> We (well, at least I) have a severe dilemma going on here.
let's call it 'disagreement'

>> int 15.4f is supposed to be called from the BIOS from the INT 09
>> handler, and NOBODY else.

> Obviously, MS believes that INT 15.4F can be called from outside
> INT 09, based on what they've published on their web site.
Obviously, MS *support* found a method to reboot a PC from a batch
file in a disk cache flushing way using int15.4f.

the conclusion
   'this funtion can be used to reboot the PC'
   ' therefore it must be fully reentrant'
is a bit overstreching my imagination.

to derive reentrancy of this function

> If INT
> 15.4F is not re-entrant, and the user happens to press (or release)
> a key on the keyboard while the MS code is in process, the computer
> may hang, or do something far worse, instead of rebooting.  You can
> find various references to similar variations of this same "reboot
> code" in multiple places on the Internet.
exactly. reboot the PC.

> However, IBM seems to have a different perspective.  They
> explicitly say in some of their documentation (comments in the PC/AT
> BIOS source code, as well as the PS/2 Technical Reference Manuals)
> that INT 15.4F is allowed to process the scancodes (something which
> up until now, I never thought was allowed).
and that's exactly what mKEYB does. now even with the official
blessing of IBM :)

> Now comes the real dilemma.  RBIL states that IBM classifies INT
> 15.4F as "required".  I don't know where that statement came from (I
> didn't find it in any of the documentation I came across), but I do
> believe IBM actually stated this somewhere.

> The problem with this is when you have a program that provides its
> own INT 09 handler, and doesn't use even use the BDA to keep track
> of things (Windows, GEM?, GEOS?, many games, ...).
in the good old DOS times, there was always enough rope to shoot you
in your feet. many programs were quite successful in this.

> The other issue with an INT 15.4F handler, of course, is that it
> won't directly work with the BIOS on PC's and early-model XT's
right. mKEYB won't work on pre-AT machines. it will work on micro
channel machines, however.

>> no single DOS or BIOS call is 'fully' reentrant

> Actually, all DOS and BIOS functions must be re-entrant in a
> general sense, though you're correct that they don't necessarily
> need to be "fully" re-entrant.  Any resident function (BIOS, DOS, or
> anything else) that can potentially be called from both inside and
> outside an IRQ handler (and there are very few that can't be), or
> anything that can conceivably be called recursively (INT 16h calling
> INT 10h calling INT 16h), must be able to handle the possibility of 
> re-entrancy.

and this was exactly the *art* of TSR programming, because neither DOS
nor BIOS are reentrant.

> Common ways of handling re-entrancy issues are to return an "I'm
> busy -- go away" error (like the InDOS Flag),
could you please lookup the return code for 'I'm busy - go away'
for ANY DOS/BIOS function ?

> provide some sort of
> "context-switching" mechanism (like the DOS Swappable Data Area),
> queue up the requests (which requires a "stack" and call-back
> mechanism of some sort), and full, unadulterated re-entrancy (where
> the "old" process is temporarily halted, the "new" one is handled,
> and then the "old" one is resumed).
is that some sort of 'introduction to multitasking for dummies' ?

> The INT 14h handlers in my DOS
> USB Host Drivers are, in fact, fully re-entrant.
fantastic, but doesn't help INT 13.3

>> that's why it was created in the first place: to free the KEYB
>> implementation from the burden of supporting micro channel machines,
>> where it's not as easy as 'handling INT 09'

> What exactly would you do differently in the INT 09 handler for an
> MCA machine than you would on an ISA machine?  AFAIK, there is no
> difference
interrupt handlers for MCA are different.

btw: AFAICT mKEYB is even reentrant. but that's a total different
story ...


All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
Freedos-user mailing list

Reply via email to