DOS ain't dead

Introducing Kbfr.exe, an int 15/4F based French keyboard driver for DOS that should work on virtually any (286+ AT compatible) PC in existence.

This is a solid *beta* - been proofing it for several days round on MS-DOS 7, including Windows 98 DOS boxes. It was built incrementally upon Japheth's (C) Keybgr, with byte size conservation constantly in mind.

Main user-visible additions to/changes from keybgr. Points 1 & 2 should be backported to the German version IMNSHO...

1. Fixed numpad '/' key processing
2. Fixed Alt+(relocated letter) key processing. This is necessary for proper
menu option selection with most applications.
3. -Removed numeric "Komma/Punkt" option. Yield numerical point always.
4. +Processing of the French "dead" key (circumflex/diëresis).
5. Adapted existing and added new translation tables to fit.

0. WONTDO - 'Typewriter style' ShiftLock instead of CapsLock : for some untold reason this is how MS & others treat our poor French keyboard, but it's pretty much impossible to do it right using an int 15 based hook. What's more, I find the CapsLock style (used by the US keyboard BIOS, and by IBM/MS DOS for German and many more keyboard varieties) more convenient.

Implementation was rather straightforward, BUT for bullet point #4:
while the other modifications collectively amounted to less than one memory paragraph more consumed, that pesky "dead key" and associated state proved to be a real pig, finally costing more than 140 bytes in tables and logic, not to mention a lot of pulled hair (of which I have not too much spare).

Resulting memory use around 512 bytes (without the optional test of presence).

It's ready to be uploaded now for voluntary testing, BUT since it's using Japheth's copyrighted code (both the driver itself and the loader, unchanged from keybgr except for message translations and removal of the now unneeded /K option) I must first ask and wait for permission

***PING*** Japheth : is this plan, publishing *beta* modified source and compiled executable for testers to play with for a start, OK with you ?
Please reply in thread or PM as you see fit.

---
Ninho

> ***PING*** Japheth : is this plan, publishing *beta* modified source
> and compiled executable for testers to play with for a start, OK with you ?
>
> Please reply in thread or PM as you see fit.

KEYBGR's readme.txt tells:
-----------------------------------

Deutscher Tastaturtreiber mit sehr geringem Speicherplatzbedarf.

Wird installiert durch Eintrag in config.sys:

DEVICE=KEYBGR.EXE

KEYBGR ist Public Domain.

Japheth

-----------------------------------

In case you don't understand German, the sentence:

"KEYBGR ist Public Domain."

translated into English means:

"KEYBGR is Public Domain."

So I see no problems.

---
MS-DOS forever!

> KEYBGR ist Public Domain.

Verstehe, danke sehr!

> So I see no problems.

I hoped you wouldn't see any obstacles but better safe than sorry. I'm no expert in software property rights, licensing nor copyright laws - I already have stated this - and as I noticed, Keybgr source includes, and executable can print, a Copyright statement. I've just learnt something from you, viz (C) copyright and public domain aren't in contradiction. Or are they ?

Henceforth I'm going to upload the stable beta of Kbfr, with source, to
a server ASAP, hopefully later tonight.

I hope you'll be trying to break\\\\ exercise and/or review it even if you have no access to a physical French keyboard.

---
Ninho

> I hoped you wouldn't see any obstacles but better safe than sorry. I'm no
> expert in software property rights, licensing nor copyright laws - I
> already have stated this - and as I noticed, Keybgr source includes, and
> executable can print, a Copyright statement. I've just learnt something
> from you, viz (C) copyright and public domain aren't in contradiction. Or
> are they ?

To a certain degree they are. However, that doesn't matter much because - at least in German legacy system - if there is some kind of contradiction, then the less restrictive rule may be applied.

But to please the hobby lawyers I'll upload an updated source which will replace the line in keybinst.asm

db "(C) Copyright 1993 Japheth",cr,lf

by

db "Public Domain",cr,lf

---
MS-DOS forever!

> Introducing Kbfr.exe, an int 15/4F based French keyboard driver for DOS
>
> This is a solid *beta* - been proofing it for several days round on MS-DOS
...

Also quick tested in FreeDOS, no problem seen.

Now please speak up, is anybody else trying or planning to try this
critter, or having critics/wishes ? Or shall I wrap up the thing, more or
less as it is, while cleaning/clearing the licensing
terms (on which matter I beg you for advice too).

I am willing to donate the thing to FreeDOS - non exclusively - if they want
it as a component or as an addon (I dont know if they have locale dependent
addons already, is Japheths Keybgr part of FreeDOS distributions or addons?)

Concerning usability/functionality, I positively want to hear users' reactions.
I can certainly think of certain modifications, but it's all a question of
compromise with the notion of "low memory footprint". No point in adding
options which users don't care about (ex: Control Alt F1/f2 to switch
back and forth between Fr and US ? Loading into the HMA ? changing the way
the detection/unload options work ? etc...)

Unfortunately I am not aware of a *French* DOS programmers site comparable
to this place here, where Kbfr could find more potential eyeballs, and am
unwilling to put the beta for download on any general (non technical) site :=(


I need to decide how best to proceed. Who, if not FreeDOS or besides it, will
host the finished app? Is Bttr-software (Rr?) a possibility ?

Cheers

---
Ninho

... (retyping since browser deleted my post, gah) ...

> > Introducing Kbfr.exe, an int 15/4F based French keyboard driver for DOS
> >
> > This is a solid *beta* - been proofing it for several days round on
> MS-DOS
> ...
>
> Also quick tested in FreeDOS, no problem seen.

Good to know.

> Now please speak up, is anybody else trying or planning to try this
> critter, or having critics/wishes ? Or shall I wrap up the thing, more or
> less as it is, while cleaning/clearing the licensing
> terms (on which matter I beg you for advice too).

Can't test, no French keyboard, no parlais francais, so your best bet is to wrap it up and/or ask for help on comp.os.msdos.programmer, comp.lang.misc, comp.lang.asm.x86, or similar.

> I am willing to donate the thing to FreeDOS - non exclusively - if they
> want
> it as a component or as an addon (I dont know if they have locale
> dependent
> addons already, is Japheths Keybgr part of FreeDOS distributions or
> addons?)

JEMM386 ("BASE") has JLOAD and KEYBGR.DLL (JLM), but otherwise no, they prefer (FD) KEYB with minor fallbacks to mKEYB (minimal) or XKEYB (old, deprecated).

> Concerning usability/functionality, I positively want to hear users'
> reactions.
> I can certainly think of certain modifications, but it's all a question of
> compromise with the notion of "low memory footprint". No point in adding
> options which users don't care about (ex: Control Alt F1/f2 to switch
> back and forth between Fr and US ? Loading into the HMA ? changing the way
> the detection/unload options work ? etc...)

Switch or unload aren't important if the differences are small.

> Unfortunately I am not aware of a *French* DOS programmers site comparable
> to this place here, where Kbfr could find more potential eyeballs, and am
> unwilling to put the beta for download on any general (non technical) site
> :=(

Isn't FFK (Dugl dude) French? Maybe he could help.
You could also ask on freedos-user or freedos-devel (or me in your place if you aren't subscribed).

> I need to decide how best to proceed. Who, if not FreeDOS or besides it,
> will
> host the finished app? Is Bttr-software (Rr?) a possibility ?

Dunno about BTTR, they seem perennially busy. But (assuming it's free/libre, which is a rule Jim Hall is strict about), I could always announce it on FreeDOS' main News page (and/or mirror on iBiblio if I can ever figure out how the hell to scp a file there via ssh, ugh!)

Hi Rugx !
> ... (retyping since browser deleted my post, gah) ...
Ouch...! Which browser was that ? Arachne doesn't play such bad tricks on me :)


>> Also quick tested in FreeDOS, no problem seen.

> Good to know.

Actually I wouldn't expect any DOS-type or version related problems
with KBFR (resident part) : it is simply a *BIOS int 15h* hook, no DOS
functions involved. The only DOS related part is the tiny, optional int 2F
hook which I wouldn't expect to be problematic either. And of course the
loader, which is Japheth's good work horse.

>> Now please speak up, is anybody else trying or planning to try this
>> critter, or having critics/wishes ? Or shall I wrap up the thing, more or
>> less as it is, while cleaning/clearing the licensing
>> terms (on which matter I beg you for advice too).

> Can't test, no French keyboard, no parlais francais,

:=)

> so your best bet is to
> wrap it up and/or ask for help on comp.os.msdos.programmer, comp.lang.misc,
> comp.lang.asm.x86, or similar.

Methinks I don't need /that/ level of help. Was looking for testers;
instead I turned family members into guinea pigs. Since they appeared
to survive test and not to curse me (aloud), I'll be wrapping up.

>>I am willing to donate the thing to FreeDOS - non exclusively - if they want
>> it as a component or as an addon
....

>> I can certainly think of certain modifications, but it's all a question of
>> compromise with the notion of "low memory footprint". No point in adding
>> options which users don't care about (ex: Control Alt F1/f2 to switch
>> back and forth between Fr and US ? Loading into the HMA ? changing the way
>> the detection/unload options work ? etc...)

> Switch or unload aren't important if the differences are small.

I have some objection against the way detection (for eventual unloading)
is implemented, but... basta!

The HMA option is what I would do next if my time (and lifeline) weren't
as compromised as they are. This thing is an ideal candidate for filling
a hole in said HMA. Do you know if FreeDOS implements the same API than
MSDOS 5+ for internal HMA alloc (int 2F/4A0x IIRC) ? DRDOS certainly has
a similar, but alas! different scheme (or had, I never went passed DRDOS 6)

...

> Isn't FFK (Dugl dude) French? Maybe he could help.

Sorry, don't know him or Dugl, my bad.

> You could also ask on freedos-user or freedos-devel (or me in your place if
> you aren't subscribed).

Seems to be a good plan; I am not subsribed, not a FreeDOS user or
contributor. I would appreciate your submitting the propsition there,
you may of course post the download URL to freedos.devel, if you do please
be sure to tell them I'll be clearing the copyright/license.


>> host the finished app? Is Bttr-software (Rr?) a possibility ?

> Dunno about BTTR, they seem perennially busy. But (assuming it's
> free/libre, which is a rule Jim Hall is strict about), I could always
> announce it on FreeDOS' main News page (and/or mirror on iBiblio if I can
> ever figure out how the hell to scp a file there via ssh, ugh!)

Yet a good plan, only wait till it's final. of course!

Thanks !

--
Ninho

typed in Arachne under MS-DOS 7.1 and using recycled electrons.

> I have some objection against the way detection (for eventual unloading)
> is implemented, but... basta!

Since apparently the Int2F hook is only used to implement detection, I would suggest replacing it by an AMIS 3.6 Int2D hook (and adding interrupt-sharing protocol headers to both interrupt (2D and 15) handlers). That interface could too be written to be disabled by a build- and run-time option, like SUPPINT2F and the F option in the original driver.

> >> host the finished app? Is Bttr-software (Rr?) a possibility ?
>
> > Dunno about BTTR, they seem perennially busy.

Assuming reasonable distribution terms Robert would probably host it here. You would have to ask him specifically though; I don't have access to the website.

---
l

> Hi Rugx !
> > ... (retyping since browser deleted my post, gah) ...
> Ouch...! Which browser was that ? Arachne doesn't play such bad tricks on
> me :)

