Wine Developers Appear Quite Apprehensive About Ubuntu's Plans To Drop 32-Bit Support

[the_scx]

But it can, and because of the choice Canonical made, it might have to.

They do not have to do anything. But maybe Canonical will be forced to do something, because both WINE developers and Valve stated that they are not going to support Ubuntu 19.10+.

https://twitter.com/Plagman2/status/1142262103106973698

Ubuntu 19.10 and future releases will not be officially supported by Steam or recommended to our users. We will evaluate ways to minimize breakage for existing users, but will also switch our focus to a different distribution, currently TBD.

[oiaohm]

They do not have to do anything. But maybe Canonical will be forced to do something, because both WINE developers and Valve stated that they are not going to support Ubuntu 19.10+.

https://twitter.com/Plagman2/status/1142262103106973698

Question do Steam they need to support 19.10+ as long as flatpak works on 19.10+. Flatpak option will work as long as Ubuntu does not switch of the 32 bit syscalls at kernel level.

Wine developers have not set stuff in stone. 19.10 release will be before wine project is ready. Wine had been working on building more libraries at PE format and not depending on outside glibc this is all prep work required for hangover support.

https://www.winehq.org//announce/4.11

Notice how much here is Build with msvcrt. Wine developers are still working on how they will deal with problem.

Hangover project is under 12 months old. With plan of needing another 12 months to be ready for users at least. 4 months to cover 12 months work is a problem. 10 months to LTS is more sane. More notice would have been nice. I would say 19.10 if 32 bit support is missing will be unlikely to have wine suitable 20.04 high horrible maybe. This is not a Valve total no way.

Remember Ubuntu 19.10 64 bit only problem matches the issue on Android.

https://developer.android.com/distribute/best-practices/develop/64-bit

Android the Linux 64 bit kernel is built missing 32 bit syscalls.

How bad Ubuntu 19.10 charge is depends on if they have got rid of 32 bit syscalls or not. There are old 64 bit bit only Linux distributions that are also missing 32 bit syscalls.

[the_scx]

I see both more in the single-digit percentages of desktop users.

What about this?

35% of Americans are PC gamers

What is more, Ubuntu statistics say that WINE is more popular than LibreOffice.

No need to reprogram any Win32 application. The proposed solution is implementing thunking, which is already in use for interfacing between Win16 and Win32.

And we already know that this not gonna happen.

https://www.winehq.org/pipermail/wine-devel/2019-June/147949.html

https://www.winehq.org/pipermail/wine-devel/2019-June/147959.html

Now who does the implementation and when is entirely another question, Ubuntu surely won't do it, nor will it happen in time for 19.10.

And users care about working and polished solutions, not something purely hypothetical that might never be implemented.

[the_scx]

Who said anything about developers providing glibc and GPU drivers?

You.

But it can, and because of the choice Canonical made, it might have to.

But again... they could just pre-package the necessary libraries.

---

Who said it had to be used for everything? I'm only suggesting to use it in a few niche cases where someone needs to run a closed-source 32-bit application in need of a handful of obscure 32-bit libraries...
You seem to be taking everything I'm saying and contorting it to the absolute worst-case extreme scenario.

Again, you said this. You literally said that it is their job to do this.

Note how in this context I'm only referring to closed-source software... For close-source programs, yes, it very much is their job to do this because (as I'm sure everyone here who has used closed-source software in Linux can attest to) using your distro's libraries often don't work with the application if you don't have the right version. This is precisely why so many closed-source programs ship their own libraries.

---

Then mind explaining how I can so effortlessly install 32-bit libs for things like Wine?

There is no easy solution here. At least for 3rd party developers/packagers. For Canonical it is trivial.

---

Because all they have to do is retain that functionality. They don't need the entire 32-bit repo to do that. It's just a few hundred MB of lib packages and maybe something like mesa or glibc. That's it. Any obscure 32-bit library Ubuntu doesn't come with can be shipped by the application itself, which is usually how it works, and it tends to work out just fine.

So? WINE developers are clearly not interested into fixing Ubuntu.
I can agree that the minimal multilib/multiarch setup would be fine, but this is Canonical's job to do this. No one will do this for them.

