What's the future of win16 compatibility on 64bit GNU/Linux?

[lunavorax]

Hello,

Some Wine user informed me that the reason why win16 binaries doesn't work anymore on GNU/Linux is because of a recent kernel change that ban execution of 16bit code on 64bit CPUs.

According to https://lkml.org/lkml/2014/4/11/542, I'm not sure if I understand everything correctly, but it seems that both Linus and the commiter of that code don't give a damn about that fact.

What solution can the Wine developers provides to this issue?

[oiaohm]

https://lkml.org/lkml/2014/4/29/626

lunavorax latter on in the month intel developer steps 3.15 is not released yet. Yes it has been noted that wine has been busted by change and that it is regression in functionality. Issue is a long time ago wine project did consider internally handling the wrapping between win16 and win32 so they could just use the same 32 bit PE mode.

lunavorax at this stage wine developers have todo nothing Intel developer is looking into it. If it turns out that is fully busted in the end wine does have options. Take vm86 mode wine project still runs dos applications by these days calling dosbox to emulate them this is the worst case out come. Minor alteration to qemu user-mode would do.

Reality here wine was meant to consider not using 16 bit segments. Turning it off was most likely the fastest way to find out what was effected.

The answer is yes there will be win16 compatibility on 64 bit Linux systems just we don't have a clue if it will be kernel or cpu emulator solution. If it emulated the functionality might disappear for a little while like dos mode did. Wine status at moment to the problem is wait and see what the kernel developers end up doing.

[lunavorax]

Thank you for your answer.

That's really a shame. Mostly because a lot of game installer are win16 binaries, and extracting the .CAB files are often not enough.

Most generally, I realise how much win16 .EXE I have laying around that I thought were win32.

[oiaohm]

lunavorax dosbox emulation is added because there are a lot of win16 and win32 games and applications with dos installers as well.

So no matter what some form of win16 support will remain. Problem here its a waste of resource to fix something that currently works. Users normally don't run like 3.15 kernel either. It will be about 12 months before the change appears in major distributions if at all.


Basically remember hitchhikers guide to Galaxy. Don't panic. Its not a problem yet.

[Bladeforce]

So in theory this would only affect 16 bit windows installers in the future? Games from the Windows 95/98/ME/XP era mainly? Most of the games executables were 32bit so those wont be affected just installing some? I guess if push comes to shove we'd have to install the game in a virtual program then transfer it to a wine prefix along with the registry settings?

[oiaohm]

Bladeforce not that simple from the 9x time frame and before there is a thing called thunking where 32 bit applications call 16 bit libraries. So applications and games that are majority 32 bit will break without the 16 bit support.

Removing the functionality long term is not really wise.

[Bladeforce]

Well if a kernel update breaks my wine games from the windows 98 era i will stay on any pre 3.15 for a long time!

If i'm not mistaken that link earlier in the thread also mentions a fix so all may not be lost?

[oiaohm]

https://lkml.org/lkml/2014/4/29/626 yes this is a fix.

The problem here is 16 in the old Linux kernels both has security flaws. This is why the 16 bit mode ended up disabled. In fact the flaw in 16 bit mode does explain some win16 using application failures that have been strange.

Bladeforce the current fix is not 100 percent positive for wine.

https://lkml.org/lkml/2014/5/4/376

Notice here 16 bit support here has been made optional.

In fact one flaw was using 16 bit segments in 64bit mode that wine never used. On 64 bit system 16 bit segments now must only be used in 32 bit areas.

So as long as H. Peter Anvin patches go mainline we have time. No requirement to panic.

Reality at a min moving to 3.15 with H. Peter Anvin patches would be wise. But long term wine project does have to consider how to emulate 16 bit mode now. Please note consider. We are still talking over 12 months before these alterations end up in mainline distributions in a large way.

No panic no rush. Users are not going to be effected in the very near future. Long term wine may have to change a few things.

[lunavorax]

Well if a kernel update breaks my wine games from the windows 98 era i will stay on any pre 3.15 for a long time!