It was Chrome. Who knows, maybe BTTR timed out on me, but I couldn't "back" to retrieve my message (sigh). Oh well, it wasn't anything irreplaceable.

> > Can't test, no French keyboard, no parlais francais,
>
> :=)

"Your mouth says no, but you have 'oui oui' in your eye."

> > so your best bet is to
> > wrap it up and/or ask for help on comp.os.msdos.programmer,
> comp.lang.misc,
> > comp.lang.asm.x86, or similar.
>
> Methinks I don't need /that/ level of help. Was looking for testers;

Well, I figured some of them could test, esp. since the Internet is very polyglotish.

> The HMA option is what I would do next if my time (and lifeline) weren't
> as compromised as they are. This thing is an ideal candidate for filling
> a hole in said HMA. Do you know if FreeDOS implements the same API than
> MSDOS 5+ for internal HMA alloc (int 2F/4A0x IIRC) ? DRDOS certainly has
> a similar, but alas! different scheme (or had, I never went passed DRDOS
> 6)

I honestly don't know. But I know people have complained that FreeDOS eats all HMA thanks to bugs (or simplified handling?). E-mail Tom Ehlert I guess (or maybe Jack Ellis?).

> > Isn't FFK (Dugl dude) French? Maybe he could help.
>
> Sorry, don't know him or Dugl, my bad.

He comes on here (BTTR) sometimes! Sorry, just grasping at straws, trying to help.

> > You could also ask on freedos-user or freedos-devel (or me in your place
> if
> > you aren't subscribed).
>
> Seems to be a good plan; I am not subsribed, not a FreeDOS user or
> contributor. I would appreciate your submitting the propsition there,
> you may of course post the download URL to freedos.devel, if you do please
> be sure to tell them I'll be clearing the copyright/license.

I'll message them today, but I don't know what "clearing" needs to be done, Japheth already made it worry-free.

> >> host the finished app? Is Bttr-software (Rr?) a possibility ?
>
> > Dunno about BTTR, they seem perennially busy. But (assuming it's
> > free/libre, which is a rule Jim Hall is strict about), I could always
> > announce it on FreeDOS' main News page (and/or mirror on iBiblio if I
> can
> > ever figure out how the hell to scp a file there via ssh, ugh!)
>
> Yet a good plan, only wait till it's final. of course!

Still waiting for (the ever busy) Jim Hall to tell what how I am misunderstanding file transfer in ssh. I guess I should Google some more, but whatever little I did try definitely didn't work.

>>> ... (retyping since browser deleted my post, gah) ...
>> Ouch...! Which browser was that ? Arachne doesn't play such bad tricks

> It was Chrome.

Must've missed announcement of yours DOS port of Chrome then ;=)

>>> so your best bet is to
>>> wrap it up and/or ask for help on comp.os.msdos.programmer,
>> comp.lang.misc, comp.lang.asm.x86, or similar.

> Well, I figured some of them could test, esp. since the Internet is very
> polyglotish.

Following up to your suggestion I posted a call for testers on fr.comp.os.msdos , just in case. Group seems to have no activity, not even spam! apart from the periodic automated FAQ reminder.


>> The HMA option ...

> I honestly don't know. But I know people have complained that FreeDOS eats
> all HMA thanks to bugs (or simplified handling?).

Oh, nice :=)


>> would appreciate your submitting the propsition there,
>> you may of course post the download URL to freedos.devel, if you do please
>> be sure to tell them I'll be clearing the copyright/license.

> I'll message them today, but I don't know what "clearing" needs to be done,
> Japheth already made it worry-free.

I mean I'll update the comments and doc. I must leave this diversion and get real important things done (not computer related) ASAP.

Cheers...

---
Ninho

>> I have some objection against the way detection (for eventual unloading)
>> is implemented, but... basta!

> Since apparently the Int2F hook is only used to implement detection, I
> would suggest replacing it by an AMIS 3.6 Int2D hook (and adding
> interrupt-sharing protocol headers to both interrupt (2D and 15) handlers).
> That interface could too be written to be disabled by a build- and run-time
> option, like SUPPINT2F and the F option in the original driver.

For personal reasons I want to be done with the release ASAP, so leave the load/reload/unload scheme in the state I found it. The following remarks therefore are for a future update I or someone else might make :

I /know/ you're a fan of Ciriaco's AMIS, but it will not the right move here IMO. May I refer you to a discussion /you/ have had with Jack R. Ellis, or Brett Johnson (I don't recall whom) on another forum ?

What I would do is ditch the "supp" int 2F ident routine altogether. If unloading is asked for, check whether the active int 15h handler is still KBFR's one. If it is, unhook, and free memory. If it ain't (someone else hooked 15h after KBFR was loaded), just find KBFR by good old MCB walking and inactivate the memory copy.

>>>> host the finished app? Is Bttr-software (Rr?) a possibility ?
>>
>>> Dunno about BTTR, they seem perennially busy.

> Assuming reasonable distribution terms Robert would probably host it here.
> You would have to ask him specifically though; I don't have access to the
> website.

Thank you !

---
Ninho

> I /know/ you're a fan of Ciriaco's AMIS, but it will not the right move
> here IMO. May I refer you to a discussion /you/ have had with Jack R.
> Ellis, or Brett Johnson (I don't recall whom) on another forum ?

This may start a flaming discussion, but here goes. I'm not sure if Christian feels as strongly about AMIS as I do, but I suspect he's close, and maybe Christian and I are the only ones who see the strategic nature of AMIS.

IMHO, AMIS should be included as part of ALL modern TSR's and device drivers. There's really no good reason not to include it. The overhead required to support it is small compared to the benefits it provides. Perhaps the most important thing to keep mind, though, is that the benefits are for the USER, not the programmer.

Written by Bretjohn :
> This may start a flaming discussion, but here goes. I'm not sure if
> Christian feels as strongly about AMIS as I do, but I suspect he's close,
> and maybe Christian and I are the only ones who see the strategic nature of
> AMIS.

No arguing nor flaming from me but

> IMHO, AMIS should be included as part of ALL modern TSR's and device
> drivers. There's really no good reason not to include it. The overhead
> required to support it is small compared to the benefits it provides.

... make that all modern TSRs EXCEPT this keyboard driver ;=) Whatever the respective merits of AMIS and ye DOS int 2F, KBFR needs none of them :
The whole point of the exercise is to shave "the last byte" off its resident portion. If it weren't for the size, we might as well use a full regular IRQ1 driver...


> Perhaps the most important thing to keep mind, though, is that the benefits
> are for the USER, not the programmer.

Me too ;=)

Cheers

---
Ninho

> For personal reasons I want to be done with the release ASAP, so leave the
> load/reload/unload scheme in the state I found it.

