Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Ninho

E-mail

27.04.2011, 13:34
 

int 15/4f French keyboard driver ready + *Ping Japheth* (Developers)

Post reply

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
Japheth

Homepage

Germany (South),
27.04.2011, 16:02

@ Ninho
 

int 15/4f French keyboard driver ready + *Ping Japheth*

Post reply

> ***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!
Ninho

E-mail

27.04.2011, 17:13

@ Japheth
 

int 15/4f French keyboard driver ready + *Ping Japheth*

Post reply

> 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
Japheth

Homepage

Germany (South),
28.04.2011, 07:47

@ Ninho
 

int 15/4f French keyboard driver ready + *Ping Japheth*

Post reply

> 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!
Ninho

E-mail

10.05.2011, 13:30

@ Ninho
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

> 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
Rugxulo

Homepage

Usono,
10.05.2011, 23:52

@ Ninho
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

... (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!)
Ninho

E-mail

11.05.2011, 13:38

@ Rugxulo
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

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.
ecm

Homepage E-mail

Düsseldorf, Germany,
11.05.2011, 19:39

@ Ninho
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

> 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
Ninho

E-mail

12.05.2011, 10:56

@ ecm
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

>> 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
bretjohn

Homepage E-mail

Rio Rancho, NM,
12.05.2011, 17:13

@ Ninho
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

> 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.
Ninho

E-mail

12.05.2011, 22:27

@ bretjohn
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

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
ecm

Homepage E-mail

Düsseldorf, Germany,
13.05.2011, 00:24

@ Ninho
 

AMIS, Optimize memory usage

Post reply

> > 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
Ninho

E-mail

13.05.2011, 01:33
(edited by Ninho, 13.05.2011, 01:46)

@ ecm
 

AMIS, Optimize memory usage

Post reply

(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
ecm

Homepage E-mail

Düsseldorf, Germany,
13.05.2011, 01:45

@ Ninho
 

AMIS, Optimize memory usage

Post reply

> > 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
Ninho

E-mail

13.05.2011, 02:07

@ ecm
 

AMIS, Optimize memory usage

Post reply

> > > 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
ecm

Homepage E-mail

Düsseldorf, Germany,
13.05.2011, 02:39

@ Ninho
 

AMIS, Optimize memory usage

Post reply

> 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
Ninho

E-mail

13.05.2011, 02:58

@ ecm
 

AMIS, Optimize memory usage

Post reply

> > 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...)
Ninho

E-mail

13.05.2011, 02:50

@ Ninho
 

Correction, memory usage

Post reply

>> 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
ecm

Homepage E-mail

Düsseldorf, Germany,
13.05.2011, 03:00

@ Ninho
 

Memory usage, AMIS(!)

Post reply

> 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.
Ninho

E-mail

13.05.2011, 11:57

@ ecm
 

Memory usage, AMIS(!)

Post reply

>> 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
ecm

Homepage E-mail

Düsseldorf, Germany,
13.05.2011, 14:51

@ Ninho
 

Memory usage, AMIS(!)

Post reply

> 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
bretjohn

Homepage E-mail

Rio Rancho, NM,
13.05.2011, 17:43

@ Ninho
 

Memory usage, AMIS(!)

Post reply

> 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.
Ninho

E-mail

13.05.2011, 18:15

@ bretjohn
 

Memory usage, AMIS(!)

Post reply

> 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
Japheth

Homepage

Germany (South),
13.05.2011, 18:58

@ bretjohn
 

Memory usage, AMIS(!)

Post reply

> 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! :-P

> 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!
bretjohn

Homepage E-mail

Rio Rancho, NM,
14.05.2011, 01:42

@ Japheth
 

Memory usage, AMIS(!)

Post reply

> 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.
Ninho

E-mail

14.05.2011, 11:38
(edited by Ninho, 14.05.2011, 11:50)

@ bretjohn
 

Memory usage, AMIS(!)

Post reply

>> 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
Ninho

E-mail

14.05.2011, 11:41

@ Ninho
 