This is not that easy, I installed GNU/Linux LTS 3.10.40 hoping that it would fix the issue, but I still have the same error.

Since Wine is available for FreeBSD and NetBSD, I'll try theses OS to see if they support win16 binaries.

[Bladeforce]

Thanks Lunavorax for the explanation very helpful! I will just have to keep a close eye on the kernel updates in the future and of course the wine updates to see if there is anything in the future as regards this topic. Many thanks mate

[oiaohm]

lunavorax not a issue to change away from Linux. Most surprising to a lot is almost all Linux distributions can be run on stock or custom patched Linux kernels.

lunavorax really It is possible due to it being a secuirty flaw that ubuntu backported the patch before it stable(ubuntu has that horible habit). But we have not had any broken reports. If they have back-ported the patch it would be possible to request Ubuntu include the work around.

There is another mistake. win16 binaries with wine only work in WINEARCH=win32 prefix on a 64 bit system. You issue might be nothing todo with kernel but incorrect usage of wine. Default prefix formed if you don't set WINEARCH on a win64 bit system is a WINEARCH=win64.

[lunavorax]

lunavorax really It is possible due to it being a secuirty flaw that ubuntu backported the patch before it stable(ubuntu has that horible habit). But we have not had any broken reports. If they have back-ported the patch it would be possible to request Ubuntu include the work around.

I'm using ArchLinux, so I'm just having the very last updates available.
This is very annoying because now 90% of the software I user doen't work anymore. I can't play anything but pure win32 software with pure win32 installers, which is absolutely not the case of the majority of the software I usually run under Wine.

There is another mistake. win16 binaries with wine only work in WINEARCH=win32 prefix on a 64 bit system. You issue might be nothing todo with kernel but incorrect usage of wine. Default prefix formed if you don't set WINEARCH on a win64 bit system is a WINEARCH=win64.

No, no, no! Whatever software I use I always use WINEARCH=win32 for everything since I never user any win64 software.

[oiaohm]

lunavorax see after a little more digging. Its 3.10.39 where the blocking patch gets include and it got into 3.14.20.

https://lkml.org/lkml/2014/4/29/626 this fix here is by the same author who broke it.

"modify_ldt: Ban 16-bit segments on 64-bit kernels" is the issue.

https://git.kernel.org/cgit/linux/kerne ... a9762624ff This is 10 days ago. This is mainline development branch that will become 3.15.

lunavorax the reality Linus and H. Peter Anvin see this as opps.

So it is a temporary breakage. espfix64 will be the proper fix.

lunavorax but due to the secuirty mess if you are really needing win16 applications I am forced to recommend for the short term custom building kernel with espfix64 or just run older kernel with patch removed or allowance patch applied.

Basically wine win16 support has been collateral damage in the process of patching a security flaw. Linus is going to allow a fix. Has allowed a temp fix that is make it as bad as it was before.

Really we want espfix64 because it will fix some of the odd issues that cause some win16 applications to crash and we have not known how. Its kinda in face when we see what the flaw was.

[oiaohm]

lunavorax turns out I do have some really bad news.

"H. Peter Anvin" in the process of developing tests for the espfix64 has in fact found the generic usage of iret inside of Linux has some nasty weaknesses. None appear create direct security flaws. Some kernel panic the complete OS.

So win16 working has been a major case of good luck than good management. Worse 32 bit binaries on a 64 bit system can also do some of the disasters.

https://lkml.org/lkml/2014/5/20/717

So proper fix will most likely end up being 3.16 unfortunately after some memory management and other things get reworked and fixed. Turns out the 16 bit stuff is a tip of a iceberg of issues. Interesting enough most have never been hit by anything major-ally before.

Basically **** has hit fan. And all these faults would have went unnoticed if wine did not require 16 bit mode.