Ah, Bret and I could surely provide you with source code for such an implementation. (Mine's in NASM syntax though.) Just saying, don't worry, I won't push it any more if you don't want it.

> The following remarks
> therefore are for a future update I or someone else might make :

Understood.

> I /know/ you're a fan of Ciriaco's AMIS,

Who/what is "Ciriaco"? http://www.funtener.org/ebooks-tutoriales-f6/el-un...el-ibm-pc-at-y-ps-2-ciriaco-garcia-t168184.html this one? I wasn't aware of this person. To address your point however, yeah, I confess I'm a fan of AMIS.

> but it will not the right move here IMO.

Just an idea, specifically seeing that the Int2F handler isn't necessary otherwise.

> May I refer you to a discussion /you/ have had with Jack R.
> Ellis, or Brett Johnson (I don't recall whom) on another forum ?

Assuming you mean a discussion where someone disagreed with me about AMIS, then it probably was with Jack. I don't remember it really though. And if you're referring to any specific technical point that we discussed then, you could as well point that out directly.

> What I would do is ditch the "supp" int 2F ident routine altogether. If
> unloading is asked for, check whether the active int 15h handler is still
> KBFR's one. If it is, unhook, and free memory. If it ain't (someone else
> hooked 15h after KBFR was loaded), just find KBFR by good old MCB walking
> and inactivate the memory copy.

You could still add an interrupt handler walker to the uninstaller to take advantage of installed interrupt sharing protocol and AMIS-compatible handlers, even if your handler doesn't adhere to either. (Though I'd very much recommend at least implementing the Int15 handler with the interrupt sharing protocol.)

---
l

> I'm not sure if
> Christian feels as strongly about AMIS as I do, but I suspect he's close,
> and maybe Christian and I are the only ones who see the strategic nature of
> AMIS.

I actually might feel similarly, but I'm not going to debate endlessly about it. Having said that, I won't answer any further AMIS posts in this thread if no one specifically raises more questions or points about it here.

> IMHO, AMIS should be included as part of ALL modern TSR's and device
> drivers. There's really no good reason not to include it. The overhead
> required to support it is small compared to the benefits it provides.

In any case, even if one doesn't want AMIS, providing and/or using interrupt sharing protocol headers is still very useful. I think it's very important to point that out specifically (hence I'm repeating myself here).

Additionally, I don't agree with you about the "modern TSR's"; I'd in any case write "modern TSRs" here ;)

---
l

> > IMHO, AMIS should be included as part of ALL modern TSR's and device
> > drivers. There's really no good reason not to include it. The overhead
> > required to support it is small compared to the benefits it provides.
>
> ... make that all modern TSRs EXCEPT this keyboard driver ;=) Whatever the
> respective merits of AMIS and ye DOS int 2F, KBFR needs none of them :
> The whole point of the exercise is to shave "the last byte" off its
> resident portion.

I see. As I suggested, you could implement a build and/or run-time option similar to those currently there to remove/disable the multiplex interrupt handler. (One can even implement the run-time option so that it installs a smaller TSR, if the affected parts are moved to the end of the TSR.) Why throw away features that some might not want if they're easy to keep around disabled or commented in the source code?

Anyway, if your goal is to optimize the memory usage of this driver:
* Don't install using Int21.31 (as you do with option /C "don't relocate"), you're leaving the PSP (256 bytes) resident in that case.
* Don't leave the device part resident if you install the normal way. You would have to relocate the TSR's resident part to achieve this (even if /C is specified). (Alternatively, assemble the driver without the device driver part.)
* Consider minimizing memory fragmentation. If there's no UMA available or /C is specified, installing the driver probably fragments memory. (To avoid all memory fragmentation, you would have to relocate the PSP. Yes, it can be done.)

---
l

(snipping)
> Anyway, if your goal is to optimize the memory usage of this driver:
...
All done (credit Japheth), no fragmentation nor PSP remains in any case.

Other questions ? :=)


Since we are evoking byte shaving, let me start a small digression of a case hopefully not completely off topic and which might amuse or interest some readers. The original (keybgr) took care of saving/restoring the flags. That precaution probably seemed necessary to the seasoned (and cautious) professional programmer but, oyez! oyez! hear...!, both the clueless newbie (confused anyway with all that there interrupt stuff), AND... the "good (TM)" programmer (after carefully checking his facts) will omit the flag save/restore (thereby reducing the size of the resident KBFR by a whopping 6 bytes iirc) :=)

The reason a software int 15h "hook" does not need to preserve the running flags is, of course, that no information is passed "down" thru them and, conversely, in cases information has to be passed back "up" to the (initial) caller, it is by altering the flags image put on the stack by the initial int 15 caller, not the running flags.

And why I'm bringing this fact here is that, indeed, the preserving/restoring of the flags around our int 15 hook was hardly a bug (it is useless but does no harm) and would not warrant a mention in the common case, nonetheless it is a a little lack of precision when one is... shaving bytes!

For anybody who wouldn't believe we do not need to pass the flags (received "from upwards") down the chain , while writing this I've been checking some int 15 "hooker", viz MS-Smartdrv (which is willing to catch the "3 finger salute" if you wonder why it hooks int 15). Well, MS got it right, it doesn't lose time in needlessly preserving the flags. Considering ~1 billion PCS have issued quadrillions of int 15s "through" Smartdrv, if their (and my) method were faulty you bet someone would've noticed :=)

Enough, sorry for the digression - I may've had a little wine too much

---
Ninho

> > Anyway, if your goal is to optimize the memory usage of this driver:
> ...
> All done (credit Japheth), no fragmentation nor PSP remains in any case.

