http://bugs.winehq.org/show_bug.cgi?id=36664
--- Comment #3 from oiaohm oiaohm@gmail.com --- 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.