DOS ain't dead

> Btw., on my keyboard "MKEYB GR" strangely doesn't translate key 0x56 (
> backslash-key on the US keyboard ) - although I can see that the key is
> supposed to be translated. Probably have to compile it on my own.

It turned out that Mkeyb and MS SmartDrv don't like each other. The root of the problem is that MKEYB's Int 15h handler expects the carry flag to be set, else it does nothing. If SmartDrv is loaded AFTER Mkeyb, it also installs an Int 15h handler, to catch Ctrl-Alt-Del. It doesn't care about the the carry flag, and the crucial code is:


cmp ax, 4F53h
jnz prev_handler


That also explains why it's just key 56h that isn't translated, the usual keys have scan codes < 53h.

The simplest fix is to load MKeyb AFTER MS SmartDrv.

---
MS-DOS forever!

> Without the need for "dead keys", extended keys and the like, the situation
> is not longer "VERY complicated". Actually, the approach that I first
> considered seams feasible: to trap keyboard ports 0x60 and 0x64, then feed
> the keyboard driver with a bunch of make codes/break codes combinations and
> see what it makes out of that.

While that may seem feasible, based on experience I would say it probably isn't. There may not even be a keyboard driver installed, and even if there is you can't always tell since many of them don't follow the (incomplete) "standard" the MS used for their driver. There are also certain make/break codes that don't generate ASCII codes at all and if you accidentally simulate one of those you could end up in trouble. Also, with some keyboard drivers you can use INT 15.4F to inject make/break codes while with others you actually need to simulate ports 60h and/or 64h.

Also, you may not really want to depend on the BIOS or DOS keyboard driver from inside a protected mode debugger, anyway.

> Without the need for "dead keys", extended keys and the like, the situation
> is not longer "VERY complicated". Actually, the approach that I first
> considered seams feasible: to trap keyboard ports 0x60 and 0x64, then feed
> the keyboard driver with a bunch of make codes/break codes combinations and
> see what it makes out of that.

I did read it, and I understand what you're trying to do. But I also think you're just going to confuse your users if you don't take into account things like keyboard modes and maybe even things like arrow keys (which includes things like NumLock and Shift-key statuses).