---

Actually, I do understand what they're doing, but you don't understand what I'm saying. Frankly, I'm tired of trying to explain this. It's not that you and duby229 don't know what you're talking about because I trust that you do, but you're misinterpreting what I'm saying, and it really doesn't matter what I say at this point because Canonical is going to figure this out one way or another.

The best they can do is to reverse this stupid decision. It is really easy, but it must be done by them, not someone else. I believe that it is still possible, especially looking at the comments from Valve and WINE developers.
Of course, they can drop i386 port. But without multiarch support, it will be a disaster.

[oiaohm]

And we already know that this not gonna happen.
https://www.winehq.org/pipermail/win...ne/147959.html

You say something and then not read what you quoted to back it up.

The README explains that it currently doesn't work very well, and it
goes into a lot of detail about the technical challenges of this
approach.
There are other possible approaches, but they all pose similar challenges, and no solution for running 32-bit applications without 32-bit host libraries is ready for users yet. CodeWeavers is working on a solution for MacOS, which will soon be dropping its 32-bit libraries. LIke hangover, this is not ready for users, and it's not targeting Linux. We don't expect it to have the same level of compatibility or performance that 32-bit Wine has today.

For Android and for MacOS solutions without 32-bit host libraries or 32 bit syscalls have to be made this basically means virtual machine. Do notice what I turned into bold ends on "yet" at some point there will be solution and the wine developers are looking for it and working on it. So win32 and win16 on a pure Linux 64 bit system will happen at some point problem is 19.10 Ubuntu will be out before those solutions have the time to be ready. Not going to happen in the wine code base in time for 19.10 release I would say is true. 20.04 might have a chance that enough exists that 64 bit applications with 32 bit installers work. Then a few more release of ubuntu after that before it decent this will be like how it played out when vm86 was removed and wine had to start using dosbox.

So? WINE developers are clearly not interested into fixing Ubuntu.
I can agree that the minimal multilib/multiarch setup would be fine, but this is Canonical's job to do this. No one will do this for them.

Wine requires are not that minimal those who flatpak wine find this out. Work to support hangover and Codeweavers solution for MacOS will reduce the size of runtime wine needs. We are seeing wine DLL reduce their external usage of glibc now. There has been a lot of quick options of just use a host library because host will have it. To improve performance when you don't have host libraries some of this stuff will have to be changed.

I agree that Wine developers are not going to fix Ubuntu. But wine will address the problem Ubuntu 19.10 will have in time not because Ubuntu needs it but because they need it for Android and OS X.

The best they can do is to reverse this stupid decision. It is really easy, but it must be done by them, not someone else. I believe that it is still possible, especially looking at the comments from Valve and WINE developers.
Of course, they can drop i386 port. But without multiarch support, it will be a disaster.

Level of disaster I am not sure of. Worst level is multiarch and 32 bit syscalls gone this is Android/OS X level problem. Not a hope in hell the decision need to be undone now.

If Ubuntu 19.10 Linux kernel still has 32 bit syscalls this means snap and flatpak and docker can work for 32 bit applications. This could be transition stage where wine and steam has to be inside snap or flatpak packages. If it this second option it will be annoying change but you still will be able to run all applications with more work.

Do remember Ubuntu owner Canonical is also in charge of snapcraft.io so they can decide to address the multiarch problem by making all 32/64 bit combination programs be on snapcraft.io as distribution neutral packages as long as they don't kill off the 32 bit syscalls on 64 bit kernels.

the_scx would have paid if you had read what the wine developers wrote word for word. Wine developers are not saying the same thing as Valve. Valve with steam is saying no way. Wine developers are saying we need more time how much more time they don't exactly know.

[carewolf]

No need to reprogram any Win32 application. The proposed solution is implementing thunking, which is already in use for interfacing between Win16 and Win32.

Win16?

x86 pre i386 is quite different. x64 processors in x64 mode can't even run those instructions, and Linux has never supported anything before i386. So it is like running ARM instructions, it is emulated.

