[Bug 36664] Unable to run anything with kernel version 3.14 and wine configured as Windows 9x

wine-bugs at winehq.org wine-bugs at winehq.org
Thu Jun 5 07:24:38 CDT 2014


http://bugs.winehq.org/show_bug.cgi?id=36664

--- Comment #3 from oiaohm <oiaohm at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list