I downloaded your program while I wrote that post and verified all of my points. (I also discarded one point I had in mind at first that didn't apply here.) Assuming you didn't silently update the program just now, they still all apply.

> ... flags image on the stack ...

Enough said.

> For anybody who wouldn't believe we do not need to pass the flags along the
> chain as we received "from upwards", while writing this I've been checking
> a famous int 15 "hooker", MS-Smartdrv (which is willing to catch the "3
> finger salute" if you wonder why it is hooking int 15). Well, MS got it
> right, it doesn't lose time in needlessly preserving the flags.

Yes. Right. Because if Microsoft does something some way, then it absolutely must be right to do it that way. (In case you can't tell, this is sarcasm. Independent of whether you should or shouldn't save the flags separately, I do not think reasoning with Microsoft's implementation is necessarily good.)

> Enough, sorry for the digression - I may've had a little wine too much

Sober up please.

---
l

> > > Anyway, if your goal is to optimize the memory usage of this driver:
> > ...
> > All done (credit Japheth), no fragmentation nor PSP remains in any case.
>
>
> I downloaded your program while I wrote that post and verified all of my
> points. (I also discarded one point I had in mind at first that didn't
> apply here.) Assuming you didn't silently update the program just now, they
> still all apply.

What DOS type and version please ? Under MSDOS 7, Japheth's scheme (really it's his loader I can't and won't take credit) does not create fragmentation and does remove the PSP. Zero overhead besides the 16-byte MCB. I assumed\\\hoped it would in other important DOSes too (hey! that's why I begged for beta testing out there! Thank you for actually launching the critter, in the end :=)

>> ... flags image on the stack ...
>
> Enough said.
>
> > For anybody who wouldn't believe we do not need to pass the flags along
> the
> > chain as we received "from upwards", while writing this I've been
> checking
> > a famous int 15 "hooker", MS-Smartdrv (which is willing to
> catch the "3
> > finger salute" if you wonder why it is hooking int 15). Well, MS got
> it
> > right, it doesn't lose time in needlessly preserving the flags.
>
> Yes. Right. Because if Microsoft does something some way, then it
> absolutely must be right to do it that way.

No, but maybe my example was somehow tongue in cheek, you know ?

(In case you can't tell, this
> is sarcasm. Independent of whether you should or shouldn't save the flags
> separately, I do not think reasoning with Microsoft's implementation is
> necessarily good.)

The right way (as I mentioned) is to study software int 15 (from BIOs listings, printed books, Ralf Brown's infamous list and build a few years' experience like you and me have. And brains). The MS example however is not worthless. MS systems programming (whether done in house or bought/"borrowed" I don't care) usually is excellent stuff. But there is another reason I chose that example, which is : in the terrible case that I, and MS, were wrong... it wouldn't matter that others were (in that absurd hypothesis) right : the mere existence of be it /one/ program which did not preserve the flags around its hook would make all the others' precaution useless. <G>

---
Ninho

> > For personal reasons I want to be done with the release ASAP, so leave
> the
> > load/reload/unload scheme in the state I found it.
>
> Ah, Bret and I could surely provide you with source code for such an
> implementation. (Mine's in NASM syntax though.) Just saying, don't worry, I
> won't push it any more if you don't want it.
>
> > The following remarks
> > therefore are for a future update I or someone else might make :
>
> Understood.
>
> > I /know/ you're a fan of Ciriaco's AMIS,
>
> Who/what is "Ciriaco"?

Ciriaco de Celis was UIAM the originator of the AMIS; he also designed several schemes and DOS drivers for filling floppies (up to 2 Megabytes on a regular 1.44HD diskette with his, unusable in practice, 2MGUI).

> http://www.funtener.org/ebooks-tutoriales-f6/el-un...el-ibm-pc-at-y-ps-2-ciriaco-garcia-t168184.html
> this one? I wasn't aware of this person.

Yeah, Ciriaco Garcia de Celis was the name.

To address your point however,
> yeah, I confess I'm a fan of AMIS.
> You could still add an interrupt handler walker to the uninstaller to take
> advantage of installed interrupt sharing protocol and AMIS-compatible
> handlers, even if your handler doesn't adhere to either. (Though I'd very
> much recommend at least implementing the Int15 handler with the interrupt
> sharing protocol.)

You know, this is going to be free/libre and I won't take offence if you make it better (or different). I gave the reasons why I won't change the loader/unloader in this round, except minimally and trivially. Besides, it is
doing very good (at least on MSDOS. We're back to your/my above statement/question. I guess you used FreeDOS ?)


--
N.

---
Ninho

> Under MSDOS 7, Japheth's scheme (really
> it's his loader I can't and won't take credit) does not create
> fragmentation and does remove the PSP.

It doesn't depend on the DOS version, it depends on the circumstances.

Please study the loader's source code first if you want to discuss its behaviour any further.

As I said, the PSP is not deallocated if you use the /C option.

As I said, memory fragmentation is likely(!) to occur if you use the /C option, or if you install the driver while no UMB is available. (I believe memory fragmentation is _possible_ even in other cases, but those other cases would be more contrived.)

As I said, the device driver header is left resident as unnecessary overhead. You can verify this by dumping the memory that the TSR takes up, the readable "KEYBFR#1" string there is obviously the device name in the device driver header structure. (Note that the installer sets the MCB's name to "SC", no descriptive name.)

And I'd hardly define the MCB as overhead

> Thank you for actually launching the critter, in the end :=)

Thank you for messing up my keyboard layout

---

> No, but maybe my example was somehow tongue in cheek, you know ?

Ha ha.

> The right way (as I mentioned) is to study software int 15 ...

Agreed.

> The MS example however is not worthless.

True. Not worthless. But still: a Microsoft implementation alone is not an argument that would convince me.

> MS systems programming ... usually is excellent stuff.

Not so sure here. (Off-topic anyway.)

> the mere existence of be it /one/ program which
> did not preserve the flags around its hook would make all the others'
> precaution useless. <G>

That only holds if I use that program.

---
l

>> I downloaded your program while I wrote that post and verified all of my
>> points. (I also discarded one point I had in mind at first that didn't
>> apply here.) Assuming you didn't silently update the program just now,
> they
>> still all apply.
>
> What DOS type and version please ? Under MSDOS 7, Japheth's scheme (really
> it's his loader I can't and won't take credit) does not create
> fragmentation and does remove the PSP.

Sincere apologies, it does not remove the PSP *if loaded low* - just what
you say further down. I /thought/ I'd checked, see, this is more evidence
that sometimes it takes more than one pair of eyeballs to see the obvious!
I have been too confident in Japheth's loader, didn't really read through
the code.

I've been unwilling to change the loader (you know when you start, never
know when it's over). While I can see your point and it can be called a
defect, do you all think it is a show stopper ? People will load high
anyway (most of'm have EMM386, like it or not). And if they don't well...
even 256 wasted PSP bytes is little compared to what MS KEYB.COM uses.

Oh well, going to bed, tomoroow is another (bright,... maybe) day

---
Ninho

> > Under MSDOS 7, Japheth's scheme (really
> > it's his loader I can't and won't take credit) does not create
> > fragmentation and does remove the PSP.
>
> It doesn't depend on the DOS version, it depends on the circumstances.
>

Right, I have confirmed, and apologised (we were both writing at the same
time). Going to sleep now, good night or good day whichever applies to
you!

> Please study the loader's source code first if you want to discuss its
> behaviour any further.

See other response plz
>
> Thank you for messing up my keyboard layout

YVW !!!!

--
Ninho (gone...)

> While I can see your point and it can be called a
> defect, do you all think it is a show stopper ? People will load high
> anyway (most of'm have EMM386, like it or not). And if they don't well...
> even 256 wasted PSP bytes is little compared to what MS KEYB.COM uses.

My point isn't that you have to fix this; I was addressing the point you made were you reasoned against AMIS to save memory. Considering that a (mostly) compliant AMIS implementation would take less resident space up than either the possible fragmentation, or the PSP left resident (with /C), or the device header left resident, I'll go ahead and declare your "AMIS takes up too much memory" argument invalid for now ;)

> I've been unwilling to change the loader (you know when you start, never
> know when it's over).

Oh yeah, I do know that. And I think that's indeed a better argument against AMIS here.

> Ciriaco de Celis was UIAM the originator of the AMIS;

Oh, well, I never heard of him. You might be right though.

So that book(?) apparently contains a chapter(?) titled "10.5.3 - La propuesta AMIS" which probably means "The AMIS proposal". With my limited Spanish skills (mostly entering things into Google's translation service) I'd guess it suggests using the AMIS that was developed by Ralf Brown.

> I gave the reasons why I won't change the
> loader/unloader in this round, except minimally and trivially.

No problem.

> ... I guess you used FreeDOS ?

Doesn't matter, as I mentioned elsewhere.

---
l

> That precaution probably seemed necessary to the seasoned (and
> cautious) professional programmer but, oyez! oyez! hear...!, both
> the clueless newbie (confused anyway with all that there interrupt stuff),
> AND... the "good (TM)" programmer (after carefully checking his facts) will
> omit the flag save/restore (thereby reducing the size of the
> resident KBFR by a whopping 6 bytes iirc) :=)

Cool!

> The reason a software int 15h "hook" does not need to preserve the running
> flags is, of course, that no information is passed "down" thru them and,
> conversely, in cases information has to be passed back "up" to the
> (initial) caller, it is by altering the flags image put on the stack by the
> initial int 15 caller, not the running flags.

This is true ............ to some degree. :))

However ... there are a few considerations:

- int 15h is an interrupt which is used for a lot of purposes.
- there exists software, including BIOSes, which do NOT return
from this interrupt by an IRET, but by a RETF 2.
- a lot of software sets (or resets) the carry flag BEFORE it calls Int 15h.
( this is probably done because there exist buggy hookers/BIOSes ).

So, considering these facts(?), one might come to realize that it is at least "thinkable" that saving the flags status is not absolutely useless. I guess - it was in 1993! - that was the reason why I added it.

---
MS-DOS forever!

Hullo Japheth

>> That precaution probably seemed necessary to the seasoned (and
>> cautious) professional programmer but,...
>> ... the "good (TM)" programmer (after carefully checking his facts)
> will
>> omit the flag save/restore (thereby reducing the size of the
> > resident KBFR by a whopping 6 bytes iirc) :=)

> Cool!


> This is true ............ to some degree. :))
>
> However ... there are a few considerations:
>
> - int 15h is an interrupt which is used for a lot of purposes.

Indeed the "cassette!" interrupt has been a place holder for an ever expanding number of system services. I consider it the BIOS analogous to DOS's int 2F multiplex ("printer.sys" was it not?)

> - there exists software, including BIOSes, which do NOT return
> from this interrupt by an IRET, but by a RETF 2.

Due to the above, a Retf 2 will make sense in certain cases of int 15h and not in others.

> - a lot of software sets (or resets) the carry flag BEFORE it calls Int
> 15h.

Ack, this is even prescribed in many cases of int 15. Case in point (15/4F) caller (normally an IRQ1 routine) is supposed to SET CY (and I have yet to SEE a firmware BIOS or software IRQ1 handler that doesn't) and our *hooker* returns status information thru the carry, that is the Cy bit of the flag image saved by the initial Int 15 instruction, not the current carry.

> ( this is probably done because there exist buggy hookers/BIOSes ).

Our hooker is not supposed to repair bugs in other software. The important point here is if some other int 15 hooker incorrectly thinks the Flags register passed to it holds meaningful information, there is /no/ general way whatever we do can repair that other software's bug, except in marginal circumstances. I thought this over in the 90s, and I even taught it.

Fortunately when considered in detail the scheme is not as fragile as it looks.

> So, considering these facts(?), one might come to realize that it is at
> least "thinkable" that saving the flags status is not absolutely useless. I
> guess - it was in 1993! - that was the reason why I added it.

This is well understood and why I said the "seasonned, cautious, professional..." would wish to pushf/popf just in case ;=)

Analysis and practice however show that it is in fact both unnecessary, from a functional PoV, and useless as a well meaning measure to "repair" others' bugs. If there was a 1/1,000,000 doubt in my mind, I would gladly put those miserable 6 bytes to the place where I took them off ;=)

Truly,

--
Ninho

---
Ninho

>> even 256 wasted PSP bytes is little compared to what MS KEYB.COM uses.

> My point isn't that you have to fix this; I was addressing the point you
> made were you reasoned against AMIS to save memory. Considering that a
> (mostly) compliant AMIS implementation would take less resident space up
> than either the possible fragmentation, or the PSP left resident (with /C),
> or the device header left resident, I'll go ahead and declare your "AMIS
> takes up too much memory" argument invalid for now ;)

Thus using Japheth's bloat as an excuse to add Ciriaco's ? (Just kidding!)<G>

>> I've been unwilling to change the loader (you know when you start, never
>> know when it's over).
>
> Oh yeah, I do know that. And I think that's indeed a better argument
> against AMIS here.

Glad you agree. You see, I am aware and agree myself with every of your detailed points. Back before 2000 I devised an used for myself a scheme for DOS programs to relocate themselves to the initial location of their own PSP and yes, their environment block [provided it was contiguous to the PSP which is not a given], by playing a few tricks documented and (s-c) undocumented, and going back to the system by int 21/4Ch not 31h, which was probably equivalent if not identical to what you promote. I used to be at ease and even love those tricks back then. I lost the respective source files and notes, though, so redoing it from scratch would take too much time (I'm getting old, too!) OTOH I still have my examples of relocation to MSDOS 5+ HMA. I did write (TBH rather stole and adapted from the DRDOS 6 version) an HMA int 9 handler which it was handy to have on 80286s without any UMBs.

Here's my suggestion to you - ONLY if you like it and can get that riches, TIME ! Since as I understand it you do have a working framework for optimal TSR relocation readied both in your mind and in your files, you might take KBFRINST.ASM (be sure to get the later version from my site), tear it to pieces and implement your scheme. For the resident part (KBFRRES.ASM) you'd either provide me with a clear interface description so I can apply changes or just modify it yourself [only please DON'T touch any of the the "French" int 15/4F code proper, that plate of spaghetti only I can cook ! In retrospect, I should have written it from scratch, but initially did not think there would be so much to add to keybgr]

---
Ninho

>> Ciriaco de Celis was UIAM the originator of the AMIS;

After a night's rest and regenerating my little gray cells (if that's possible at all), I think Ralf Brown indeed was who originated AMIS (he certainly was who advertised it) and Ciriaco Garcia must have been an (early) adopter.

---
Ninho

> Thus using Japheth's bloat as an excuse to add Ciriaco's ?

Haven't you heard? Any amount of unnecessary bytes attracts more such.

> Back before 2000 I devised and used for myself a scheme for
> DOS programs to relocate themselves to the initial location of their own
> PSP and yes, their environment block [provided it was contiguous to the PSP
> which is not a given], by playing a few tricks documented and (s-c)
> undocumented, and going back to the system by int 21/4Ch not 31h, which was
> probably equivalent if not identical to what you promote.

Hmm, I don't know. My method will result in the least possible fragmentation (given the placement of other memory blocks), independent of where my PSP and environment were placed. I free the latter (of course) and move the former to my liking. (This is especially useful considering that well-meaning users might try "optimizing" the TSR's placement using LOADHIGH or other commands of that ilk, in effect possibly blocking the best UMB with the PSP and environment.) Of course I use Int21.4C for process termination too. (This obviously only applies to TSRs that do not need their PSP any more once they're resident. With TSRs that want to use their PSP again (- though a prior PSP relocation is still usually required for optimal placement -) using Int21.31 to terminate is just fine.)

I've recently thought of a different method were, instead of relocating the PSP using Int21.4C (hooking the entire parent, parent stack and PSP field in my PSP, Int22 and all)* one could terminate the process and then effectively place the TSR while using the original parent's process (hooking only Int22 and the parent stack field).** However, I don't think I'll implement that: I don't think it's advantageous in the general case; and it means one couldn't depend on any process resources during the final placement. (It might be advantageous in special cases with strict memory limits, like, say, an improved LOADFIX or UMB blocker that automatically unloads once a process launched by the program terminated.) (Such an incomplete termination hook strikes me as less portable and more dependent on DOS internals, too. Would have to look into it again to verify that though.)

* I guess because I terminate two times one could call my method "TTSR": "Terminate, Terminate again, and Stay Resident all the while".

** Analogous to TTSR, "TIJPSR": "Terminate Improperly then Jump to the Parent process, Staying Resident"

> Here's my suggestion to you - ONLY if you like it and can get that
> riches, TIME ! Since as I understand it you do have a working framework for
> optimal TSR relocation readied both in your mind and in your files, you
> might take KBFRINST.ASM (be sure to get the later version from my site),
> tear it to pieces and implement your scheme.

Yeah, I might do that later. Would have to look into porting the source code (as you might have heard I'm a fan of NASM too) or getting it to link properly somehow though. I'm not experienced enough with linkers to get them to output what I want them to output for my (T)TSR shenanigans though, so I would either have to learn something new or work around that.

> [only please DON'T touch any of the the "French" int 15/4F code
> proper, that plate of spaghetti only I can cook !

Alright. Given that neither I possess any French keyboard, nor have I really looked into keyboard layout mapping yet, I wouldn't want to change it anyhow.

> In retrospect, I should have written it from scratch, but
> initially did not think there would be so much to add to keybgr

But would you have come up with a better solution in the time that it took you to adapt Keybgr? I doubt it.

---
l

> even 256 wasted PSP bytes is little compared to what MS KEYB.COM uses.

Just for the record, your program, or any program that simply intercepts INT 15.4F to remap the keyboard, is not even remotely equivalent to the MS KEYB program. You're comparing apples to oranges, as they say here in the USA.

MS KEYB literally replaces the ENTIRE keyboard BIOS handler (INT 9) with a new one. Considering what it actually does, the memory requirements of MS KEYB (about 6 kB) are not unreasonable.

Many times, an INT 15.4F handler is all you need to accomplish what you want, but sometimes it isn't. AFAIK, there is no true equivalent to the MS KEYB program available anywhere.

> Just for the record, your program, or any program that simply intercepts
> INT 15.4F to remap the keyboard, is not even remotely equivalent to the MS
> KEYB program. You're comparing apples to oranges, as they say here in the
> USA.
>
> MS KEYB literally replaces the ENTIRE keyboard BIOS handler (INT 9) with a
> new one. Considering what it actually does, the memory requirements of MS
> KEYB (about 6 kB) are not unreasonable.

Of course - though I prefer slightly hacked, old versions from OEM MS DOS 3.x.
They work perfectly in every modern DOS, do NOT require access to voluminous separate keyb.sys tables (important for boot dikettes), and the driver itself requires half the memory than the newer versions.

> Many times, an INT 15.4F handler is all you need to accomplish what you
> want, but sometimes it isn't. AFAIK, there is no true equivalent to the MS
> KEYB program available anywhere.

Agreed, it's not equivalent. But pretty close IMHO; YMMV !
Also, the MS KEYB installs a full int 16 handler (while the ROM BIOS handler is almost always OK on an AT), plus "code page" stuff which personally I find so badly designed as to be practically useless, plus int 2F multiplex handler for said codepage stuff and more... bloat bloat bloat :=)

The way MS designed their internationaliZation or "i8n" stuff at the era of MS DOS 3.2x (?) was a cruel joke. Instead of OEM versions optimised for a particualr country and particular hardware, we got "one size fits all" stuff (same for country specific conventions for example. Perso for boot diskettes I use a cntryfr.sys which contains only stuff for US and FR and which I assembled from country.sys format description found, probably, in RBrown's list. But I must be one of a handful persons outside the USA who desn't suffer from MS's lack of care. So, please, don't praise Microsoft it doesn't work too well with me) <G>

---
Ninho

> Just for the record, your program, or any program that simply intercepts
> INT 15.4F to remap the keyboard, is not even remotely equivalent to the MS
> KEYB program. You're comparing apples to oranges, as they say here in the
> USA.

IMO they are almost equivalent.

> MS KEYB literally replaces the ENTIRE keyboard BIOS handler (INT 9) with a
> new one. Considering what it actually does, the memory requirements of MS
> KEYB (about 6 kB) are not unreasonable.

I - and AFAIR quite a few other people as well - also wrote keyboard "drivers" that fully replace BIOS INT 9. It's not that much more difficult than a "Int-15" driver. And ... the one I wrote takes 4 kB only!

> AFAIK, there is no true equivalent to the MS KEYB program available anywhere.

I'm afraid that's not fully true - at least not as far as a German version is concerned. The one that I wrote can be downloaded from http://www.japheth.de/Download/DOS/KEYBAT.zip. It's the binary only, because I really don't feel like cleaning the very old assembly sources ( it was written before KEYBGR ).

---
MS-DOS forever!

> IMO they are almost equivalent.

They are functionally equivalent, but only in certain situations. On some computers, it is necessary to replace the keyboard BIOS for compatibility issues. That's one of the reasons MS felt it was necessary to replace the entire BIOS with their KEYB program, in addition to making it possible to simply remap the keyboard. With modern hardware like USB keyboards and UEFI BIOS's, compatibility issues are already a problem and are only going to get worse. An INT 15.4F interface simply won't be good enough as things continue to move forward.

> I'm afraid that's not fully true - at least not as far as a German version
> is concerned. The one that I wrote can be downloaded from
> http://www.japheth.de/Download/DOS/KEYBAT.zip. It's the binary
> only, because I really don't feel like cleaning the very old assembly
> sources ( it was written before KEYBGR ).

Again, I'm personally not aware of any equivalent to MS KEYB (and no, Ninho, I'm not praising MS). A driver that simply maps a specific keyboard language, like yours does, even if it completely intercepts INT 9, is not equivalent to MS KEYB. Your KEYBAT program is much closer to a MS KEYB replacement than an INT 15.4F driver is, though.

BTW, your KEYBAT uses only about 2.7 kB (at least in the default configuration), not even the 4 kB you thought.

>> IMO they are almost equivalent.

> They are functionally equivalent, but only in certain situations.

You do realise int 15/4F handlers execute as part of an int 9/IRQ1 handler.
Actually, one could in theory duplicate or replace almost the entire int 9 functionality with an int 15 4F handler which would always return a clear carry flag to the BIOS - in effect leaving to the original BIOS only the actual in/out interactions with the interrupt and keyboard controllers.

In practice one wouldn't proceed like that of course, rather write an int 9 handler and replace the BIOS altogether, like Microsoft, Digital...; and many OEMs provided their own version in the early days of compatible PCs. Also Japheth in this thread told us he wrote his own iiuc. I was surprised you seemed to think it was some sort of MS exclusivity!

But whether the national kb replacement hooks int 9 or int 15 should make little difference to other software. When doing int 15/4F however, we generally want to use as much of the original BIOS's power as we can, while keeping as much user's experience and compatibility to other programs intact as possible.


> On some
> computers, it is necessary to replace the keyboard BIOS for compatibility
> issues.

Bad computer, change computers ;=) Seriously I doubt this has been a problem since the mid 90s, when PC clones had become a comodity and most were fully "compatible".

> That's one of the reasons MS felt it was necessary to replace the
> entire BIOS with their KEYB program, in addition to making it possible to
> simply remap the keyboard.


> Again, I'm personally not aware of any equivalent to MS KEYB (and no,
> Ninho, I'm not praising MS).

I know you aren't, but you are inmproperly singling them out, like they were the only providers of full fledged int 9 handlers out there.

> A driver that simply maps a specific keyboard
> language, like yours does, even if it completely intercepts INT 9, is not
> equivalent to MS KEYB.

It could be equivalent if we wanted to. there's a compromise made between function and size. Mine (the French version) goes further than the German ancestor on the path to compatible handling of the (Alt, Control) keystrokes. The goal however is NOT to make it equivalent, just better...;=)

The main problems with the AT keyboard however stem from the fact that there is no way for a program to read minds or... the physical keyboard layout (including the labels printed or stuck on keycaps). Simple extensions to the keyboard/KBC protocol could easily provide character code/language info but unfortunately weren't provided!

Therefore there will always exist problems with programs that must bypass the BIOS altogether for part of their keyboard processing. Ordinary programs (i.e. not full keyboard handlers) which get scancodes by way of "in al,60h" whether polling or installing their own IRQ driver, should not, IMO, call int 15/4F. The latter should be called /only/ by a BIOS IRQ 1 handler (or replacement thereof).

> (Japheth's) KEYBAT program is much closer to a MS KEYB
> replacement than an INT 15.4F driver is, though.

---
Ninho

empty

I was simply going to stop responding to this thread, since it was proving fruitless. However, I can't let Ninho's comments simply pass for fear that someone might actually try to implement something based on what he says.

> You do realise int 15/4F handlers execute as part of an int 9/IRQ1 handler.
> Actually, one could in theory duplicate or replace almost the entire int 9
> functionality with an int 15 4F handler which would always return a clear
> carry flag to the BIOS - in effect leaving to the original BIOS only the
> actual in/out interactions with the interrupt and keyboard controllers.

This is not true. INT 15.4F is indeed called by the INT 09 handler, but that is not the only time it is called. It can be called by any program at any time. Because of this, an INT 15.4F handler is not allowed to actually "process" any keystrokes or make any system changes at all (put ASCII codes in the keyboard buffer, make changes to the BIOS Data Area, etc.).

E.g., Some of my "keyboard simulation" programs may call INT 15.4F in order to make sure they are simulating a valid scancode. I think I've also seen references to programs that simulate a Ctrl-Alt-Del through INT 15.4F in order to flush the caches of a disk caching program like SMARTDRV (more on this further down).

> Therefore there will always exist problems with programs that must bypass
> the BIOS altogether for part of their keyboard processing. Ordinary
> programs (i.e. not full keyboard handlers) which get scancodes by way of
> "in al,60h" whether polling or installing their own IRQ driver, should not,
> IMO, call int 15/4F. The latter should be called /only/ by a BIOS IRQ 1
> handler (or replacement thereof).

Not true, as stated above. INT 15.4F is allowed to be called by any program at any time. That is why it is a separate interface and not actually required to be part of the INT 9 handler.

Regarding your specific implementation, it has problems. I haven't look at all of the details, but your INT 15 handler is incorrect. There are programs that "monitor" keystrokes by trapping INT 15.4F. E.g., SMARTDRV monitors INT 15.4F for Ctrl-Alt-Del, and flushes its write caches when this occurs. Since your program does not chain to the old INT 15 handler, there is a potential for drive corruption during a reboot if the user installed a disk caching program (like SMARTDRV) before they installed your driver. You must chain to the old handler even if you are the one processing the INT 15 Request. Because you must chain, there is also the possibility that the user has installed more than one INT 15.4F handler (either inadvertently or on purpose), which you must handle correctly.

Your INT 15h handler should look something like this. Note that this is in A86 syntax, and is untested, so there might be errors/problems with it, but you will hopefully get the idea:


  PUSH AX              ;Save Original AX
  PUSH BP              ;Save used registers
  PUSH W SS:[BP+8]     ;Call the
  CALL [OldVector]     ;  Old INT 15h Vector
  PUSH BX              ;Save used registers
  PUSHF                ;Put return flags
  POP  BX              ;  in BX
  STI                  ;Enable interrupts
  CMP  B SS:[BP+3],4Fh ;Is this call for us?
  JNE >F80             ;If not, jump to handle it
  MOV  AX,SS:[BP+2]    ;AX = Original AX

  ;Process here, setting return CF (at SS:[BP+8]) and modifying AL as needed
 
  JMP >F90             ;Done
F80:                   ;Call was not for us
  MOV  SS:[BP+8],BX    ;Set return flags
F90:                   ;Done
  POP  BX              ;Set return BX
  POP  BP              ;Restore used registers
  ADD  SP,2            ;Skip over the original AX
  IRET


A NASM example outlining how to construct an IISP header yourself (I usually use a macro for that), and with slightly different behaviour. (Yes, I know the flags are handled differently. And I don't know what to do with the AL value(s). Ignore these parts, they would have to be adjusted accordingly.) The part I want to point out specifically is that Bret's example would chain by calling the next handler every time, then check afterwards whether it was the correct function call. That unnecessarily increases the stack usage of every Int15 function and may or may not be less efficient than this one: It checks for the correct function first, and will chain directly (via jump) if it's another function.

; This stuff at the beginning is the IISP header (17 bytes).
; It allows other programs to walk the handler chain past this one.
int15.dummyhwreset:
    retf

int15:
    jmp short .actualhandler
.next:
    dd 0
    db "KB"
    db 0
    jmp short .dummyhwreset
    times 7 db 0

    ; Here the actual handler.
.actualhandler:
    ; push ax           ; (if saving al, see below)
    pushf
    cmp ah, 4Fh         ; Is this our function call?
    je .handle
    popf                ; Nope, chain quickly to the next handler:
    ; pop ax            ; (if saving al, see below)
.jumpnext:
    jmp far [cs:.next]

.handle:
    ; Save al here? (Modify it already?)

    push cs
    call .jumpnext
    ; pop ax            ; (if saving al)

    ; Process in some way.

    iret


Boys, I was passing by to announce I've uploaded a revised kbfr (see announce)

> I was simply going to stop responding to this thread, since it was proving
> fruitless. However, I can't let Ninho's comments simply pass for fear that
> someone might actually try to implement something based on what he says.

Brett, thank you for going out of your way in order to try to pass your important message...

Be sure I'll reply but now I cannot spare the time to even read your article other than diagonally. And I am probably not going to agree with every point you try to make, let alone the tone

Regards; see you later...

---
Ninho

Thanks for providing your advice. I've been soliciting remarks indeed and this is why I make kbfr a 'beta'.

Note however that it is Japheth's work you're criticising before being Ninho's, not that I want to elude responsibility, only I can't reply relative to Japheth's own intentions, just my take.

> I can't let Ninho's comments simply pass for fear that
> someone might actually try to implement something based on what he says.

The 'something' in question exists and has been in use since 1993 however. This may relativise your 'fear'. As for the French version, I am using it for typing this and quite pleased although I'm arguably not impartial.


Your article is trying to make 2 points, which I'll address in turn. There's good news and there's bad news, only maybe not so bad...


Bret's point #1 :

>> You do realise int 15/4F handlers execute as part of an int 9/IRQ1
> handler (...)

> This is not true.

Says who ? Not true, is : in your not so humble opinion.

According to Ralf Brown, int 15/4F is "called by INT 09 handler", providing a keyboard "intercept" (IOW a hook) used by software which wants to "rearrange the keyboard".

> INT 15.4F is indeed called by the INT 09 handler, but
> that is not the only time it is called. It can be called by any program at
> any time.

A rather personal, even excentric interpretation! "INT 09 handler" (R. Brown's word) is not quite "any program" !


> Because of this, an INT 15.4F handler is not allowed to actually
> "process" any keystrokes or make any system changes at all (put ASCII codes
> in the keyboard buffer, make changes to the BIOS Data Area, etc.).

Leaving apart "because of this", since as we've shown 'this'...is a fallacy;
now /you/ insist on calling int 15/4F, which is an abuse, then /you/ decide what int 15/4F is allowed to do to suit your abuse? That's too much if you ask me.

Don't get me wrong : I don't deny your right to (intelligently) twist standards to suit your fancy. But you must be prepared for all kinds of compatibility problems, and throwing bad words at others is not an answer either.

I will admit we (Ninho and Japheth) may be pushing things a bit, but a mere trifle compared to your admission of /calling/ int 15/4F. You and we alike are doing non standard stuff, yours more than ours. Together you and us may examine if and how compatibility can be ensured, or the user may have to choose between using our driver or your programs (better, our driver might be unloaded). No case for throwing accusations of idiocy or incompetence at one another.

> E.g., Some of my "keyboard simulation" programs may call INT 15.4F in order
> to make sure they are simulating a valid scancode.

Without seeing the programs in question , I decline to comment.

> I think I've also seen
> references to programs that simulate a Ctrl-Alt-Del through INT 15.4F in
> order to flush the caches of a disk caching program like SMARTDRV

Methinks there are much better ways... SMARTDRV provides an API. Alternatively they could use DOS buffer flushing calls which smartdrv or similar caches intercept.

(...)
>> int 15/4F... should be called /only/ by a BIOS IRQ 1
>> handler (or replacement thereof).

> Not true, as stated above. INT 15.4F is allowed to be called by any
> program at any time.

Bis repetita non placent!


>That is why it is a separate interface and not
> actually required to be part of the INT 9 handler.

Grossly inexact : int15/4F has been part of the AT BIOS/ ISA de facto standard at least since the PC-AT, maybe PC-XT even.

I think we must agree to disagree re. the "philosphical" meaning of int 15/4F.
We could however learn how your program's calls conflict, or not, with our hook.

°°° °° °°° °° °°° °°

Bret's point # 2 :

> Regarding your specific implementation, it has problems. I haven't look at
> all of the details, but your INT 15 handler is incorrect. There are
> programs that "monitor" keystrokes by trapping INT 15.4F. E.g., SMARTDRV
> monitors INT 15.4F for Ctrl-Alt-Del, and flushes its write caches when this
> occurs.

I'm well aware of smartdrv and similar intercepting ctrl-alt-del, in fact I've mentioned it upthread.

I do not blame you for not reading everything ;=)

> Since your program does not chain to the old INT 15 handler, there
> is a potential for drive corruption during a reboot if the user installed a
> disk caching program (like SMARTDRV) before they installed your driver.

KBFR must be installed before Smartdrv for that reason precisely, which I'm doing. Remind me to add a note in the Manual.


> You must chain to the old handler even if you are the one processing the
> INT 15 Request. Because you must chain, there is also the possibility that
> the user has installed more than one INT 15.4F handler (either
> inadvertently or on purpose), which you must handle correctly.

Please note we are chaining (jmping, rather) to the old handler for all int 15, /except/ our 4Fh.

I shall leave it to Japheth to tell his rationale for not chaining.

I considered chaining, chose /not to/ for I couldn't trust other hookers not to modify the initial scan code. There's no problem with hooks which only /examine/ scan codes, our driver just can't tolerate another to /change/ a scan code, otherwise the keyboard behaviour could become erratic and user would put the blame on /us/.

I might reconsider. A compromise would be to call the old handler only on int 15/4F53 (the DEL sc iirc) and then only in ctrl+alt state.

The only case which need really concern me is, indeed smartdrv. Even so, there are situations already (older DOS versions for instance) when Smartdrv will not get ctrl-alt-del notification irrespective of a keyboard driver.


> Your INT 15h handler should look something like this. Note that this is in
> A86 syntax, and is untested, so there might be errors/problems with it, but
> you will hopefully get the idea:
>
> (code snipped for brevity)
]
Oh I get it. A detail, I would rather chain only the 4F case and JMP to the old driver for the general int 15, don't you think so ?


°°° °° °°° °° °°° °°

Phew, this has been long. Hope we can come to an understanding of sorts...

Regards,

---
Ninho

> A NASM example outlining how to construct an IISP header yourself (I
> usually use a macro for that), and with slightly different behaviour.

OK Christian, thank you, good stuff. Shall look it through to morrow (I've just finished answering Bret, took time - browser lost all before I was finished and I had to redo afresh, like happened to somone else recently) it's late and I'm going to sleep now.

---
Ninho

> Note however that it is Japheth's work you're criticising before being
> Ninho's, not that I want to elude responsibility, only I can't reply
> relative to Japheth's own intentions, just my take.

AFAICS I do virtually fully agree with your response, so no need for me to repeat the arguments.

My impression is that Bret is loving dogmas, occasionally.

> I shall leave it to Japheth to tell his rationale for not
> chaining.

It's simple: I'm not a strong believer in democracy.

> The only case which need really concern me is, indeed smartdrv. Even so,
> there are situations already (older DOS versions for instance) when
> Smartdrv will not get ctrl-alt-del notification irrespective of a keyboard
> driver.

Yes, Smartdrv is a little problem. I agree that a note in the documentation is the best "fix".

---
MS-DOS forever!

> AFAICS I do virtually fully agree with your response, so no need for me to
> repeat the arguments.
>
> My impression is that Bret is loving dogmas, occasionally.

Ah, makes sense then ;=)

Well I have just been made aware that mKEYB, the official (right?) k.b.
driver of FreeDOS, is int 15/4F based too. Booted from a FreeDOS floppy
ran > MKEYB FR and indeed it was hooking int 15 and int 2F. Had I known of
it before, I might not have embarked onto this boat

- mKEYB FR uses up 200 bytes more than my KBFR tho :=)

Quick viewing of in-memory mKEYB code further seems to confirm it doesn't
chain int 15/4F.

This being so, Bret's wrath should in good logic be directed at Tom Ehlert
(mKeyb) - we can only assume he was not aware of its existence either...


> Yes, Smartdrv is a little problem. I agree that a note in the documentation
> is the best "fix".

Thank you ! Wishing you a good day

---
Ninho

> Well I have just been made aware that mKEYB, the official (right?) k.b.
> driver of FreeDOS, is int 15/4F based too. Booted from a FreeDOS floppy
> ran > MKEYB FR and indeed it was hooking int 15 and int 2F. Had I known of
> it before, I might not have embarked onto this boat
I had wondered why you started it ;)

> - mKEYB FR uses up 200 bytes more than my KBFR tho :=)
not bad, considering the fact that mKEYB is 98% C, and handles 20 keyboard layouts ;)