Support for i386 though is needed by both Wine and by proprietary games and applications that have been kind enough to be released for Linux. It is needed to run old binaries both those for Windows through Wine, and those for Linux. And emulating i386 on x64 is not really a thing, because x64 can run it natively, so nobody has bothered writting that as it would a waste of time, all you need to do is provide the most basic libraries for i386 in your distro.

[oiaohm]

Win16?

x86 pre i386 is quite different. x64 processors in x64 mode can't even run those instructions, and Linux has never supported anything before i386. So it is like running ARM instructions, it is emulated.

This is not true x86 Linux kernel supports starting up a 16 bit protected mode the only known user is wine. The 16 bit protected mode support is to run win16 binaries.

Yes i386 can run win16 binaries. x86 processor supports 16 bit, 32 bit and 64bit protected in long mode. Yes vm86 mode that was need for dos binary compatibility disappeared. Microsoft decided not to implement 16 bit protected mode on their 64 bit operating systems this is not that the cpu cannot do it.

Support for i386 though is needed by both Wine and by proprietary games and applications that have been kind enough to be released for Linux. It is needed to run old binaries both those for Windows through Wine, and those for Linux. And emulating i386 on x64 is not really a thing, because x64 can run it natively, so nobody has bothered writting that as it would a waste of time, all you need to do is provide the most basic libraries for i386 in your distro.

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/why-thunking-is-necessary

Windows when doing particular things you are thunking from 32 to 64 bit. Under wine currently you are not thunking in all the areas that a real windows does. Thunking those areas will reduce the number of host dependency 32bit libraries wine needs.

So how many basic libraries wine needs to run 32 bit wine will depend on how much can be thunked. Also remember wine allows using windows PE files so if the library that wine has been using can be built for windows 32 bit maybe then it not need as host runtime file.

Basically there is a lot of work to restructure wine to work out how small the dependency on 32 bit host libraries can be made. Not something that can happen quickly.

[carewolf]

This is not true x86 Linux kernel supports starting up a 16 bit protected mode the only known user is wine. The 16 bit protected mode support is to run win16 binaries.

Yes i386 can run win16 binaries. x86 processor supports 16 bit, 32 bit and 64bit protected in long mode. Yes vm86 mode that was need for dos binary compatibility disappeared. Microsoft decided not to implement 16 bit protected mode on their 64 bit operating systems this is not that the cpu cannot do it.

Ah, it can run 16bit proctected mode, but not real mode, unreal mode, or virtual 8086 mode. I think a saw a too simplified overview over that once.

[duby229]

But... you can't depend on closed-source programs being maintained like that. So, when you pre-package everything it needs in order to run, you solve the compatibility issues.

No you don't... In -all- cases glibc is depended on at the bottom of that dependency graph, and if the glibc you compiled against is not fully compatible with the glibc on your system then it will not work. That -always- happens when the glibc you compiled against is significantly older than the one you have available. Your -only- option in cases like that is a chroot with a significantly old glibc.

[duby229]

Who said anything about developers providing glibc and GPU drivers?

Who said it had to be used for everything? I'm only suggesting to use it in a few niche cases where someone needs to run a closed-source 32-bit application in need of a handful of obscure 32-bit libraries...
You seem to be taking everything I'm saying and contorting it to the absolute worst-case extreme scenario.

Then mind explaining how I can so effortlessly install 32-bit libs for things like Wine? Because all they have to do is retain that functionality. They don't need the entire 32-bit repo to do that. It's just a few hundred MB of lib packages and maybe something like mesa or glibc. That's it. Any obscure 32-bit library Ubuntu doesn't come with can be shipped by the application itself, which is usually how it works, and it tends to work out just fine.

Actually, I do understand what they're doing, but you don't understand what I'm saying. Frankly, I'm tired of trying to explain this. It's not that you and duby229 don't know what you're talking about because I trust that you do, but you're misinterpreting what I'm saying, and it really doesn't matter what I say at this point because Canonical is going to figure this out one way or another.

Because you -have- to. Glibc is -NOT- a stable user facing interface. You would have to provide a glibc, but that would only work in a chroot. If you provide a glibc, and you would have to, then you have to provide an entire chroot. It won't work otherwise.

EDIT: Canonical is -not- going to figure this out. The -literal- only option is going to be a 32bit chroot. There will be no other way.