#394 mKEYB 0.46 - different version of KEYB found 5c1003c != d4cb003c

[Oliver]

I found a strange error when unloading mKEYB with the /U parameter after booting FreeDOS 1.3.

REM BOOT BEGIN
...
MODE select codepage 858 function completed
Refreshing codepage number 858
MODE select codepage 858 function completed
mKEYB 0.46 [Oct 09 2021] - GR - GERMAN - deutsche Tastatur (by tom)
...
REM BOOT END
C:\>mkeyb /U
mKEYB 0.46 [Oct 09 2021] - different version of KEYB found 5c1003c != d4cb003c
C:\>

See Screenshot for details.

The two addresses change on another FreeDOS guest machine in my VM.

[fritz.mueller]

I just tested it. This happens when mkeyb is not the last loaded resident driver.
Change the order: ctmouse first, mkeyb last - and it should work.

[Jim Hall]

According to your screenshot, you are loading other drivers after mkeyb. The error message states mkeyb cannot unload because it is not the last loaded driver.

[Aitor Santamaría Merino]

Hello Oliver,

The topic you are raising affects the various "bugs" that you have opened
on (m)KEYB, NANSI, etc., affecting virtually any driver or TSR that chains
through int 2Fh to determine if it is already present in memory.

The common standard way to receive int2Fh calls is to install itself as int
2Fh handler, and pass on the next one when the call is not for you. Thus,
these drivers are stacked, and once you determine that the call is not for
you, you pass to the next one and lose control: you know who to call next,
but not who called you.
Thus, if you are called and you are on the top of the stack (i.e. the int2F
handler points to you), there is no problem: you point the int2Fh to the
next. When you are not (because some other program stacked itself on top of
you), then there is no trivial say to un-link yourself from the chain,
because you don't know where the address pointing you is in memory.

To patch this, some later programs used the AMIS (on int 2Dh interface).
However, programs that use 2Fh, or are forced to use 2Fh for MS-DOS
compatibility, cannot solve it.

I am afraid it is not a bug, bug an undesirable feature. Arguably someone
can make FreeDOS drivers/TSR to never use int 2FH and use AMIs instead, but
this would break MS-DOS compatibility. And furthermore, the gain is small
if you correctly configure your FreeDOS, and thus it is unlikely that
everyone would ever want to implement this.

I hope this closes these bugs. Feel free to open as feature requests to use
AMIS instead of int 2Fh and break MS-DOS compatibility.

Aitor

quoted reply removed

[Aitor Santamaría Merino]

The main problem is cost-benefit. Its just not worth it.
Just configure your AUTOEXEC.BAT properly.

Aitor

quoted reply removed

[Jim Hall]

I am closing this "bug." See Aitor's explanation in the notes.