> Quick viewing of in-memory mKEYB code further seems to confirm it doesn't
> chain int 15/4F.
that's wrong.
mKEYB chains most of the time, and only handles the (few) scancodes that it wants to modify. most work is done by the BIOS (in particular *both* DEL keys !)

> This being so, Bret's wrath should in good logic be directed at Tom Ehlert
> (mKeyb) - we can only assume he was not aware of its existence either...
IMHO Bret is plain wrong with
'INT 15.4F handler is not allowed to actually "process" any keystrokes
or make any system changes at all (put ASCII codes in the keyboard buffer,
make changes to the BIOS Data Area, etc.).'


> > Yes, Smartdrv is a little problem. I agree that a note in the
> documentation
> > is the best "fix".
the fix is to chain the DEL scancode to the BIOS; no user will ever read documentation ;)


Tom

> MKEYB FR and indeed it was hooking int 15 and int 2F. Had I known of
>> it before, I might not have embarked onto this boat

> I had wondered why you started it ;)

>> - mKEYB FR uses up 200 bytes more than my KBFR tho :=)
> not bad, considering the fact that mKEYB is 98% C, and handles 20 keyboard
> layouts ;)

Sure, I wanted to underline that mkeyb's code must be, i presume, table driven(?) and in any case prepared to handle many languages, while our driver can have optimised instruction flow for the unique keyboard layout.

