I think this is an UPSTREAM bug.

http://lkml.org/lkml/2014/4/14/207

The kernel issue is definitely upstream, but I think the problem being reported here is that wineboot, winecfg, regedit, etc. use 16 bit code when the Windows version is set to Windows 98. I don't know if that's a bug or intentional.

Rosanne DiMesio the reality in the past the 16 bit code was not a issue because the kernel always supported it.  In 3.16 and going forwards 16 bit code will require a /proc setting changed in kernel.  yes  echo 1 > /proc/sys/abi/ldt16 is what you have todo on 3.16 and later to have 16 bit mode.  https://lkml.org/lkml/2014/5/7/508.

Bruno Jesus yes you are right its a upstream bug.  But upstream is declaring it secuirty issue. So its never coming back how we use to use it.

Wine has to be altered in design to gracefully handle case of no 16 bit mode and ask user to enable it or reverse windows ME and before mode set.   Just like wine currently handles echo 0 > /proc/sys/vm/mmap_min_addr not set on programs that need it.   The mmap_min_addr alteration is also due to another security issue.

The main bug here is winecfg failed due to using 16 bit code so unable to revert change.  This will be true even when 16 bit code support returns to the Linux kernel.   If nothing else is change winecfg needs to work.

Ok I just got a broken kernel.  Windows ME mode is the same.  Its all the ME and before are stuffed.

I can tell you if you change to Windows 9x mode using apply from winecfg don't close winecfg you can have the fault appear and be able to reverse it.

Yes I understand working out if Windows 9x/ME and before applications need 16 mode init will take time.   This is why the prime target has to be fixing winecfg so it does not absolute fail.

(In reply to oiaohm from comment #3)
> Rosanne DiMesio the reality in the past the 16 bit code was not a issue
> because the kernel always supported it.  In 3.16 and going forwards 16 bit
> code will require a /proc setting changed in kernel.  yes  echo 1 >
> /proc/sys/abi/ldt16 is what you have todo on 3.16 and later to have 16 bit
> mode.  https://lkml.org/lkml/2014/5/7/508.
> 
> Bruno Jesus yes you are right its a upstream bug.  But upstream is declaring
> it secuirty issue. So its never coming back how we use to use it.

I've added a bit of info for this to the FAQ: http://wiki.winehq.org/FAQ

(In reply to Austin English from comment #4)

> 
> I've added a bit of info for this to the FAQ: http://wiki.winehq.org/FAQ

Thanks. I made one change to it: removed the reference to 3.14+ kernels. Ubuntu has backported the change to older versions.

/proc/sys/abi/ldt16  I got version wrong its 3.15 where this offically will appear at kernel.org.

If you are on a 64 bit system that win16 does not work and its prior to 3.15 you might have /proc/sys/abi/ldt16 if you do enabling it will make it work again.

3.16 is when the hope for the secuirty patch will be done.

32 bit Linux kernels running 16 bit code is secure.  The 64 bit mode requires a different fix to a secuity issue than.

Still does not change the fact that 3.15 after 16 bit support by kernel is optional on 64 bit systems.   Someone without root rights will not be able to change /proc/sys/abi/ldt16 yet they will be able to change winecfg setting on prefix and end up in stuffed.   LTS particular versions have had the disabling patch applied some have the /proc/sys/abi/ldt16 applied.   As far as I can see no direct kernel.org kernel under 3.15 has the /proc/sys/abi/ldt16 patch applied yet.

From kernel.org 3.15+, 3.14.6+, 3.10.42 +, 3.4.92+ on has  /proc/sys/abi/ldt16 in 64 bit mode but if you are running 3.12.21 or 3.2.59 those are busted.   Hopefully 3.13.22 and 3.2.60 will have it but we will have to watch.

Just to bewarped 2.6.32.62 has not been patched at all.
 
Basically the faq will have to be updated a few times as the patches are pushed out.  In the end there will be two lists.

List one will be kernels that contain  /proc/sys/abi/ldt16 so 16 bit applications on these 64 bit kernels can be made work with secuirty risks.
List two will be kernels that contain espfix64 these are safe to run 16 bit applications but you still have to turn 16 bit on as required.
https://lkml.org/lkml/2014/5/4/346
espfix64 is qued for 3.16 and maybe backported to LTS kernels.

Why is espfix64 critical it contains the secuirty fix for 16 bit segments for 64 bit kernel.

*** Bug 36707 has been marked as a duplicate of this bug. ***

3.2.60+ is patched to have /proc/sys/abi/ldt16.
Only 3.12.21 kernel.org mainline is the only LTS that if you are upto date cannot run win16 binaries.   Hopefully 3.12.22 release will have all the current LTS kernels sorted.  So at 3.12.22 release I will check if it has patch then update faq.

I was wondering why Linux Kernel 2.6.32 was not patching  Mid-2014 is  its offically end of life.  So anyone still running this should be migrating anyhow.

I remembered 
http://wiki.winehq.org/PreloaderPageZeroProblem
This is the prior example of wine running into a Linux secuirty fix.  It was also crashing when this first change appeared.

/proc/sys/abi/ldt16 default state is going to be no 16 bit on 64bit kernel.

I can confirm, this affects 32 bit applications as well (running in Windows 95 or Windows 98 mode). Including ones from Wine itself, such as winecfg!

Alexandre commited a few patches recently, maybe they are related to this issue (like http://source.winehq.org/git/wine.git/commitdiff/b0953a09bdc8d807b6549051c4283a6e2dc6ad88 )

Please try again in wine-git if possible.

Shouldnt this be fixed by now using up to date kernel?

Yes, this problem doesn't show anymore with kernel 3.16+

(In reply to doragasu from comment #12)
> Yes, this problem doesn't show anymore with kernel 3.16+

Fixed upstream, closing.