Hi Bret,
>> int 15.4f is supposed to be called from the BIOS from the INT 09
>> handler, and NOBODY else.
>
> I've done some more research regarding this, and it is never stated
> anywhere that this function can ONLY be called from the INT 09
> handler. That is merely an assumption on your part. As a general
> rule, BIOS functions are allowed to be called by any program
> (including IRQ handlers) at any time, and as a result must be
> re-entrant.
I disagree here. You would only need reentrant handling if it
could happen that int 15.4f is called while int 15.4f already
is busy. This is unlikely for two reasons: Int 15.4f usually
takes very little time and it is usually only called by int 9
which in itself cannot be active twice at the same time if it
is a normal classic style IRQ handler.
For example, you could always return with the carry flag clear
immediately ("ignore scan code") when your int 15.4f is already
busy and somebody tries to call it again. From what I get from
the thread here, that "somebody" is likely to be some code that
tries to fake keypresses in preparation for a reboot, so if I
have to guess, that somebody will not even do "error" checking
and the worst that you can get is a less fool-proof reboot than
intended and only if "MS style" software tries to prepare for
a reboot exactly at the moment when the real user presses keys.
> Obviously, MS believes that INT 15.4F can be called from outside INT
> 09, based on what they've published on their web site. 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"
Int 15.4f is not supposed to do anything else than keyboard layout
translations so there is no "far worse". I could imagine that some
really badly written software would fake a control-alt-del INSTEAD
of doing proper cache flushing before rebooting, instead of AFTER
proper cache flushing as a service for weird caches which would in
the belief of MS only watch int 15.4f but not any buffer flush API.
In that context, it is important that caches which do delayed or
pooled writes are not widespread in DOS and typically already do
a flush when any program exits to the DOS prompt or DOS is idle.
> things (Windows, GEM?, GEOS?, many games, ...). If these programs
> call INT 15.4F as is "required", and INT 15.4F actually processes the
> scancode (modifies the BDA, puts keystrokes in the keyboard buffer,
> toggles the LEDs on the keyboard, etc.) and then tells the INT 09
> handler to ignore the scancode, there is a big problem...
It is not the job of int 15.4f to toggle LEDs etc. The standard
way to do that is to manipulate the bits at 40:17 and then call
int 16.1 to give the BIOS a chance to sync with that. Neither
int 9 nor int 15 manipulate the LED in that context, it seems.
To create fake keystrokes, use int 16.5, again avoiding direct
I/O manipulation and staying on the 40:xx keyboard buffer level.
Eric :-)
------------------------------------------------------------------------------
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.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