>> Quick viewing of in-memory mKEYB code further seems to confirm it doesn't
>> chain int 15/4F.

> that's wrong.
> mKEYB chains most of the time, and only handles the (few) scancodes that it
> wants to modify. most work is done by the BIOS (in particular *both* DEL
> keys !)

Sure we want as much of the work as possible to be done by the BIOS, for which we IRET. This is not chaining :
I quick viewed mKEYB in memory (using the disassembler included in McAffe's proview), it didn't appear to /chain/ 154F (as in passing scancodes by calling or jmping to the previously installed int 15 hook). Either I mis-looked or there is a misunderstanding over the notion of chain. Please clarify.

Incidentally I also noticed you use int 16h for stuffing the buffer - I have reservations over such use (we do direct buffer handling); not because of reentrancy nor efficiency problems, but because calling int 16h at that point you don't know /who/ is going to mess with the buffer for good or bad. Either do it ourselves, or we could call the BIOS int 16 at its default entry point (per ISA quasi standard).

>> This being so, Bret's wrath should in good logic be directed at Tom
> Ehlert
>> (mKeyb) - we can only assume he was not aware of its existence either...

> IMHO Bret is plain wrong with
> 'INT 15.4F handler is not allowed to actually "process" any keystrokes
> or make any system changes at all (put ASCII codes in the keyboard
> buffer,
> make changes to the BIOS Data Area, etc.).'

I tried to put it less abruptly :=)

