DOS ain't dead

Any reason not to use 21.49 now? Not important though.

; 5 - Mark our environment block, if any, FREE :
                mov     CX,DS:[10h+2Ch]
This should be:
; 5 - Mark our environment block, if any, FREE :
                mov     CX,es:[10h+2Ch]
As otherwise, you're accessing the old PSP which as you know is already freed here. (In any case, independently of PSP relocations and critical sections, I still don't get why you don't just free the environment before splitting MCBs and all.)

; 6 - ask DOS for a suitable block; make it owned by system
                mov     BX, (offset EndofInt15) -1
                shr     BX, 4
                inc     BX      ; needed paragraphs
The comment is outdated, because this version of the installer marks the block as self-owned instead. The computation is unnecessarily carried out at run-time. And what I actually wanted to say about this isn't true. (I wasn't aware that ((x-1)>>4)+1 equals (x+15)>>4 except in corner cases but it makes sense if you think about it.)

However, what I noticed there is that you're using additions from the 186 instruction set, which is okay for a 15.4F driver, but it would be better if you actually checked for such a CPU before using those.

---
l

KBFR 1.98 (16,718 bytes)

- fixed bug where a potentially stale pointer would be used (thanks CM)
- refuse to unload under MS-Windows "enhanced", disable instead.
- docs updated.

Since there is little new, I wish to discuss the Windows point for you geeks.

KBFR will work properly with DOS programs run in MS-Windows, whether windowed
or full-screen.

A TSR like this can be either local, per virtual machine (VM), or it
can be global (under DOS-based Windows 3.x, 9x...) being launched
from DOS before Windows itself (by Autoexec.bat for instance).
[It can be forced to be local even in the latter case, if you don't know how just lookup LocalTSRs + NonWindowsApps ]

The interesting point : a local instance of KBFR could be unistalled (removed from memory), independently per VM; but a global one couldn't without Windows "freezing"...

This has to do with "instanciation" - Windows would not mind freeing the global, non instanced, KBFR's memory, but because of the the IVT being "instanced" in WinDOS, the unhooking of KBFR's "int 15" vector would be effective locally only (in the one VM) instantly making int 15 invalid in all other VMS (including the "system" VM).

OK I assume you know about instanciation - the Geoff Chapel whom we had the pleasure to call us here on the forum while FIXWRAP was under study wrote a book chapter about it IIRC.

For the global int 15 to be truly unhooked by Windows the uninstaller would have to use tricks from the Windows DDK and start interacting with the virtual machine manager (VMM) or maybe just using DPMI (I'm unsure the latter can do the trick), which is off limits for a simple DOS TSR like KBFR, and considering the selling price

Detecting whether the resident KBFR is global or not being similarly off-limits, instead I choose to refuse unloading KBFR under Windows regardless, thus preventing 'clueless user' errors ("global" is the recommended setting under WinDOS).

Geeks who want to be able to unload KBFR from a Windows DOS-box and shoot themselves in the foot may compile their own copy with the conditional (at the start of module KBFRINST) disabled

And yes, KBFR does work under NT based windozes (tested with Win 2k), although not really useful there... If someone wants to test, s/he should first ensure the original keyboard driver is set to EN-US in the VDM ('kb16 us'), then load KBFR as usual.

Enjoy... And please report any last minute problems! I intend to make the official release after this version.

---
Ninho