Sorry error :) - No contents - Ignore

Post reply

empty
bretjohn

Homepage E-mail

Rio Rancho, NM,
15.05.2011, 17:26

@ Ninho
 

Memory usage, AMIS(!)

Post reply

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
ecm

Homepage E-mail

Düsseldorf, Germany,
15.05.2011, 18:30

@ bretjohn
 

Int15 handler example: IISP; chain other functions directly

Post reply

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
Ninho

E-mail

16.05.2011, 03:49

@ ecm
 

Int15 handler example: IISP; chain other functions directly

Post reply

> 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
Ninho

E-mail

15.05.2011, 20:57

@ bretjohn
 

Memory usage, AMIS(!)

Post reply

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
Ninho

E-mail

16.05.2011, 03:35
(edited by Ninho, 16.05.2011, 03:51)

@ bretjohn
 

In reply to Bret - int 15/4F stuff

Post reply

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
Japheth

Homepage

Germany (South),
16.05.2011, 10:18

@ Ninho
 

In reply to Bret - int 15/4F stuff

Post reply

> 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. :-P

> 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!
Ninho

E-mail

16.05.2011, 12:19
(edited by Ninho, 16.05.2011, 12:49)

@ Japheth
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> 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. :-P

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
tom

Homepage

Germany (West),
16.05.2011, 13:35

@ Ninho
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> 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
Ninho

E-mail

16.05.2011, 15:10

@ tom
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> 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
tom

Homepage

Germany (West),
16.05.2011, 17:13

@ Ninho
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> 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.
bretjohn

Homepage E-mail

Rio Rancho, NM,
16.05.2011, 19:50

@ Ninho
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> 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.
tom

Homepage

Germany (West),
16.05.2011, 21:06

@ bretjohn
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> > 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)
bretjohn

Homepage E-mail

Rio Rancho, NM,
17.05.2011, 18:10

@ tom
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> 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.
tom

Homepage

Germany (West),
17.05.2011, 19:47

@ bretjohn
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> > 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.
bretjohn

Homepage E-mail

Rio Rancho, NM,
18.05.2011, 02:09

@ tom
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> 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.
Japheth

Homepage

Germany (South),
18.05.2011, 06:47

@ bretjohn
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> 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.
I don't think this idea will work - at least not when EMM386 is loaded. The MS tool:


   MOV AH,0D                 ; Disk Reset
   INT 21h                   ; causes SmartDrv 4.x to write cache
   MOV AX, 40                ; set up segment addressing
   MOV DS, AX
   DS:
   OR  BYTE PTR    [17],0C   ; equivalent of pressing CTRL+ALT
   MOV AX,4F53               ; Issue a "DEL" (53h = DEL scan code)
   INT 15h                   ; EMM386 sees this & shuts down
   DS:
   MOV WORD PTR [72],1234    ; Set REBOOT flag to Warm-Boot (0=cold)
   JMP F000:FFF0             ; Execute the internal restart routine


uses int 15.4F53 to "shut down" EMM386 ( note that int 21h is used to clear the cache ). If EMM386 detects int 15h.4f53, it will reboot immediately and won't return - because it could do this only if no EMS or UMBs are supplied - which is a very rare case.

---
MS-DOS forever!
bretjohn

Homepage E-mail

Rio Rancho, NM,
18.05.2011, 19:08

@ Japheth
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> > 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.
>
> I don't think this idea will work - at least not when EMM386 is loaded. The
> MS tool:
>
>
> MOV AH,0D                 ; Disk Reset
> INT 21h                   ; causes SmartDrv 4.x to write cache
> MOV AX, 40                ; set up segment addressing
> MOV DS, AX
> DS:
> OR  BYTE PTR    [17],0C   ; equivalent of pressing CTRL+ALT
> MOV AX,4F53               ; Issue a "DEL" (53h = DEL scan code)
> INT 15h                   ; EMM386 sees this & shuts down
> DS:
> MOV WORD PTR [72],1234    ; Set REBOOT flag to Warm-Boot (0=cold)
> JMP F000:FFF0             ; Execute the internal restart routine
>
>
> uses int 15.4F53 to "shut down" EMM386 ( note that int 21h is used
> to clear the cache ). If EMM386 detects int 15h.4f53, it will reboot
> immediately and won't return - because it could do this only if no EMS or
> UMBs are supplied - which is a very rare case.
You're correct -- I had the SMARTDRV part confused with the EMM386 part. This still doesn't negate the fact that MS thinks it's OK to call INT 15.4F from outside INT 09, though they may think it's OK only when you're about to shut down or reboot.

