
Wine Developers Concerned with Ubuntu Dropping 32-Bit Support - logix
https://www.linuxuprising.com/2019/06/wine-developers-concerned-with-ubuntu.html
======
richard_todd
I immediately wondered about macOS, which is dropping 32-bit support as well.
One of the first links I found[1] seems to say that there is no 64-bit wine on
macOS regardless of library issues, due to an ABI incompatibility. So on the
surface it seems like the world is shifting under wine's feet, and they are
going to need to do a second level of emulation eventually to keep 32-bit
stuff running.

[1]:
[https://forum.winehq.org/viewtopic.php?f=9&t=23005](https://forum.winehq.org/viewtopic.php?f=9&t=23005)

~~~
coldpie
The change Ubuntu is proposing is far less harsh than what macOS is doing.
Unlike macOS, Ubuntu will still run 32-bit processes, you just have to provide
all of the userspace libraries. Applications like Steam for Linux already do
this for binary compatibility reasons, so their usecase won't change much.

Wine's official Ubuntu packages currently rely on the OS to provide these
userspace libraries. They would "only" need to change to also build and ship
the rest of the libraries, instead of relying on the OS to provide them.
Meanwhile on macOS, you can't even run 32-bit binaries, working around that is
a much, much larger task.

~~~
jjwhitaker
I wonder why Wine doesn't have those libraries on standby. I can understand
keeping installer/total install size and footprint down for any application
but especially emulation which is already complex and going to push hardware.
If Wine includes the right components, what performance hit may be suffered?
Or maybe I have this wrong and it won't really matter.

~~~
iokanuon
Yeah, it doesn't really matter as wine would just have to load the 32 bit
libraries from a different location (say, /usr/lib/wine/lib32 instead of
/usr/lib32).

Also, Wine is not that kind of emulator. It provides windows-compatibile
libraries but does not do CPU emulation so there's no real significant
performance hit. [0]

[0]: [https://superuser.com/a/14600](https://superuser.com/a/14600)

------
EamonnMR
WINE needs 32 bit support. The bulk of windows programs that people still care
about are from the 32 bit era, and as they point out many 64 bit apps use 32
bit installers. Maybe it's time for x86 box like DOSbox.

~~~
AnIdiotOnTheNet
What's interesting about this is... doesn't WINE also support Win16
applications? My understanding was that it does, yet it doesn't seem to
require 16 bit libraries from the host OS...

~~~
djsumdog
Windows doesn't even support 16-bit applications (unless you use 32-bit
Windows with NTVDM enabled).

There was another post on here a few months back about someone getting Win16
apps working on modern 64-bit Windows machines:

[https://hackernoon.com/win3mu-part-1-why-im-
writing-a-16-bit...](https://hackernoon.com/win3mu-part-1-why-im-
writing-a-16-bit-windows-emulator-2eae946c935d)

~~~
pedrocx486
If I'm not mistaken such emulation already exists with winevdm:

[https://github.com/otya128/winevdm](https://github.com/otya128/winevdm)

------
momokoko
I'm curious about Wine's usage and relevance at this point in the Linux
desktop story. My assumption is that Linux users(myself included) that use
Windows applications(not games), tend to just run a VM in seamless mode for
Windows functionality.

I would be curious if others had any insight(anecdotal or otherwise) about
Wine usage these days.

~~~
Aelius
I used to run foobar2000 in wine, because no other linux media player
scratched some of the itches foobar covered. There is even a foobar2000
package in the arch aur so it simply installs like any other pacman managed
program.

However, once I learned of the wine interface that is available on flathub
(for flatpak) I immediately removed wine and its 32 bit components from my
system- now that untidyness is neatly contained within flatpak dependencies.

Correct me if I'm wrong, but doesn't flatpak'd wine solve this issue?

~~~
corey_moncure
Yes, fb2k is the one Windows-only app I just can't let go. The library
management, plugins, UI, extensibility, and configurability are just simply
unmatched by anything else out there. I likes my music the way I likes it.

------
TazeTSchnitzel
I had assumed that because 64-bit wine did the “Program Files (x86)” thing, it
ran 32-bit Windows apps in a 64-bit process. But now that I think about it,
that doesn't make sense.

WINE needs kernel and userland support for running 32-bit x86 code unless it
adds an emulator, because WINE actually loads the Windows executable's binary
code into the current process (I assume exec() is a good comparison?) together
with OS shared libraries. Maybe relevant for understanding this:
[https://wiki.winehq.org/Wine_Developer%27s_Guide/Kernel_modu...](https://wiki.winehq.org/Wine_Developer%27s_Guide/Kernel_modules#The_Wine_initialization_process)

------
giancarlostoro
This will make me more likely to spin up a ReactOS VM if I really want to run
any Windows only software, since running Windows in a VM is very resource
consuming.

I was looking at computers at Walmart with only 4GB of RAM, the task manager
said 3 GB out of 4 GB were being used, and it was just on standby. I don't
know what happened around Windows 8 to 10 but having 8 GB of RAM is too little
for Windows, the OS takes up half of it out of the box whilst idle.

~~~
FeatureIncomple
Yep

That, and it's also almost impossible to run Windows 8 or 10 with a HDD drive,
even for basic stuff like internet browsing, etc.

SSD is basically required now.

Sad, because Linux is still pretty fast with HDD for basic usage.

~~~
asark
Can confirm, had a huge "WTF?" on installing Win8 on an HDD and seeing the
friggin' OS UI pause constantly for no obvious reason. It was like running
Win98 on a 75Mhz Pentium with 16MB of RAM. On my beefy quad-core Intel with
16GB of RAM. Added an SSD, problem went away. They're relying on the SSD to
make up for some really lazy crap in their code.

------
WhatIsDukkha
This actually seems like a GREAT thing to untangle all the otherwise useless?
32bit support from the underlying filesystem.

Why have windows apps accessing your 32 bit libraries in /usr (which only the
Windows apps need at this point) and instead just a flatpak library of
sandboxed 32 libraries?

My steam install is already flatpaked, I'd be much happier if the community
just moved this way -

[https://winepak.org/](https://winepak.org/)

Seems like much closer to what I would want when running ANY Windows app in my
otherwise completely open source desktop in the first place.

------
speeder
Lots of people in my company use Ubuntu and Wine...

Those news indeed are concerning, specially because a lot of "bureacracy"
related software is win32 only for stupid reasons (there is even one company
that purchases from us, that only negotiate the actual deals using a online
platform that only runs on IE6 and needs some Win32 plugins...)

------
whatshisface
I use Ubuntu, but should I switch to Debian or something else? What do I get
with Ubuntu that I don't get with Debian? The ability to run Windows binaries
is important to me.

~~~
momokoko
The biggest difference is probably the desktop UI. After that Ubuntu has a bit
more of a unified experience. Part of that is because Ubuntu tends to make a
lot more decisions for you, whereas Debian gives you more options upfront.
There is a nice integrated GUI(I know Debian has one but its less integrated)
for installing packages. Online resources tend to discuss Ubuntu specifically
due to its larger market share on the desktop. There is the Ubuntu
PPA(Personal Packaged Archives) which don't always work easily in Debian.

They are both fairly similar internally. I have been a long term Debian
user(decades), and I never feel out of place working with Ubuntu. That is not
always the case when I'm working with Red Hat or Arch or some other
distributions. Debian probably requires a bit more fiddling and a bit more
general Linux and computing knowledge, but if you have been using Linux for a
bit, I think you would be just fine.

------
dooglius
Presumably, the kernel will continue to support 32-bit, it's just that Ubuntu
won't package various 32-bit libraries anymore. But, can't Wine just bundle
any library dependencies itself?

~~~
coldpie
> But, can't Wine just bundle any library dependencies itself?

Yes. Any volunteers? :)

~~~
viraptor
Sure. You'll find them here:
[https://www.winepak.org/](https://www.winepak.org/)

------
olliej
But why not just do a translation — 32bit x86 to 64bit x86 doesn’t
meaningfully restrict available instructions, then just* plant a bunch
trampolines in the low 4gig to the real implementations in the 64bit adds
space.

* I know this isn’t a trivial “just” but it seems like a plausibly achievable approach to me

~~~
yjftsjthsd-h
I wonder if it'd be easier to use qemu's binary compatibility features?
Granted, I've only seen that used in Linux, but it's an existing layer that
supports running code for another processor as if it were native.

~~~
makomk
That qemu mode requires a full set of libraries compiled for the processor the
code you want to run executes on, so it doesn't help here - if you've got that
you can just use the Linux kernel's built-in 32 bit compatibility layer which
isn't going away any time soon and get better performance.

------
tracker1
It seems to me, we'll probably wind up with a base linux container for 32-bit
wine support... now, what that is based on, and how well it's maintained is
another issue entirely.

By comparison there's DosEMU, DosBox and others for DOS, but Windows/Wine is a
much larger surface. I can only hope there's enough community to create
effectively a "virtual distro base" that's 32-bit so that said apps can
continue to run.

Should be fairly similar to the effort on windows for WSL2 ... Would be
interesting to see MS take a similar approach for DOS/Win32 support. Given the
changes in MS, would actually be _VERY_ interesting to see MS support Wine32
under WSL2 so that they could remove the 32bit support from windows as well.
Unlikely, but one can dream.

~~~
xemdetia
I agree that a virtual 32 bit distro is probably the only way this makes
sense. I can't imagine that a project like wine has any capacity to do all the
security updates and dealing with all of multi distro complexities to work
around the fact that they could have wildly different library sets to stand
on. It could potentially be done as part of a distro package for Ubuntu but it
would be a single person replicating the effort of the core libs for ubuntu
over again, just for this one corner project.

Either that or someone's going to have to rebuild WOW64 on top of wine? I
guess that could happen.

------
FrozenVoid
Alot of non-technical people use (mostly closed source) 32bit windows
apps/games through wine on Ubuntu(the most popular desktop linux) - some
without equivalents/alternatives. The only result of this is ubuntu usage
share dropping - people run Operating Systems for Apps/Games/Software, not the
other way around.

------
sneakernets
I'll admit I'm a very fringe case, but I loved the ability to play the
original Microsoft Entertainment Packs on my Mac using WINE. There's just
something about how simple and clean those games are, and people actually like
to see them when I have a paused game of rodent's revenge on one of my
screens.

I really don't want to lose that!

------
devit
I think you can just use 32-bit libraries from Debian for the most part (I
assume Debian is going to maintain i386 forever).

~~~
yjftsjthsd-h
I would be concerned about the stability of mixing distros like that, even
within a family. If nothing else, those packages are built against different
versions of libraries.

~~~
AnIdiotOnTheNet
Which is one of the many reasons I think package managers are awful. If we
lived in a sane world this sort of thing would be a simple matter for any and
all distros. In fact, you wouldn't even need distros because you could
trivially mix and match the software you wanted without concern for this
garbage.

------
yellowapple
I took Ubuntu's dropping of 32-bit support to only apply to the machine
itself, like how openSUSE Leap only supports running on 64-bit hardware but
still supports 32-bit libraries[1]. Sounds like Ubuntu's taking it to an even
greater extreme.

Regardless, I can think of a couple ways around this:

\- Build the 32-bit versions of the relevant libraries and ship them in a
third-party PPA (or - ideally - convince Canonical to do this for Ubuntu, thus
doing what openSUSE Leap is doing)

\- Ship Wine in a snap or AppImage or flatpak or what have you with the
relevant 32-bit (and 64-bit) libraries

[1]:
[https://doc.opensuse.org/documentation/leap/reference/html/b...](https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.64bit.html)

------
ketsa
Debian will keep 32 bit support for a while... No problem here.

------
jostmey
Does the Microsoft Office executable file even come in a 64bit package? It's
not Ubuntu's or Wine's fault

~~~
MikusR
Office has been 64bit for 9 years. And this year it's the default.

~~~
coldpie
Almost all Windows installers are 32-bit, even if the application installed is
64-bit. This is so the installer can do something elegant when run on a
32-bit-only system. While this might be changing, 32-bit support is
effectively required for almost every Windows application ever released.

------
RosanaAnaDana
I've used Wine to run a number of instrument specific pieces of software via
Ubuntu and all of them were 32 bit.

------
dafran
There's ecen an Ubuntu dev urging for more testing before implementing this:
[https://discourse.ubuntu.com/t/results-of-testing-games-
on-6...](https://discourse.ubuntu.com/t/results-of-testing-games-on-64-bit-
only-eoan-19-10/11353)

------
bstar77
Can't you still setup a 32bit chroot in 64bit Ubuntu (or any other distro for
that matter)?

~~~
chrisseaton
But the 32 bit code physically won't be part of the distribution. What do you
imagine you'd be running?

~~~
yjftsjthsd-h
32-bit Debian chroot on 64-bit Ubuntu? Works, mostly conforms to user
expectations, seems decent?

~~~
chrisseaton
Well yes if you're going to run another distro that's fine. This issue is
about that people can't run new Ubuntu. You can't run new Ubuntu in 32-bit.

~~~
zapzupnz
So presumably they'd run old-Ubuntu 32-bit chroot in new-Ubuntu.

------
randyrand
How hard is it to statically convert a 32 bit process into a 64 bit one? And
why?

------
writepub
What would it take for wine to run in 64 bit mode and emulate Win32?

------
tzs
How different is the 32-bit Windows application environment from the 64-bit
Linux application environment on x64 systems, as far as how system calls are
invoked goes, and how memory is accessed?

We had a somewhat similar issue of wanting to run code from a different,
narrower, system, although the systems involved were not anywhere near as
different as Windows and Linux, back in the mid '80s at ISC. We were doing the
386 port of System V Release 3 under contract from AT&T. Part of the contract
required that we add the ability to run binaries from the 286 ports of System
V Release 2 and System V Release 3 [1].

The approach was similar to what Wine does, if my limited understanding of
Wine is correct. We wrote a program, i286emul, which could be pointed at a 286
program. It would allocate memory for the 286 program and load the program
into that memory.

386 Unix was using a simple paging memory model. The 386 still used the
selector/offset system even when using paging, but the selectors were loaded
once when a program started and not touched again. I think it was using what,
in 16-bit land, would be called "small model" (one code segment, one
data/stack segment), but with all the segments set to 4 GB, and the real
memory management done via that paging system that operated below the output
of the selector/offset system.

We had to add a system call (or maybe it was a new command added to an
existing ioctl...I don't remember for sure) that allowed i286emul to ask the
kernel to set up some 16-bit selectors referencing the parts of the i286emul
32-bit address space at which it had loaded the 16-bit program, or at which it
had allocated memory for the 16-bit program's data and stack.

That let i286emul load a 16-bit program into i286emul's address space, get the
selectors set up, and then it could load the selectors and jump into the
16-bit program.

Eventually, the 16-bit program would try to do a system call. Fortunately,
16-bit 286 Unix and 32-bit 386 Unix happened to use different mechanisms for
invoking system calls, so that when 16-bit tried to do a 286 Unix system call
it would be an illegal instruction or a segfault or something like that (I
don't remember the exact mechanism it used), instead of something that would
try to invoke a 386 Unix system call. (As far as I know, this was pure luck
that the people who decided on the 386 system call interface mechanism picked
something different from the 286 system call interface mechanism).

So, to handle system calls we just had to have i286emul handle the fault,
recognize that it was caused by the 286 program trying to do a system call,
and emulate that call. I don't remember if that was as simple as installing a
signal handler for the fault, or if we needed some kernel help.

The only other kernel change I remember was making exec recognize 286
binaries, and turn the exec into an i286emul exec, with the path to the 286
program passed as an additional argument.

Later, when AT&T and Microsoft made a deal to add Xenix binary compatibility
to 386 Unix, we got the contract for that, leading to x286emul, which was very
similar to i286emul. There were a couple of minor areas in which Xenix and
Unix differed that we could not take care of in user mode, so had to add a
kernel flag [2] to have it slightly change some behavior for x286emul.

How hard would it be to take a similar approach with 32-bit Windows on 64-bit
Linux? That is, make it so that a Linux process can reasonably mix 32-bit and
64-code, and give it some control over how 32-bit code sees the processes
address space, and then implement a version of Wine that can handle 32-bit
Windows programs translating their system calls to 64-bit Linux calls? The
issues I can see include:

1\. What is actually different between 32-bit code execution and 64-code
execution as far as the kernel goes? Is there some flag that marks
32-bit/64-bit, or is it mostly that 32-bit code is simply going to use
addressing mode that refer to the double word registers instead of the quad
word registers?

2\. We greatly benefited on i286emul/x286emul by the very different memory
models of the two systems. I'd expect 32-bit Windows and 64-bit Unix to have
very similar models which could be a problem...but I'd expect 32-bit Windows
and 32-bit Linux to be even closer, and Wine dealt with that, so I'm not sure
32-bit/64-bit would add much difficulty.

3\. We also benefited from 286 Unix and Xenix being similar to 386 Unix, so
mostly 286 system calls mapped directly to corresponding 386 system calls,
with just a little translation of arguments and return codes. Windows and
Linux are very different. But Wine is already dealing with that, so as with
memory model it is not obvious that 32-bit vs. 64-bit makes much difference.

[1] ...not that there were actually any System V Release 3 on the 286 programs
anyone cared about, because as far as I know that port was never completed. We
were doing that one for AT&T, too, but there were too many assumptions about
memory management baked into the 3B2 source that were not right for the very
different memory environment of the 286, and maybe halfway through the port
AT&T realized that Release 3 on the 286 was going to suck unless we did some
major rewriting rather than just porting, and the 386 was so much better than
on one was going to give a damn about running Release 3 on a 286 even if it
did not suck, and dropped the port.

[2] That stupid flag led to the most annoying meeting I have ever attended.
For x286emul, we were just doing the user mode code. Microsoft was doing any
kernel changes we needed. They said an issue arose with our request for this
flag that could not be resolved by email or phone. Me and the other guy who
were writing x286emul had to fly from LAX to SEATAC, go all the way over to
Redmond, to resolve this thing in person.

We got to the meeting, and they presented the issue: should controlling the
flag be via a new system call, or via a flag on the system call (or ioctl...I
never can remember which it was) that is used for some of the other 286
emulation control? We gave out preference on that, and were sent home. How the
heck could that not have been handled by email or phone?

------
wtdata
I do use Wine (and Steam with it's various levels of Windows API calling), and
I am happy about this.

Sure, it will create some issues during the first stages of this migration,
but, more than once, I botched my system in the past with the needed i386
libraries (it didn't happen lately, can't tell if because I finally got my
head around it of because they improved the tooling).

Still, in the end, we will all have a "cleaner" system. Either because they
migrate parts of the Windows calling to 64bit or because they will keep
everything neatly in containers, or, probably, due to a mix of both. But it's
high time we improve the current state of these tools.

P.S.: Still trying to get WINASIO to work properly with Wine using one of the
latest versions (I am trying to run Ableton in Wine, but the latency is just
too high). If anyone has experience doing this, any tips would be apreciated.

~~~
holy_city
I think even if you got the drivers working you'd have too much latency. You
need the PREEMPT_RT kernel patch to get reliably low latency.

You can also try Bitwig, it has native Ubuntu support and most feature parity
with Ableton.

~~~
james-mcelwain
I'm so happy that Bitwig is supporting Linux as a first class platform, but
it's still unstable enough on Linux that I would never consider using Bitwig
on Linux for, e.g., a live performance.

I'm sure they consider crashes on Linux real bugs, so hopefully it's just a
few more years of work to have a rock solid DAW on Linux. Super excited about
the future of Bitwig.

------
Otnix
There are thousands and thousands of applications available for Linux, and
even more being developed as you read this. As much as I love Linux and Open
Source, sometimes you happen to love a Windows application so much that you
wonder if only this was available on Linux I would completely switch

------
trollied
I have a sneaking suspicion that Microsoft will release their own Wine-a-like
subsystem some time soon.

It's the missing link, and I can't see them ignoring it given how their
direction has changed over the last few years.

~~~
RussianCow
I doubt that's the case. Everything they've been doing with WSL is precisely
to keep you _inside_ the Windows OS. It doesn't make sense to go the other way
and give you a reason to use Linux instead.

~~~
dragonwriter
> It doesn't make sense to go the other way and give you a reason to use Linux
> instead.

It makes sense for every business unit _except_ Windows to make it easier to
run their software on Linux/MacOS (for desktop software, more the latter, for
server software, more the former.) A common shim that lets you so that with
the same codebase rather than maintaining separate Linux and MacOS versions or
porting the whole existsling software to a cross-platform base rather than a
Windows base makes some sense.

Of course it doesn't make sense for the Windows unit to promote Linux, but
Windows isn't all of Microsoft.

~~~
RussianCow
I could be wrong, but I think the overlap of people who use Linux but would
also pay for Microsoft software like Office is small enough to not justify the
engineering effort.

------
xvilka
Well, the best solution would be to fix Wine for 64 bit platforms and
applications. And use docker + wine for 32 bits ones.

~~~
the_duke
The very first paragraph in the article explains why this does not work...

Unless you mean building a 32bit emulation layer into Wine itself.

------
postit
In the current state of technology, wine doesn’t make sense anymore.

20-ish years ago was impossible to have an interchangeable application between
two OS, without a huge effort on porting and adaptations trade off. Now we
have the web applications running in a handful of different systems. We’re
also watching the people theorizing supporting webassembly binaries directly
in the kernel. If you don’t want to run a webapp you have virtualization to
rescue you.

My last straw with Wine was when I bought navicat for Linux and they shipped a
wine wrapped windows app. Really, some tech should just retire.

~~~
tombert
First off, there are plenty of older Windows applications that currently exist
that aren't going to get a port to a modern web app any time soon that work
perfectly fine with Wine; even Microsoft doesn't support running Windows 3.1
programs anymore. You could argue that nothing from that era is worth
preserving, but are you saying that applications like DOSBox, Snes9X, or UAE
aren't useful?

Second, while I definitely support the push to web technology, I'd still
rather have _something_ on Linux or Mac than nothing, and often times Wine is
the only realistic way of doing that. I agree it's a little annoying when you
buy a "Linux" app, and it's just a wine wrapper, but at the same time, at
least it's officially supported and works. I didn't get upset with SEGA when I
bought the Sega Genesis collection and it used emulation instead of native
ports.