lunavorax so what we know is yes win16 support will be fixed. So win16 can work in 3.15 and hopefully that get backported to the other LTS kernels. But then 3.15 use with care at this stage. Basically avoid new unknown win16 applications where you can(because they might be landmine). 3.16 hopefully proper stack fix so a rogue application cannot stuff everything. In fact disabling 16 bit stacks did not stop the means to crash kernel welcome to the creativity of "H. Peter Anvin" testing being able to stuff everything from 32 bit and 64 bit binaries.

Yes the issue is at least 9 times large than it was presumed.

lunavorax this is a truly rare event this is only the second one of these kind of messes I have seen from 1996 to today. So its about once every 10 years and we just happen to be caught in the middle of this one.

[oiaohm]

echo 1 > /proc/sys/abi/ldt16

If you have a 3.15 or latter Linux kernel the above will be required at this stage run run win16 binaries. The patches todo this is already in 3.15. 3.15 currently in this mode is not secure.

All the prior kernels that could run win16 were not secure either.

[doragasu]

It's really good news we will be able to get back win16 compatibility in 3.15 kernel. Thanks @oiaohm for the info.

[oiaohm]

One thing I forgot to say. Current 32 bit LTS Linux kernels running 16 bit code is secure. This is the problem. Its going to take them awhile to properly fix the 64bit kernels. There are a few issues in the arch of 64 bit mode that have brought disaster. So if you are trying a win16 application or a win32 application that uses win16 in the short term using a 32 bit install would be advisable from a security and stability point of view.

Win16 support will return to 64 bit Linux kernels. Question is currently how long before it is safe. Also the fact it traces to how 64 mode works in x86 processors there is a chance the issue is in other platforms.

As I say this is a true tip of iceberg problem we don't know how big it is yet. Linuix it self its fairly large other OS's have not been checked yet. This is why it pays to sit back and wait some of these things out.

[dadnotgrandad]

Apparently some in the Linux community thing the OS is for playing games, and not using the OS for serious business appliations. I went to pay bills from QuickBooks 2001 today only to find my QuickBooks would not work because of upgrade to 3.8.0-41 kernel. Fortunately I had backups of my data files and was able to run on a copy of QB that I have on a WinXP partition. Still I had to spend several hours troubleshooting why a program that worked well uder Wine was now DOA.

John

[oiaohm]

dadnotgrandad sorry what. You are running a +10 year old accountancy package. Quickbooks 2003 don't have 16 bit parts. From the Linux point of view still running Quickbooks 2001 is not being serous and taking security risks. There are quite a few document CVE issues with Quickbooks 2001.

Exactly where was your migration plan to move to native Linux applications.

Linux 64 bit temporary has come into alignment with Windows 64 bit. Some modernday motherboards only have 64 bit Windows drivers so installing 32 bit version of Windows is out.

Yes running a 32 bit version of Linux will allow you to run Quickbooks 2001. Running a insecure 64 bit Linux kernel will also allow Quickbooks 2001 to run. But the serous question if you are a serous business why are you still running it due to Quickbooks 2001 own known security issues.

As far as I know there are zero maintained applications still using win16 bit code. Unmaintained and Business do not mix. Business users should not have been effected by this change. The ones that are do need to take a very much closer look at their application policies.

Yes the reason why win16 is being talked about in the sense of being for game players is really they are are people who run historic applications for history reasons.

Only people with historic reasons to run stuff should need win16.

dadnotgrandad I did not want to have to be mean. But there is no good going to come from me saying that what you are doing is right when its been wrong.

[dimesio]

I've made this thread a sticky. If Ubuntu's backported the change, we're going to see a lot of users with this problem.

[dadnotgrandad]

Olaohm, thank you for your reply. You provided a very important piece of information. All I need to do is to move to QuickBooks 2003 and the problem goes away. Of course there are differeing views on whether QB 2003 is okay for LOOinux OS or one needs to move to QB 2005, 2006, or 2007. Apparently QB versions beyond 2007 are Linux unfriendly.