>>> Yes, Smartdrv is a little problem. I agree that a note in the
>> documentation
>>> is the best "fix".
> the fix is to chain the DEL scancode to the BIOS; no user will ever read
> documentation ;)

You have a point...

---
Ninho

> I quick viewed mKEYB in memory (using the disassembler included in McAffe's
> proview), it didn't appear to /chain/ 154F (as in passing scancodes by
> calling or jmping to the previously installed int 15 hook). Either I
> mis-looked or there is a misunderstanding over the notion of chain. Please
> clarify.

_int15_handler:
jnc chain_int15_non_carry

cmp ah,04fh
jne chain_int15

push bx
push cx
push dx
push ds
push es

push cs
pop ds
push ax

call near _cint15_handler_full
pop cx ; pop argument from stack

pop es
pop ds
pop dx
pop cx
pop bx

; scancode if pass down key to BIOS
; 0 if scancode was handled
mov ah,04fh
cmp al,0
jne chain_int15

push bp
mov bp,sp
and byte [bp+6],0feh ; clear carry
pop bp
iret

chain_int15:
stc
chain_int15_non_carry:
db 0eah ; Jump Far
_OldInt15 dd 0


in short words: _cint15_handler_full decides if it has
handled the scancode; if so it returns 0, and the code IRET's
(I even think that this is not correct; it would be better
to clear carry, and chain to the old handler. left as an exercise)

otherwise scancode processing is left to the BIOS. this is true for most
alpha, all shift, cursor, insert, function keys. (however accented alpha
keys are handled by mKEYB)

> Incidentally I also noticed you use int 16h for stuffing the buffer - I
> have reservations over such use (we do direct buffer handling); not because
> of reentrancy nor efficiency problems, but because calling int 16h at that
> point you don't know /who/ is going to mess with the buffer for good or
> bad. Either do it ourselves, or we could call the BIOS int 16 at its
> default entry point (per ISA quasi standard).

I don't know or care who is messing with the buffer.
but it's most likely the same that is also handling the other int16 keyboard
functions, and this is a good thing

besides that, as there exists a documented function
(int 16/5) KEYBOARD - STORE KEYSTROKE IN KEYBOARD BUFFER
for the purpose, most of the time ist's a good idea to use this standard.

> IMHO Bret is plain wrong with 'INT 15.4F handler is not allowed to
> actually "process" any keystrokes or make any system changes at all (put
> ASCII codes in the keyboard buffer, make changes to the BIOS Data Area,
> etc.).'

Let me explain to you where this "fantasy" of mine, that INT 15.4F can be called by any program at any time, came from.

http://support.microsoft.com/kb/67929

After seeing this, I see only three possible conclusions that you can make.

1)
Microsoft is wrong, and INT 15.4F cannot be called from anywhere except inside an INT 09 handler. You must find another way besides INT 15.4F to flush a SMARTDRV or SMARTDRV-compatible cache when rebooting from inside a program.

