Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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 Steffens (heftig) - Saturday, 03 November 2018, 08:52 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Jan Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 16
Private No

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 Steffens (heftig)
Saturday, 03 November 2018, 08:52 GMT
Reason for closing:  Implemented
Additional comments about closing:  Implemented in trunk, pending next release
Comment by Levente Polyak (anthraxx) - Wednesday, 07 February 2018, 11:55 GMT
It adds a small performence penality for context switches and the syscall with the LDT opens up an not to ignore attack primitive. Latter is the reason this won't happen for linux-hardened. Former is a reason i personally wouldn't enable it for the general purpose variant, but if, then _maybe_ consider it for desktop oriented linux-zen instead?
Comment by Doug Newgard (Scimmia) - Wednesday, 07 February 2018, 16:31 GMT
We're going to be talking about 20-25+ year old proprietary binaries here, is that something we should even bother supporting? Anything that's been maintained even a little bit or is open source would not be an issue.
Comment by AaronP (Bellum) - Wednesday, 07 February 2018, 17:58 GMT
Yeah, why not? There **are** people still actively maintaining dos software that's run in dosemu--or so I've heard in a recent talk on the subject--but yeah my interest is running unmaintained 20-25+ year old proprietary binaries. I heard some weeks ago from a guy who for years used the Writer application in Windows 3.11 via dosbox because he didn't like libreoffice. We Linux users have a broad array of interests and eccentricities. :P

To be fair, whoever is using dosemu2 to interface with their spaceship from the 80s or whatever is probably not doing it on Arch.
Comment by Chris Severance (severach) - Friday, 09 February 2018, 03:11 GMT Comment by AK (Andreaskem) - Friday, 09 February 2018, 06:04 GMT
Would the old games/software angle be covered by a virtual machine running FreeDOS?
Comment by AaronP (Bellum) - Friday, 09 February 2018, 08:15 GMT
No, I don't think so. See this comment by the dosemu2 maintainer regarding using qemu: https://github.com/stsp/dosemu2/issues/401#issuecomment-312958964

> 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.
Comment by Chris Severance (severach) - Friday, 09 February 2018, 09:04 GMT
Wine and dosemu have both good performance and transparent access to the host file system in a way that doesn't defeat caching. It's hard to find something else with either of these, let alone both.
Comment by Antony (arch_86) - Saturday, 10 February 2018, 13:37 GMT
currently docker work correct only with vsyscall=emulate, in 4.15 i cant change this value
Comment by magiblot (magiblot) - Friday, 20 April 2018, 19:26 GMT
I wish a solution to this can be found eventually.

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.
Comment by Jens Staal (WFcody) - Saturday, 25 August 2018, 08:33 GMT
Can 16 bit support be offered as a (dkms) kernel module?
Comment by Aleksei (nesk_bugs) - Monday, 17 September 2018, 06:41 GMT
Please count my vote to re-enabling that feature. According to this Phoronix thread, this was disabled for a while as a temporary workaround for a vulnerability, but later re-enabled in mainline kernel - https://www.phoronix.com/forums/forum/software/linux-gaming/1046396-dosbox-0-74-2-released-with-better-wine-compatibility-linux-opengl-fixes/page3
Comment by Lance (Raansu) - Saturday, 03 November 2018, 07:59 GMT
I also vote yes for this change, if it doesn't impact security.

Loading...