DOS ain't dead

Hospital sent me back home last weekend... I'm uploading the newer better KBFR
before they'll want to see more of me !

KBFR 1.97 (15,931 bytes)

What's new ?

- new int 15/8F API, simpler and future-proof. Cf. KB_API.TXT
- auto load-high (unless 'KBFR C' -> force use of conventional mem only)
- doesn't try to enforce the former "critical" section; properly checks
DOS reported completion status on memory allocation.

Enjoy...

---
Ninho

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

> mov CX,DS:[10h+2Ch][/code]
> 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.

This is a very good catch indeed, Christian! I'm impressed at the quality of your reviewing. This was the kind of hard to pinpoint bug because although not correct in theory the instruction will work... almost always!
It ceased to be correct at some time when the code was shuffled around...
Might have stayed unfixed w/o your help I dare say.

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

OK, comment fixed.

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

The test was omitted as redundant, since we do check for an AT BIOS (using only 8086 instructions). A positive result, it is assumed, guarantees at least a 286, and also that the BIOS int 9 will call down to int 15/4F.

°°°°°°°°

Thank you! Doesn't look far from a final release, after that.

I'm also doing a quick backport as KBGR (German keyboard) provided some Germans are willing to test it in earnest. And a question to start : should it switch between "." and "," (numeric pad) ? What's printed on the key itself, I can't discern on the small image I have of a German kb layout if it's a comma or decimal point there...

---
Ninho

> This is a very good catch indeed, Christian! I'm impressed at the
> quality of your reviewing. This was the kind of hard to pinpoint bug
> because although not correct in theory the instruction will work... almost
> always!
> It ceased to be correct at some time when the code was shuffled around...
> Might have stayed unfixed w/o your help I dare say.

Well I didn't have time to debug it today anyway as I'm preparing things for a longer leave (will be in England from this Sunday til mid-August) so I omitted that. When I review stuff, I always read through the source code though (if provided publicly).

> The test was omitted as redundant, since we do check for an AT BIOS (using
> only 8086 instructions). A positive result, it is assumed, guarantees at
> least a 286, and also that the BIOS int 9 will call down to int 15/4F.

Ah, yeah. I did glance over that check but didn't think through that. I guess that's sufficient then.

> Thank you! Doesn't look far from a final release, after that.

Certainly.

> And a question to start : should it switch between "." and "," (numeric
> pad) ? What's printed on the key itself, I can't discern on the small
> image I have of a German kb layout if it's a comma or decimal point there...

On the keyboards I have around right now, there's commas there (which makes sense as decimal points are instead decimal commas in German) but I'm no keyboard expert and can't tell you whether all German layouts place the decimal comma on that key and/or what the keyboard driver layout and features should be.

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