This code is supposed to work whether EMM386 is installed or not, so it must assume that if EMM386 is installed, EMM386 will do the rebooting, and if EMM386 isn't installed, INT 15.4F will simply return and this code must do the rebooting itself.

I don't know if anybody has recognized this yet, but for this code to work properly, INT 15.4F must be fully re-entrant (at least if EMM386 is not being used). If not, this code could get "stuck" if a real keystroke is being processed at the same time this code is trying to reboot. That is, the machine will simply hang (or possibly do something else really nasty that the user doesn't want), and not actually reboot.
tom

Homepage

Germany (West),
18.05.2011, 12:35
(edited by tom, 18.05.2011, 13:01)

@ bretjohn
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

after looking into your code, I see that you simulate keypresses
using the keyboard controller
;FAKE A KEYBOARD KEYSTROKE USING METHOD 2 (WORKS WITH MOST AT KEYBOARDS)

IMHO this is exactly the way your code should work, and will work nicely
both with the default BIOS, and with existing international keyboard drivers

> 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.
there is no such thing as a'keyboard language'.
INT 2F.AD80h reports the 'language' of the keyboard *driver*

there is also no such thing as a 'keyboard layout'.
hitting the key between 'T' and 'U' produces the exact same scancode
on each keyboard in known universe;
it's translated to'Y' in america, and to 'Z' in germany.
not the 'Y' or 'Z' keys are are changed in the layout, they were only
labeled different, and are transleated accordingly by the keyboard driver.


>ALL KEYBOARD RE-MAPPING UTILITIES SHOULD SUPPORT THIS FUNCTION,
> whether they use INT 09 or INT 15.4F.
why would I even install a keyboard driver if the translation is done by
USBKEYB ?

> AFAIK, none of the INT 15.4F programs do.
what's even the relation of int15.4f to int2f.ad80 ?

> This is the only way other programs can know what the
> current language is.
 'other programs' shouldn't care if this is written using a german or US keyboard. this is called an 'abstraction'.

BTW: simulating a keyboard interrupt, and then single stepping it to
modify scancodes is an heroic attempt to solve the problem, but probably overkill
bretjohn

Homepage E-mail

Rio Rancho, NM,
18.05.2011, 18:14

@ tom
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> ;FAKE A KEYBOARD KEYSTROKE USING METHOD 2 (WORKS WITH MOST AT KEYBOARDS)
>
> IMHO this is exactly the way your code should work, and will work nicely
> both with the default BIOS, and with existing international keyboard
> drivers
In my experience, Method 2 has NEVER worked reliably on ANY of my test computers. It completely locks up some computers, especially older ones. I have even considered removing it as an option since it is so unreliable, but I keep it because it might work for others even though it never has for me.

Method 1 is the best one to use if the BIOS HW supports it. The Method 1 function should exist on all modern hardware, but it doesn't, especially on laptops. Method 3 is the only one that even has a chance of working on all computers, but even it doesn't work all of the time -- sometimes it needs the BIOS INT 09 code replaced (which is what MS KEYB does).

> there is no such thing as a 'keyboard language'.
> INT 2F.AD80h reports the 'language' of the keyboard *driver*
You're correct there. Drivers are all we can talk about, since the KB HW never lets you know what it looks like, and (on most keyboards) you can physically move the printed parts of the keys around so they are located wherever you want them to be.