I am one scientist consulting business with part-time secretary. My secretary's PC went from XP to Ubuntu well over a year ago. I moved my laptop and desktop PCs to Ubuntu earlier this year. I am the only one who uses QB, payroll is outsourced, and all data files for all applications are backed up as they are changed using commercial off-site back-up services. Being able to quickly recover data in the event of a disaster seems much more important than committing the sin of using legacy software that works reliably.

John

John

[oiaohm]

dadnotgrandad from a security point of Quickbooks 2011 or older is busted.
http://support.quickbooks.intuit.com/Su ... s/INF12842 Intuit support cycle is 3 years once that is up no more security updates or bug fixes. If you are not planning on re-buying it every 3 years you should be looking at a different product.

Currently wine runs no secure versions of Quickbooks runs. And no one has funded that they do run.

The reality here is you have been running with a insecure product for many years. Don't be insulting about Linux using like Loonux. Reality here if anyone is a loon in this mess its you. Not trying to mean but there are a lot of Windows users who don't bother getting application life cycles and when disasters happen get bitten by them.

Being able to quickly recover data in the event of a disaster seems much more important than committing the sin of using legacy software that works reliably.

This statement is not true. Intuit will not provide new installation media for old versions. So those online backups you have might be completely worthless after a disaster. The sin of legacy software equals possibility of no recovery. This is why no serous business does this. By the way restoring a quickbooks 2001 file into 2013 requires migrations to versions of quickbooks in middle that Intuit is not going to provide. So you current locations is that you cannot go out and buy a new version and set yourself back up.

sugercrm, oodo, gnucash.... There are a list of open source accountancy solutions. After a disaster with the open source ones you can download new copies of the installers even for the old versions. There is also a list of closed source java based accountancy packages that run on Linux as well.

The simple reality you migrated across to Linux to get away from XP end of life and forgot software you are using also had end of life values. As I said this should be a wake up call. XP in virtual machine for now is an option. But no long term plan should include you still running quickbooks 2001.

dadnotgrandad I am not going to sit here and tell you that everything is good. When the truth is you are truly up the creek and sinking before Linux kernel updated and blocked the application from working. Just you were not noticing the fact you were sinking. In a lot of ways you should consider yourself lucky it happened now while you still had a copy of XP installed and it was not a harddrive crash forcing you to get a new computer and set back up.

[doragasu]

What I think it is not made clear (or at least I have not seen a warning anywhere) is that configuring Wine to mimic Windows 9x also triggers this problem even if the software you want to run is 32-bit.

So my advise is if you are running 32 bit windows programs through wine on an x86_64 system, don't bother setting Windows 98 mode or you might have problems with recent kernels. Leave it as the default Windows XP and don't look back.

[oiaohm]

doragasu I am sorry to say you are wrong on reason right on advice.

Setting 9x mode all it major-ally does in wine is change what version windows is reported to the application. A pure win32 9x application will not be effected by setting 9x mode and still run with the Linux kernel alteration. Problem here is some applications when they are reported 9x switch to using win16 libraries. So now become hybrid win32/win16 applications that the kernel update don't allow.

I do back that sticking to XP is most advisable. This reduces applications that use win16.

[doragasu]

@oiaohm Are you sure some programs work in Windows 98 mode? Just try this on an x86_64 with 3.14 kernel:

1.- Create an empty win32 prefix:
$ WINEARCH=win32 WINEPREFIX=/home/doragasu/test wineboot

2. Test some built-in wine applications like e.g. wineconsole and winecfg:
$ WINEPREFIX=/home/doragasu/test wineconsole
$ WINEPREFIX=/home/doragasu/test winecfg

(Both apps work perfect in my setup).

3. Launch again winecfg and configure it to Windows 98.

4. try again step 2. Now neither winecfg nor wineconsole will work (at least they do not in my setup, they throw the ldt_modify errors).

Maybe the problem is applications switch to 16 bit libraries, bus as even wineboot is affected and will not start in Windows 98 mode, I think you will not be able to start any applications, even "pure" 32 bit ones.