FS#57408 - [linux] Consider enabling 16-bit support
Attached to Project:
Arch Linux
Opened by AaronP (Bellum) - Wednesday, 07 February 2018, 03:28 GMT
Last edited by Jan Alexander Steffens (heftig) - Saturday, 03 November 2018, 08:52 GMT
Opened by AaronP (Bellum) - Wednesday, 07 February 2018, 03:28 GMT
Last edited by Jan Alexander Steffens (heftig) - Saturday, 03 November 2018, 08:52 GMT
|
Details
16-bit is apparently not working with the default Arch
kernel. If there's no big reason not to, consider enabling
it in the config.
I did this myself, and note that it did add a little over 20mb to the package, which seems excessive for this feature, but it's necessary to run a variety of windows 9x software in wine and dosemu2. To get it working, you need to set the following: CONFIG_X86_16BIT=y CONFIG_X86_ESPFIX64=y CONFIG_MODIFY_LDT_SYSCALL=y |
This task depends upon
Closed by Jan Alexander Steffens (heftig)
Saturday, 03 November 2018, 08:52 GMT
Reason for closing: Implemented
Additional comments about closing: Implemented in trunk, pending next release
Saturday, 03 November 2018, 08:52 GMT
Reason for closing: Implemented
Additional comments about closing: Implemented in trunk, pending next release
To be fair, whoever is using dosemu2 to interface with their spaceship from the 80s or whatever is probably not doing it on Arch.
> Poor sb16 emulation, no DOS-specific hacks
> in pic/pit/kbd code, no DOS-specific integration
> with host FS, with network, etc etc.
A year or two ago I reported a bug in the keyboard handling on dos for qemu that made vim unusable, but it never saw any discussion. I assume DOS just isn't on their radar, which is understandable.
For Windows 95/98 software, which also often has 16-bit code, running a virtual machine is really overkill when you can just use wine, where you can do things like mount a disk image with cdemu and get CD audio without trying to emulate an old 16-bit sound card. You also don't have to deal with mounting a VM image to transfer files back and forth, non-existent drivers for your modern hardware, etc.
I don't think the efforts of the package maintainers for security and convenience have to be incompatible with the efforts of the developers of compatibility applications such as dosemu2 and wine.
Regarding what anthraxx said, the impact on performance can't be that bad. At least it seems to me that it's much less significant than the functionality that is lost by disabling this feature.
I'm aware it's only a few of us who may need it, but there has to be a way other than having to compile the kernel on our own.
Thanks.