RBIL (and probably MS) refers to it as a country, I prefer to call it a keyboard language. Calling it a country doesn't really make sense, because, e.g., there are two different layouts for Brazil (and Italy and others), but there is only one of each of those countries. Also, even though I live in the country of USA, I sometimes load a driver for one of the Brazilian keyboard languages when I need to type a lot of accented characters. The physical layout of the Brazilian keyboard driver language is exactly the same as the US keyboard, but the Brazilian keyboard language has dead keys that make it much easier to type accented characters.

We can call it a "keyboard driver language" instead of a "keyboard language", or something else, if you prefer. Whatever you want to call it, it is the concept of how scancodes are translated into ASCII codes. Further down, you call it an abstraction, and we can use that term if you want to next time.

> there is also no such thing as a 'keyboard layout'.
> hitting the key between 'T' and 'U' produces the exact same scancode
> on each keyboard in known universe;
> it's translated to 'Y' in america, and to 'Z' in germany.
> not the 'Y' or 'Z' keys are are changed in the layout, they were only
> labeled different, and are transleated accordingly by the keyboard driver.
Quoting INT 15.4F from RBIL: "called by INT 09 handler to translate scan codes" ... "This permits software to rearrange the keyboard; for example, swapping the CapsLock and Control keys" ...

What would you prefer to call this, if not a "keyboard layout"? BTW, RBIL never says, or even implies, that INT 15.4F can be used to change the keyboard driver language (or abstraction or whatever it is you choose to call it).

> what's even the relation of int15.4f to int2f.ad80 ?
INT 2F.AD80, and the other INT 2F.AD8x functions, are how keyboard language drivers are supposed to interface with the "outside world" (the OS itself and other programs). They aren't supposed to be related, because INT 15.4F isn't supposed to have anything to do with the keyboard driver language. Because your (and other) drivers are acting as "KEYB surrogates" using INT 15.4F to "create" a keyboard language driver, however, they must use INT 15.AD8x to let the rest of the world know that they are installed and what keyboard driver language is currently being used.

Look at the other INT 2F.2D8x functions in RBIL. E.g., it is possible for the user (or a program) to request a change in the code page any time they want to. KEYB (and KEYB surrogates) are supposed to monitor and respond to INT 2F.AD81, which is (or at least is supposed to be) called by MS DISPLAY.SYS (or whatever the DISPLAY.SYS surrogates are in the various DOS versions). If the user (or a program) tries to change the code page to one your driver doesn't support, and you don't respond appropriately, you could be in trouble. If you don't monitor INT 2F.2D81, you must instead poll the system to determine the current code page each time you perform a scancode-to-ASCII translation, at least for ASCII characters > 127.

KEYB surrogates are also supposed to respond to INT 2F.AD82 & 2F.AD83 to be able to report and toggle themselves between the "foreign" keyboard driver language and the default (US) keyboard driver language (this basically turns the driver on and off). If the keyboard driver language supports multiple sub-mappings (e.g., the Greek keyboard driver language has a "Greek mode" and a "Latin mode"), the driver must monitor and support INT 2F.AD84 & 2F.AD85 to be able to toggle between the sub-mappings.

I know RBIL refers to these functions as specifically related to KEYB.COM, but they are in reality "system level" calls that the OS and other drivers (like DISPLAY.SYS) depend on for compatibility. KEYB surrogates must also support them.

> 'other programs' shouldn't care if this is written using a german or US
> keyboard. this is called an 'abstraction'.
RBIL certainly doesn't call it an abstraction -- they call it a country, and I'm pretty sure they get that language from MS and/or IBM. But we can call it an abstraction if you want to -- it doesn't change the concept or separation that is there between what INT 09 is supposed to do and what INT 15.4F is supposed to do.

> BTW: simulating a keyboard interrupt, and then single stepping it to
> modify scancodes is an heroic attempt to solve the problem, but probably
> overkill
As stated earlier, it's the only method I've found that even comes close to working reliably on all computers. I consider SMM overkill, but it may come to that someday the way the hardware is changing. I'm not 100% sure about this, but I don't think SMM is emulated in virtual machines, either.

