DOSBox 0.74-2 Released With Better Wine Compatibility, Linux OpenGL Fixes

[perpetually high]

chuckles I meant that humorously, no insult was taken.

Ok good, just checking.

Can you run warcraft 2 on recent DosBox and recent kernel? I tried recently, it won't run because of 16-bit disabled in the kernel config. Maybe you know some trick (to avoid compiling your own kernel)?

Running fine on 4.18 (my own compiled) and the generic 4.18 in Ubuntu 18.10 cosmic with the latest distro version (dosbox/cosmic,now 0.74-4.3 amd64)

config X86_16BIT
bool "Enable support for 16-bit segments" if EXPERT
default y
---help---
This option is required by programs like Wine to run 16-bit
protected mode legacy code on x86 processors. Disabling
this option saves about 300 bytes on i386, or around 6K text
plus 16K runtime memory on x86-64

You can double check your setting for this parameter by running:

$ gzip -cd /proc/config.gz | grep -i CONFIG_X86_16BIT
CONFIG_X86_16BIT=y

I just don't see the benefit in disabling that feature personally. Not sure what the equivalent boot parameter would be if you wanted to flip it on at startup (something maybe like x86.16bit=y, not sure). Also, if you don't want to compile your own kernel, you can get one pre-built from Ubuntu.

[ssokolow]

Not sure what the equivalent boot parameter would be if you wanted to flip it on at startup (something maybe like x86.16bit=y, not sure).

I'm not sure if it's still the same but, for a while, the way to re-enable the relevant functionality was to put this in your /etc/rc.local:

echo 1 > /proc/sys/abi/ldt16

[perpetually high]

I'm not sure if it's still the same but, for a while, the way to re-enable the relevant functionality was to put this in your /etc/rc.local:

echo 1 > /proc/sys/abi/ldt16

Interesting, not sure if that's the one. I don't have the file on my computer (don't need the fix, was just curious).

$ cat /proc/sys/abi/ldt16
cat: /proc/sys/abi/ldt16: No such file or directory

[ssokolow]

Interesting, not sure if that's the one. I don't have the file on my computer (don't need the fix, was just curious).

$ cat /proc/sys/abi/ldt16
cat: /proc/sys/abi/ldt16: No such file or directory

I don't have it anymore either. One of the Kubuntu 14.04 LTS kernel updates switched it from requiring that change to just having it on by default.

[Weasel]

I'm not sure if it's still the same but, for a while, the way to re-enable the relevant functionality was to put this in your /etc/rc.local:

echo 1 > /proc/sys/abi/ldt16

It was just a temporary bandaid. It has been fixed long ago, but people will keep on insisting on it because they want to believe it.

By fixed I mean the security risk of having it on was fixed completely so now it's permanently on (if compiled obviously).

[ssokolow]

but people will keep on insisting on it because they want to believe it.

I don't follow. Explain?

[Weasel]

I don't follow. Explain?

Some people like oiaohm want to believe that it stops working, so they have an excuse to use when I tell them that Wine still supports 16-bit programs and it's not a CPU limitation (i.e. no need for emulation for 16-bit protected mode, only real mode). For the same reason he wants to believe that Microsoft APIs break their contracts left and right too. Just doesn't align with his beliefs, so he wants it to become true, but that's a different subject.

[ssokolow]

Some people like oiaohm want to believe that it stops working, so they have an excuse to use when I tell them that Wine still supports 16-bit programs and it's not a CPU limitation (i.e. no need for emulation for 16-bit protected mode, only real mode). For the same reason he wants to believe that Microsoft APIs break their contracts left and right too. Just doesn't align with his beliefs, so he wants it to become true, but that's a different subject.

Ahh.

I'll admit I thought the Ubuntu people had taken over the job of toggling it on at whatever location it had moved to, but only because, last I heard, the stance from the kernel developers was that they were going to keep 16-bit support opt-in to protect the vast majority of Linux users (people who don't need to run 16-bit code in Wine) against any 0-day exploits that might be discovered in the future.

Is it that a default KConfig now has CONFIG_X86_16BIT turned off or did they change their mind on that?

[Weasel]

Ahh.

I'll admit I thought the Ubuntu people had taken over the job of toggling it on at whatever location it had moved to, but only because, last I heard, the stance from the kernel developers was that they were going to keep 16-bit support opt-in to protect the vast majority of Linux users (people who don't need to run 16-bit code in Wine) against any 0-day exploits that might be discovered in the future.

Is it that a default KConfig now has CONFIG_X86_16BIT turned off or did they change their mind on that?

Well, to not go into details, originally, they disabled 16-bit mode due to a vulnerability. It was just a temporary measure until the said vulnerability was fixed. This was in the 3.x mainline kernels and Linus added this option at the request of Alexandre Julliard (Wine's maintainer) until the vulnerability was fixed "for real".

I don't know about Ubuntu, but for their 3.x kernels they probably backported the security fix like they do with security fixes, so there's no need to have that /proc/sys/abi/ldt16 stuff anymore. 4.x kernels are fixed even on mainline anyway.

I have to emphasize that disabling 16-bit code was not the fix, it was a temporary bandaid measure.

[ssokolow]

I have to emphasize that disabling 16-bit code was not the fix, it was a temporary bandaid measure.

I'm well aware of that. I did read quite a bit about it.

However, I also remember the position of the kernel developers at the time it was fixed being "Now that this is fixed, we're going to leave 16-bit support opt-in since it's such a niche need and, for all we know, there could be more 0-day exploits still to be found."