(Win64) AltGr issues when using MS-DOS

[hb9tst]

Describe the bug I'm using an hardware Swiss French keyboard, which —as many international keyboards— requires the use of AltGr for extended keys (including essential ones, like \ or {). When using the integrated command prompt fom DosBox-X, the AltGr (right alt) key properly works, and is not equivalent to Ctrl+Alt. When using MS-DOS 6.22 inside DosBox-X and the MS-DOS keyboard layout driver (keyb), everything works fine except AltGr, which seems to be mapped to Ctrl+Alt.

To Reproduce

1. Install MS-DOS 6.22 on a disk image, configuring Swiss French keyboard during setup
2. Boot the disk image
3. Try entering a backslash (AltGr + the key on the left of the Y, see Swiss keyboard layout)

Expected behavior AltGr should be deteced by MS-DOS as right Alt, not as Ctrl+Alt. Using the latter to insert a backslash generates a ^\ escape code (even in DosBox DOS integrated interface, where it is displayed as ∟, i.e. character code 28 on CP437).

Environment

• PC with Swiss keyboard, configured as Swiss French
• DOSBox-X release 0.83.13, SDL2 build, 64-bit (VS build) on Windows 10
• Happens with default configuration file

Screenshot

[Wengier]

The AltGr key was discussed in some earlier threads, and I heard some report(s) that it worked in SDL2 build, but I don't have the equipment to test this one myself. Can @rderooy confirm this? Thanks.

[rderooy]

@Wengier I tested it only in the dosbox-x prompt. He is saying it is broken with the SDL2 build when booting MS-DOS, which I did not test.

[Wengier]

@rderooy I see. But could @hb9tst describe it more clearly if the issue also happens in the DOSBox-X prompt, or it is specific to booting MS-DOS? Thanks.

[rderooy]

@Wengier he says, it does not happen at the DOSBox-X SDL2 prompt.

But I did a quick test from Linux with PC-DOS 2000 with "sf" keyboard layout on the host and in DOS, and it seemed that Alt-Gr did not trigger the issue. For instance alt-gr E gave the Euro symbol. and alt-gr by itself did nothing. So I guess there must be something else.

@hb9tst can you share which DOS version and config/autoexec you used?

[hb9tst]

@rderooy I tried MS-DOS 6.22 (Italian localization, but I guess the language wont make any difference).

The configuration files are below. They are almost identical to how the MS-DOS setup created them (except for the TEMP/TMP environment and the SMARTDRV moved after the @echo off).

CONFIG.SYS

DEVICE=C:\DOS\SETVER.EXE
DEVICE=C:\DOS\HIMEM.SYS
DOS=HIGH
COUNTRY=041,,C:\DOS\COUNTRY.SYS
DEVICE=C:\DOS\DISPLAY.SYS CON=(EGA,,1)
FILES=30

AUTOEXEC.BAT

@ECHO OFF
C:\DOS\SMARTDRV.EXE /X
PROMPT $p$g
PATH C:\DOS
SET TEMP=C:\TEMP
SET TMP=C:\TEMP
MODE CON CODEPAGE PREPARE=((850) C:\DOS\EGA.CPI)
MODE CON CODEPAGE SELECT=850
KEYB SF,,C:\DOS\KEYBOARD.SYS

My physical keyboard and config on Windows 10 are Swiss French too, if it can make a difference.

I can upload my MS-DOS disk image somewhere if it is of some use.

[rderooy]

I did an install of MS-DOS 6.22, and selected Country Switzerland and Keyboard Swiss-French.

After booting the image, the keyboard appears to work just fine. This is with the latest DOSBox-X SDL2 0.83.14.

So I'm wondering, since I'm running Linux and its working fine, and your using Windows, if that has something to do with it.

My host keyboard layout makes no difference, setting it to Swiss-French, or not, has no effect on the keyboard layout in DOSBox-X. But this is not surprising since DOSBox-X on Linux does not try to detect the host keyboard layout, like it does on Windows.

p.s. loading smartdrv is not needed in DOSBox-X. Your host OS does a better job at caching than smartdrv, so your just wasting ram, and causing potential compatibility problems with some programs.

[hb9tst]

@rderooy I hope to have some time in the next days to try on Linux to confirm that the bug is specific to Windows. By the way thanks for the hint about SMARTDRV, perfectly makes sense.

[hb9tst]

@rderooy I confirm that this problem does not happen on Linux, the same installation works perfectly. The issue seems to be Windows specific (I couldn't test on MacOS as I only have 10.14 for compatibility reasons with some 32-bit software, and DOSBox-X only supports from 10.15 on...).

[Wengier]

@hb9tst I posted macOS builds built with macOS 10.13 a few days ago in another thread. Can you check it out and see if it works on your macOS 10.14?

• dosbox-x-macosx-x86_64-10_13.zip

[rderooy]

I'm thinking of 2 possible causes for this, @Wengier has perhaps a better idea since he is more familiar with windows.

• some kind of other software that you have installed is causing issues.
• the host keyboard autodetect is causing issues, perhaps some kind of double translation going on?

[hb9tst]

@Wengier Thanks for the MacOS 10.13 build! Needless to say, the bug doesn't appear there...

On both Mac and Linux, I used DOSBox-X without a config file. The default layout of keyboard when opening it was US, I had to type keyb sf to get the proper layout. However on Windows (I updated to the latest released 0.83.14 meanwhile), even if I disable keyboard layout autodetection, or set it to us, or remove the configuration file altogether, the issue is always present. @rderooy I don't think that a software I run might be creating the bug, as I don't see why it would only create problems once I load MS-DOS and not in the default DOSBox-X command prompt... the double translation explanation seem much more pertinent in my opinion, but not having ever read anything of the source code, I don't really know...

[rderooy]

@hb9tst I would not completely discount something else causing havoc. For instance I have seen weird issues on Vogons with users who had installed Discord.

[hb9tst]

@rderooy Ok then it would make sense I try that on a cleanly installed machine or VM... hope to have some time next week.

[spudpiggy]

Sorry for necro, but I'm here to confirm. I have a US layout keyboard (@ key on shift+2) but use UK qwerty, and I have this issue when trying to type a backslash. My muscle memory presses right alt + # (UK qwerty would put backslash between left shift and z, but US qwerty doesn't have a key there) to type a backslash, and because of this bug that doesn't work in dosbox-x. Like, at all. I checked the mapper and can confirm altgr detects as ctrl+alt

[tokariu]

confirm the issue.

Alt Gr + ß = Backslash on the german codepage.

it works in dosbox-x when just using normal. but it does NOT work after you use "boot c:" to boot to a guest os like original MSDOS 6.22 or Win98.

with a guest OS we need to make use of "keyb gr 437" f.i. to get the correct keyboard layout. but as soon as it is set, backslash won't work anymore. if keyb is not set, we just have the us keyboard layout.

on a side note, keymapper always shows Alt-Gr as both modifiers Ctrl + Alt being pressed and not as its own key. maybe something that should be considered for a change?

[maron2000]

Modern Windows handle AltGr key as Left CTRL + right ALT keys, not only DOSBox-X. https://en.m.wikipedia.org/wiki/AltGr_key#History

You currently have to either Switch your host keyboard to ENG (or whatever not using AltGr such as JP) Map any key other than AltGr to Right alt key on the keymapper

[maron2000]

Another option is to copy keyb.exe and keyboard.sys from FreeDOS. It seems to handle CTRL+ALT as ALT.