BTW, the single-stepping method is what at least some of the commercial DOS remote control programs used (Carbon Copy, CO/Session, LapLink, etc.).
tom

Homepage

Germany (West),
19.05.2011, 15:32
(edited by tom, 19.05.2011, 15:51)

@ bretjohn
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> > ;FAKE A KEYBOARD KEYSTROKE USING METHOD 2 (WORKS WITH MOST AT
> KEYBOARDS)
> >
> > IMHO this is exactly the way your code should work, and will work nicely
> > both with the default BIOS, and with existing international keyboard
> > drivers
>
> In my experience, Method 2 has NEVER worked reliably on ANY of my test
> computers. It completely locks up some computers, especially older ones.
>> Method 1 is the best one to use if the BIOS HW supports it.
you are the expert here.
my own experience with scancode stuffing is ~15 years ago, and just worked
(on the few computers I tested it).
it might as well have been METHOD 1, I simply don't remember.

> The Method 1
> function should exist on all modern hardware, but it doesn't,
> especially on laptops.
to bad. however only few laptops have a USB keyboard anyway...
I'm sometimes a bit rude to machines, and simply ignore them. YMMV


> Quoting INT 15.4F from RBIL: "called by INT 09 handler to translate
> scan codes" ... "This permits software to rearrange the keyboard; for
> example, swapping the CapsLock and Control keys" ...
 scancode -> ascii translation is a bit more complicated then swapping
CapsLock keys.

> If the user (or a program) tries to change the code page to one
> your driver doesn't support, and you don't respond appropriately, you
> could be in trouble. If you don't monitor INT 2F.2D81, you must instead
> poll the system to determine the current code page each time you perform a
> scancode-to-ASCII translation, at least for ASCII characters > 127.
agreed. mKEYB is lazy in this regard, and ignores codepages completely.
(the 'm' stands for 'mini')

the 'official' FreeDOS KEYBhandles codepages (for a bazillion languages)
but is a bit larger. I'll stick with mKEYB.




>
> KEYB surrogates are also supposed to respond to INT 2F.AD82 & 2F.AD83 to be
> able to report and toggle themselves between the "foreign" keyboard driver
> language and the default (US) keyboard driver language (this basically
> turns the driver on and off).
mKEYB supports this.
Rugxulo

Homepage

Usono,
19.05.2011, 22:42
(edited by Rugxulo, 21.05.2011, 00:58)

@ tom
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> > If the user (or a program) tries to change the code page to one
> > your driver doesn't support, and you don't respond appropriately, you
> > could be in trouble. If you don't monitor INT 2F.2D81, you must instead
> > poll the system to determine the current code page each time you perform
> a
> > scancode-to-ASCII translation, at least for ASCII characters > 127.
>
> agreed. mKEYB is lazy in this regard, and ignores codepages completely.
> (the 'm' stands for 'mini')
>
> the 'official' FreeDOS KEYBhandles codepages (for a bazillion languages)
> but is a bit larger. I'll stick with mKEYB.
<boring useless trivia nobody cares about but me>