2)
Microsoft is right, but the ONLY exception to the INT 15.4F rule in conclusion 1 is Ctl-Alt-Del.

3)
(My conclusion) that by logical extension, INT 15.4F can be called by any program at any time for any scancode. INT 15.4F is only supposed to translate or monitor scancodes, not actually process them.

> > IMHO Bret is plain wrong with 'INT 15.4F handler is not allowed to
> > actually "process" any keystrokes or make any system changes at all (put
> > ASCII codes in the keyboard buffer, make changes to the BIOS Data Area,
> > etc.).'
>
> Let me explain to you where this "fantasy" of mine, that INT 15.4F can be
> called by any program at any time, came from.
>
> http://support.microsoft.com/kb/67929
>
this is clearly not "any" program, but a program that reboots the system in a SMARTDRV compatible way


> After seeing this, I see only three possible conclusions that you can
> make.
>

I'm not able to follow your logic.
> 1)
> Microsoft is wrong, and INT 15.4F cannot be called from anywhere except
> inside an INT 09 handler. You must find another way besides INT 15.4F to
> flush a SMARTDRV or SMARTDRV-compatible cache when rebooting from inside a
> program.
KB67929 describes a way to reboot the system in a SMARTDRV compatible way; no reason to doubt that.

MS is most likely right - it's great if you MAKE the standards.
>
> 2)
> Microsoft is right, but the ONLY exception to the INT 15.4F rule in
> conclusion 1 is Ctl-Alt-Del.
which INT 15.4F rule ?

> 3)
> (My conclusion) that by logical extension, INT 15.4F can be called by any
> program at any time for any scancode. INT 15.4F is only supposed to
> translate or monitor scancodes, not actually process
> them.

as already said: I'm not able to follow your reasoning; why exactly should
it not call INT 16.5 (besides common DOS/BIOS reentrancy problems)

> this is clearly not "any" program, but a program that reboots the system in
> a SMARTDRV compatible way

That's true, but the point is it's a program, written by MS, that calls INT 15.4F from outside the INT 09 handler. Ergo, MS thinks it's OK to issue an INT 15.4F from outside the INT 09 handler, at least for Ctl-Alt-Del.

The only question, at least in my mind, is whether MS thinks Ctl-Alt-Del is the ONLY keystroke that can be "simulated" this way from outside the INT 09 handler. Nothing I've ever seen from MS or IBM, including official documents like the IBM Technical Reference, leads me to believe that INT 15.4F can ONLY be called from inside an INT 09 handler. In fact, quite the opposite. This simply seems to be an (incorrect) assumption that a lot of people have been making for a long time, though maybe somebody is privy to something I'm not.

> as already said: I'm not able to follow your reasoning; why exactly should
> it not call INT 16.5 (besides common DOS/BIOS reentrancy problems)

The reason is because if you call INT 16.5, or modify anything in the BDA, or anything like that, but the INT 15.4F did not come from inside the INT 09 handler, you will be "typing" something that didn't actually come from the keyboard. At best, this would be an annoyance to the user. At worst, it could cause catastrophic data loss (depending on exactly what the scancode actually was and what program was running at the time).

***

As I alluded to earlier, the reason I'm so concerned about this issue is because of virtual keyboards, like USB. I have several of these kinds of programs, and I sometimes try to make them automatically "sense" the current keyboard language so that they can "adjust" themselves and make sure that what comes out at the end is what the user is expecting to happen.

Based on everything I've seen from MS, the scancode-to-ASCII "translation" is supposed to occur completely inside the INT 09 handler. The purpose of INT 15.4F is simply to allow the user to move keys around on the keyboard (e.g., switching where the Ctl and CapsLock keys are located), not to actually manipulate what the keys do.

As another example, look in RBIL at how INT 2F.AD80 (the "official" KEYB API) is implemented. The data structure returned by this function includes the old INT 09 vector (which means it expects/requires it to be implemented as INT 09), and includes a two-letter abbreviation for the keyboard language. This two-letter abbreviation is what defines the scancode-to-ASCII translation, and is what other programs are supposed to use to determine the current keyboard language (not necessarily the keyboard layout, which can be manipulated by INT 15.4F, but the keyboard language, which is the scancode-to-ASCII translation).

It should be noted, however, that this is an incomplete solution because it requires a standard two-letter abbreviation for every possible keyboard language. There are several "documented" abbreviations, but anybody who wants to can create their own keyboard language that doesn't exactly match any of the existing ones. That's an issue that should be addressed. but doesn't negate any of the above conclusions.

> > as already said: I'm not able to follow your reasoning; why exactly
> should
> > it not call INT 16.5 (besides common DOS/BIOS reentrancy problems)
>
> The reason is because if you call INT 16.5, or modify anything in the BDA,
> or anything like that, but the INT 15.4F did not come from inside the INT
> 09 handler, you will be "typing" something that didn't actually come from
> the keyboard.
in our case (we are a keyboard driver) the scancode (most likely) comes from the keyboard.

even if 'something' is simulating a keyboard by sending scancodes into
the system by callimg int15.4f, usually the intension is to enter characters into the keyboard buffer.

if this something is sending CtrlAltDel scancodes, it's either an annoyance
or a remote control program - the system will boot anyway.

> As I alluded to earlier, the reason I'm so concerned about this issue is
> because of virtual keyboards, like USB. I have several of these kinds of
> programs
I m not sure, but I guess that sending the scancodes using int15.4f should just work.

I haven't looked at your code, but they should probably send scancodes
using int15.4f. (even better would be to use SMM and simulate a real PS/2
keyboard, but this is beyond tyhe current scope). your driver should handle
the keyboard, and let the scancode->key translation to the keyboard driver.

> and I sometimes try to make them automatically "sense" the
> current keyboard
is there any way to determine the keyboard layout ?

> Based on everything I've seen from MS, the scancode-to-ASCII "translation"
> is supposed to occur completely inside the INT 09 handler. The purpose of
> INT 15.4F is simply to allow the user to move keys around on the keyboard
> (e.g., switching where the Ctl and CapsLock keys are located), not to
> actually manipulate what the keys do.
I doubt that. int16.5 was exactly created to enter keys into the keyboard buffer; no reason not to use it.

just one point: how should the international keyboard driver enter Ä Ö Ü and accented stuff into the keyboard buffer ?
int16.5 was created exctly for this purpose.

> in our case (we are a keyboard driver) the scancode (most likely) comes
> from the keyboard.

Again, that is the point. MS (via their code) says INT 15.4F can come from anywhere, not just from the INT 09 handler.

> even if 'something' is simulating a keyboard by sending scancodes into
> the system by callimg int15.4f, usually the intension is to enter
> characters into the keyboard buffer.

Perhaps usually, but not always. It is also true that the only programs I know of that use INT 15.4F are the SMARTDRV-compatible caches, and the only scancode that is used for this is Ctl-Alt-Del. But that doesn't mean there aren't other programs or other scancodes that do the same thing.

> if this something is sending CtrlAltDel scancodes, it's either an
> annoyance or a remote control program - the system will boot anyway.

Most likely, but not necessarily. It is at least theoretically possible to flush the SMARTDRV caches with INT 15.4F even if you don't intend to reboot. In reality, though, nobody would ever do this -- they would just use the SMARTDRV INT 2F interface instead. BTW, this is yet another justification to assume MS & IBM intended INT 15.4F to be called from anywhere -- the example reboot code from MS could have used INT 2F instead of INT 15, but it didn't.

> I m not sure, but I guess that sending the scancodes using int15.4f should
> just work.

No, because INT 15.4F handlers don't necessarily handle all scan codes. Your program, MKEYB, for instance, does not. It passes the ones it doesn't care about back to the INT 09 handler. And again, I want to reiterate that I don't think INT 15.4F handlers should actually "handle" any scancodes at all.

> I haven't looked at your code, but they should probably send scancodes
> using int15.4f. (even better would be to use SMM and simulate a real PS/2
> keyboard, but this is beyond the current scope). your driver should
> handle the keyboard, and let the scancode->key translation to the keyboard
> driver.

That's basically what it does, but doesn't use SMM. SMM is really, really ugly, and doesn't even exist on older computers.

> is there any way to determine the keyboard layout?

Two different notions here: keyboard language and keyboard layout. The only way I know of to determine the keyboard language is with INT 2F.AD80h. ALL KEYBOARD RE-MAPPING UTILITIES SHOULD SUPPORT THIS FUNCTION, whether they use INT 09 or INT 15.4F. AFAIK, none of the INT 15.4F programs do. They don't need to support it fully, but they at least need to provide the two-letter language abbreviation. This is the only way other programs can know what the current language is.

Determining the keyboard layout, if it is other than the default, can only be done using INT 15.4F, and hoping it doesn't actually process the scancodes. Actually, for my purposes, merely supporting INT 2F.AD80 with a two-letter language ID is enough.

If you add support for INT 2F.AD80 to your program, which I would STRONGLY encourage everyone to do, you really should change it to a "proper" INT 09 interface instead of an INT 15.4F interface at the same time. The only difference between an INT 15.4F interface and an INT 09 interface is the entry/exit "wrapper", which is pretty insignificant.

> I doubt that. int16.5 was exactly created to enter keys into the keyboard
> buffer; no reason not to use it.

Different concepts. INT 09 (IRQ / scancodes / keyboard language), INT 15.4F (keyboard layout), INT 16.5 (ASCII codes). You can call INT 16.5 just as easily from INT 09 as you can from INT 15.4F.