Just for the record (though it doesn't majorly matter), to change the currently selected "display" codepage:

MS-DOS, DR-DOS: int 21h 440Ch 6Ah
MS-DOS, FreeDOS: int 2Fh, 0AD02h

Yes, int 2Fh 0AD02h is "documented" in RBIL, but it's the low-level (hidden) interface, I think. FreeDOS doesn't support the other way because that's IOCTL and their DISPLAY is an TSR (.EXE), not a device driver (.SYS) (and Aitor is strict about that separation).

Long story short, for ultimate compatibility, you'd (in theory) want to support both. BUT, in reality, it's almost impossible to write for what you can't test (and although DR-DOS is fairly cheap, it ain't free nor libre, which I'm sure lessens its appeal greatly).

So whatever, don't worry about it too hard. But the moral of the story is you have to test everywhere and not blindly rely on what you think, as even RBIL is underdocumented or incorrect in a few places. (It didn't mention DR-DOS specifically here anyways, plus cp853 is undocumented for them, has a bug/missing char, and it's not "Latin-2" but instead Latin-3. Apparently nobody ever cared to support all Latin 1-4 despite them being designed at the same time. So much for standards, esp. obsolete ones, heh.)

</boring useless trivia nobody cares about but me>

EDIT: Corrected accidental error, sorry for the confusion.
Ninho

E-mail

19.05.2011, 23:41
(edited by Ninho, 20.05.2011, 12:18)

@ Rugxulo
 

Keyboard, codepages...

Post reply

Hi !

Like mKEYB, I don't even think of supporting codepages.
That CP stuff is not any good anyway, IMO (and pun intended) .

Alright, for a Chinese or a Russian locale, it might be necessary,
but for a French DOS system it's totally useless bloat. Perso I never load
any of the localisation stuff on my PCs or those of the people I advise,
except for "country.sys" (and then I have my own slim cntryfr.sys).

I'm interested in your advices : do you (not just Rugx, you all!) think a French
PC needs *any* of the codepage stuff ? In my experience it is useless bloat,
and even nefarious (MS assumes the French want to use CP 850, but in fact the
alternate CP 437 is perfect for us, and anyway 99.99999% of all DOS
programs assume CP 437, or rather ignore "code pages" completely, which is
practically the same as assuming 437 <G> )

---
Ninho
ecm

Homepage E-mail

Düsseldorf, Germany,
20.05.2011, 14:09

@ Rugxulo
 

FreeDOS DISPLAY (TSR vs. device driver?)

Post reply

See in this new thread here.

---
l
Ninho

E-mail

19.05.2011, 23:59

@ tom
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

>
>> If the user (or a program) tries to change the code page to one
>> your driver doesn't support, and you don't respond appropriately, you
>> could be in trouble. If you don't monitor INT 2F.2D81, you must instead
>> poll the system to determine the current code page each time you perform
> a
 >> scancode-to-ASCII translation, at least for ASCII characters > 127.

> agreed. mKEYB is lazy in this regard, and ignores codepages completely.
> (the 'm' stands for 'mini')
Don't let him persuade you, it would be sad :(

His confusion comes from not realising that int 15 is a BIOS function,
while int 2F is an OS thing. Int 15/4F, which is a mere "subroutine" of
int 9, so to say, has nothing to do and especially nothing to know about
MS-DOS in general and its int 2F in particular. It would be very wrong !

Of course due to MS DOS history and "design" (not designed, it's
patched, as someone has remarked), people have been used to mixing BIOS
calls with DOS calls as if they were part of the same set (I no less than
anybody else). But they are not the same !

mKEYB is absolutely correct IMO not supporting MS-DOS CP, and if users want
or need CP, they should use another driver. Like my KBFR won't support CP.

>
> the 'official' FreeDOS KEYBhandles codepages (for a bazillion languages)
> but is a bit larger. I'll stick with mKEYB.

And I with KBFR. :=)

Regards
>
> >
> > KEYB surrogates are also supposed to respond to INT 2F.AD82 & 2F.AD83 to
> be
> > able to report and toggle themselves between the "foreign" keyboard
> driver
> > language and the default (US) keyboard driver language (this basically
> > turns the driver on and off).
> mKEYB supports this.

---
Ninho
tom

Homepage

Germany (West),
20.05.2011, 00:49

@ Ninho
 

In reply to : Bret 'll have to hate FreeDOS mKEYB, too

Post reply

> > agreed. mKEYB is lazy in this regard, and ignores codepages completely.
> > (the 'm' stands for 'mini')
>
> Don't let him persuade you, it would be sad :(
> ...
> mKEYB is absolutely correct IMO not supporting MS-DOS CP,

I wouldn't call it 'correct' in a strict sense. codepages are an very useful concept for the people that use them (kyrillic/japanese/chinese/...).

ignoring it is just a shortcut that mKEYB took to save some runtime memory -
and programmers time.

and this won't change (that's not a bug, it's a feature) ;)
Ninho

E-mail

18.05.2011, 15:41
(edited by Ninho, 18.05.2011, 15:56)

@ bretjohn
 

In reply to Bret...

Post reply

> Again, that is the point. MS (via their code) says INT 15.4F can come from
> anywhere, not just from the INT 09 handler.
Their "knowledge base" article and piece of code are a "cooking recipe" aimed at your typical "systems administrator", not reference material. Not so bad however.

>> 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.
It is unclear from your writings whether you believe that the MS reboot program issues int 15/4F with the intent of flushing smartdrive's cache ? This is not the case. It is the int 21/0D function that causes Disk caching programs, including but not limited to "smartdrive compatible", you forgot Drivespace, network redirectors...to flush dirty buffers to disk.

But the purpose of issuing int 15/4F53 is to give notification of impending reboot to internal (and any add on) components which need a chance to clean-up before reboot. Smartdrv, DrvSpace and other standard systems components hook that, as do memory managers (not just EMM386! UMB managers like UmbDrvr or UMBPCI... must hook this too)

I belieeve one important aspect of int15/4F53 control-alt-del processing is DOS IO.SYS itself restores the original BIOS interrupts that it preserved very early in its sysinit module(including int 13h!).

Really, the control alt del case of int 15/4F is very specific and indeed, when you call it (as you may indeed, like the MS reboot mini utility does), it is not even likely to return from the call... did you understand this ? In the case it /does/ return to you, you had better initiate the soft reboot yourself immediately, as trying to continue processing would be hazardous.

Oh, and I hope you'll be pleased with it, following up to this discussion, I've updated KBFR to chain int 15/4F53 to previous handler (in control-alt state only) I have no intention ti chain arbitray scan code events however.
Is this enough to make you (rather, your programs) happy ?


>> 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.

No !!!! Don't do that !!!! Explained above.

> 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.
You are confirming you don't understand the real purpose of int 15/4F in that smallish MS sample.


> 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.
int 2F/AD is not part of a standard at all, it's an /internal/, private interface. It is not used by many non MS keyboard drivers, and it was not used by older MS Keyb.com either !

Anyways, there is no way to "determine the keyboard layout". It could have been part of the IBM AT keyboard ID interface, unfortunately it isn't.

> If you add support for INT 2F.AD80 to your program, which I would STRONGLY
> encourage everyone to do
There is IMHO no reason to support that private MS keyboard interface in a non MS driver.

, 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.
False ! There's all the communication with the hardware, not only the interrupt and keyboard controllers, hardware initialisation, protocol management (error/resend), keyboard LEDs, just to scratch the surface. All this is done, and welldone, by the BIOS IRQ1 handler, it does not have its place in a driver which seeks to minimise overhead.


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

In reply to Tom : using it will save a few bytes, sure. The price maybe some lag, more seriously : we have no way to know what f^cker hooked int 16. A securer possibility is to call the /original/ int 16 at F000:E82E .
End of reply to Tom.


> 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.

---
Ninho
ecm

Homepage E-mail

Düsseldorf, Germany,
18.05.2011, 20:35

@ Ninho
 

DOS IO kernel part hooking Int15.4F ?

Post reply

> I believe one important aspect of int15/4F53 control-alt-del processing is
> DOS IO.SYS itself restores the original BIOS interrupts that it preserved
> very early in its sysinit module (including int 13h!).
I think you're confusing this with Int19. (And even then, restoring interrupts properly is only necessary for "fast rebooting".)

---
l
Ninho

E-mail

18.05.2011, 22:41

@ ecm
 

DOS IO kernel part hooking Int15.4F ?

Post reply

Hi Christian !

>> I believe one important aspect of int15/4F53 control-alt-del processing
> is
 >> DOS IO.SYS itself restores the original BIOS interrupts that it
> preserved
 >> very early in its sysinit module (including int 13h!).
>
> I think you're confusing this with Int19. (And even then, restoring
> interrupts properly is only necessary for "fast rebooting".)
Hmmmh... I may be confused on this detail - I wrote "I believe" 'cause I wasn't so sure in fact, can't check now yet; but I believe you.

Fortunately I don't think it invalidates my other points to Brett, main point being that int 15/4F53 (when issued with control/alt state active) has much broader effects than a mere flushing of smartdrive's buffers, although of course, disk caches will hook that function among others as a last chance for them to flush dirty buffers before a reboot :=)

---
Ninho
ecm

Homepage E-mail

Düsseldorf, Germany,
18.05.2011, 22:48

@ Ninho
 

DOS kernel, Int15.4F

Post reply

> I wrote "I believe" 'cause I wasn't so sure in fact,
Yeah, I noticed.

> Fortunately I don't think it invalidates my other points to Bret,
As I said, I'm not an expert on these keyboard handling things. So I won't discuss any of that in detail.
tom

Homepage

Germany (West),
19.05.2011, 15:15
(edited by tom, 19.05.2011, 15:42)

@ Ninho
 

In reply to Bret...

Post reply

> In reply to Tom : using it will save a few bytes, sure. The price
> maybe some lag, more seriously : we have no way to know what f^cker hooked
> int 16. A securer possibility is to call the /original/ int 16 at F000:E82E
I disagree. the keyboard is consumed by calling INT16.0/1/10/11 and NOT by
calling the original at F000:E82E. as I want to feed *this* interface,
it's probably a good idea to call int16, and not the original f000:E82E

If someone else hooks int16, it hopefully serves a useful service.
Ninho

E-mail

19.05.2011, 19:27

@ tom
 

In reply to \\\ Tom...

Post reply

> I disagree.
I won't take offense, this point is disputable (and non essential).

>the keyboard is consumed by calling INT16.0/1/10/11 and NOT by
> calling the original at F000:E82E. as I want to feed *this* interface,
From a regular program, no doubt. But from a national keyboard driver ?
This is a BIOS extension [ideally, the French or whichever keyboard driver
would be in ROM, as it was indeed the case with certain good quality PC XTs
and ATs before "compatibles" became a commodity driven towards low
quality, low cost].

Looking at various ROM BIOSes, generally they /don't/ call down int 16
(why would they?). Instead they call the kb buffer management subroutines
directly, or else inline.

Why then would the user of our replacement keyboard driver have to be
subject to a random int 16 replacement inside of the BIOS int 9
processing, whereas a user who is able to use the (presumably) American
built-in doesn't ? Seems illogical to me.


> it's probably a good idea to call int16, and not the original f000:E82E
>
> If someone else hooks int16, it hopefully serves a useful service.
Yep, but a service to programs, not a service to the BIOS.

---
Ninho
Japheth

Homepage

Germany (South),
13.05.2011, 07:28

@ Ninho
 

AMIS, Optimize memory usage

Post reply

> 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!
Ninho

E-mail

13.05.2011, 11:27

@ Japheth
 

AMIS, Optimize memory usage

Post reply

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
ecm

Homepage E-mail

Düsseldorf, Germany,
13.05.2011, 00:24

@ bretjohn
 

AMIS, No flaming

Post reply

> 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
ecm

Homepage E-mail

Düsseldorf, Germany,
13.05.2011, 00:24

@ Ninho
 

AMIS

Post reply

> 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
Ninho

E-mail

13.05.2011, 02:21

@ ecm
 

AMIS

Post reply

> > 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
ecm

Homepage E-mail

Düsseldorf, Germany,
13.05.2011, 03:23

@ Ninho
 

AMIS, Ciriaco

Post reply

> 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
Ninho

E-mail

13.05.2011, 12:16

@ ecm
 

AMIS, Ciriaco, Ralph ?

Post reply

>> 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
Rugxulo

Homepage

Usono,
11.05.2011, 20:12

@ Ninho
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

> 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. :-P
Ninho

E-mail

12.05.2011, 10:36

@ Rugxulo
 

int 15/4f French keyboard driver ready + Now what? *

Post reply

>>> ... (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
Back to index page
Thread view  Board view
22773 Postings in 2122 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum