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

[the_scx]

I really don't understand the problem. We have years to implement support in a more sustainable way.

There is no more suitable way than multilib/multiarch. And never will be.

Why the extreme panic? Linux users are so incredibly emotional.

Valve drops support for Ubuntu 19.10+.
WINE developers drops support for Ubuntu 19.10+.
GOG doesn't care too much about Linux, but probably will drop support for Ubuntu 20.04+ LTS (they don't support non-LTS versions at all), at least for 32-bit games.

Explain to me why your 1990s game MUST at all times have the very newest version of a given library?

Try to run Grand Theft Auto V or The Witcher 3: Wild Hunt under WINE 1.6, without DXVK, and tell me how it works.
Why WINE 1.6? Because it was the latest stable release 5 years ago.

You think that 32-bit support is about legacy software? Then you are wrong.

https://www.phoronix.com/forums/forum/software/distributions/1107716-openmandriva-is-also-making-plans-to-move-away-from-32-bit-support?p=1108036#post1108036

[the_scx]

No, I really didn't.

Oh yes, you did.

No... I literally didn't... I never used those words.

But these were exactly your words.
And I believe you that you didn't mean it, but you said it.

I said it's their job to pre-package libraries that will get their application running.

Yes.

I didn't say they needed to provide GPU drivers, glibc, or whatever else.

But these components are required by software. They can be provided either by the system vendor or the app developer. And I think that the system vendor should care about this, because it is their job to do this.
Of course, we need to distinguish what should belong to the system and what should belong to the application. Anyway, the main components should be provided by the system. Game can provide SDL2 or OpenAL Soft on its own (or use runtime environment like Steam Runtime), but glibc and GPU drivers should be provided by the system.

I have encountered many closed-source programs that required an old version of a library that didn't come with my distro. Those programs often ship their own, and it works fine.

And now we have a situation, in which Steam games come with a bunch of libraries, use Steam Runtime, but even this is not enough for Ubuntu 19.10+.
And for GOG games, this situation is even worse.

Yes, there is. You just seem to keep thinking it involves something far more drastic than is necessary.

It involves Canonical participation, but they are not going to do anything about this. That's the problem.

I agree the wine devs aren't interested in fixing Ubuntu, nor should they be. I also agree it's Canonical's job. That doesn't mean it's a difficult job.

This is super easy for Canonical, but extremely hard for others. That's why Canonical should do this.

And the 2nd best they can do is give a partial i386 repo that just contains the necessary packages to get these 32-bit programs working.

That's exactly what I said from the very beginning. I'm glad you finally agreed with me. Unfortunately, Canonical is not interested in such a solution.

Why is this so hard to understand?

I really don't know why it is so hard to you to understand simple things.

[the_scx]

UWP is widely seen at the end of its road.

No, it isn't. I mean, almost everyone is going to abandon it, but Microsoft still believes that this it the future of the Windows Platform.
And it won't die, because it is used in Xbox.
For the record, I am definitely not a fan of UWP, Silverlight, Windows 10 Mobile, Windows Phone, Zune, MSN, CodePlex, Bing, Windows Live, Games for Windows, etc. I don't even like Xbox.

PWA and Win32, that is Microsoft's forseeable future.

Win32 won't be supported OOTB in Windows Lite. Win32 apps are not supported in Windows 10 S Mode.
Of course, 3rd party developers don't give a shit about UWP apps, but the same applies to Snaps when it comes to games and the most professional software (like Autodesk Maya). However, it should be noted that Canonical was able to convince some developers to publish theirs apps here (e.g. JetBrains products).

You know what is funny? There are already more paid commercial games in Microsoft Store than in Snap Stores. Of course, the first ones use Desktop Bridge. And there are not too many of them. But still, even here Microsoft wins.

That is not quite correct. Windows RT had full Win32 support, this was demonstrated on jailbroken Surface RT devices. Microsoft just chose to not expose this to users.

End users don't care what is under the hood. They care only about what is exposed to them and what is easy to use. That's why Android users doesn't care about running GNU/Linux apps on theirs smartphones.

Also the "transparent x86 emulation" (actually it is binary translation) is not new, DEC FX!32 for Windows NT Alpha had this more than 20 years ago, running at 40% of native speed. Microsoft was able build on existing technology and expertise here.

So, what is the point? Everyone knows that.
Anyway, as you can see, Canonical is unable to provide solutions similar to these from 25 years ago.

[oiaohm]

WINE developers drops support for Ubuntu 19.10+.

Wine is likely to support Ubuntu 19.10+ going forwards with the 64 bit version straight. Ok not very functional but those users will come tested bed for hangover for installers at least.

Its also likely that wine will also do a snap or flatpak. Snap being 18.04 based for running on 19.10+.

Wine supporting a platform does not mean 32bit support has to work.

I would say this plan to drop 32 bit support has been in the works for awhile. libfaudio0 a new dependency wine needs since Mar 29, 2019 ie 4.5 have had a hard time getting any notice when it going to be going into 18.04. So something has been up for 3 months.

So, what is the point? Everyone knows that.
Anyway, as you can see, Canonical is unable to provide solutions similar to these from 25 years ago.

https://ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc/

Canonical ships all the part to perform transparent x86 emulation bar a GUI to make it easy to setup. The solution was in debian before the first version of Ubuntu was ever made. This is why 32 bit support removed at syscall level is more a curse of low performance than a absolute deal breaker of run nothing. Yes 64 bit bit Linux kernel built without 32 bit syscalls you can put 32 bit support back by declaring qemu in binfmt_misc and that happens when you install qemu-user package under ubuntu.

Yes 32 bit Mesa will talk to 64 bit Linux kernel graphics driver with qemu in middle doing the translation and in fact work.this does not in fact work for users who are using Nvidia closed source drivers. Nvidia drivers do some direct memory things qemu does not catch and translate.

[chithanh]

No, it isn't. I mean, almost everyone is going to abandon it, but Microsoft still believes that this it the future of the Windows Platform.
And it won't die, because it is used in Xbox.
For the record, I am definitely not a fan of UWP, Silverlight, Windows 10 Mobile, Windows Phone, Zune, MSN, CodePlex, Bing, Windows Live, Games for Windows, etc. I don't even like Xbox.

Major Microsoft-centric news outlets like Paul Thurrott and ZDNet's Mary Jo Foley seem to think or imply that UWP is pretty much dead.
Yes, UWP apps will still work going forward, but there will not be a reason to use it for development going forward. Microsoft themselves have announced that all the remaining functionality that UWP has over Win32 will come to Win32. Just yesterday there was the latest high profile departure, Dropbox.

Win32 won't be supported OOTB in Windows Lite.

Eh, what will work at all then? The new Edge browser is Win32.
Its engine is used to power PWAs.
So no browser, no Win32 apps, no PWAs. Only UWP? I think Microsoft themselves know that this is not going to work out.

Win32 apps are not supported in Windows 10 S Mode.

They are. The limitation in S mode is Store apps, not UWP. The operating system still comes with lots of Win32 apps.

Of course, 3rd party developers don't give a shit about UWP apps

They used to. Twitter, Dropbox, etc. had UWP apps at some point. But they are mostly gone to PWA now, after seeing the writing on the wall.

You know what is funny? There are already more paid commercial games in Microsoft Store than in Snap Stores. Of course, the first ones use Desktop Bridge. And there are not too many of them. But still, even here Microsoft wins.

I don't know what that has to do with anything. Of course Ubuntu offering paid software to Linux users is a tough sell. I don't think anybody ever disputed that.

End users don't care what is under the hood. They care only about what is exposed to them and what is easy to use.

That wasn't the point. If the lack of Win32 was what prevented the success of Windows RT, then Microsoft could have just flipped the switch and allow them. Apparently it was not.

If the lack of x86 support was the problem, they could have implemented an FX!32 like solution over the course of a few months. The x86-to-aarch64 implementation for Windows 10 S was done some time during 2016 by what was apparently a very small team.

That's why Android users doesn't care about running GNU/Linux apps on theirs smartphones.

On the contrary. It is not for everyone, but the ability to have a mobile (not just portable) device plugging into the next monitor's USB-C port is going to transform personal computing. It is not quite ready for end users yet, and businesses will see adoption first, but the first company to make it will grab a significant share of that market.

So, what is the point? Everyone knows that.
Anyway, as you can see, Canonical is unable to provide solutions similar to these from 25 years ago.

i386 code on x86_64 needs no binary translation. It is however a maintenance and QA burden.

Whether Canonical is going to ship binary translation from x86 to aarch64 is unclear at this point, but I doubt it. x86_64 to aarch64 maaaaaybe.

[Weasel]

If make a BPF profiling item to detected 32 bit time usage and apply to 19.04 ubuntu you will find most of the online 32 bit applications are using 32 bit time in different areas.

Citation needed.

So your pretty darn sure is horrible wrong you really need to stop guessing so a lot of those programs are dead man walking for open online usage. Windows API for 32 bit also includes usages of 32 bit time and if you trace that you find the same bugger me. The issue since 32 bit time is able to be used in Linux and Windows 32 bit binaries in the API programmers are using it by mistake or lack due care or program is simply no longer maintained without source code so no possibility of fixing(so true legacy stuff).

Uh no, the Windows API operates with 64-bit time structs or with structs containing words for years/months/days/milliseconds, both of which won't overflow.

https://docs.microsoft.com/en-us/windows/desktop/api/minwinbase/ns-minwinbase-filetime

Again, bullshit without evidence.

[chithanh]

Weasel
Citation? Just compile and run the following code yourself on 32-bit and 64-bit x86 Linux:

#include <stdio.h>
#include <time.h>

int main() {
    printf("The size of time_t is %zu\n", sizeof(time_t));
}

About your "bullshit" claim: Visual Studio up to version 2003 uses 32-bit time_t on x86. Since version 2005 it defaults to 64-bit time_t unless _USE_32BIT_TIME_T macro is defined[1, 2].
So almost all Windows x86 software built with VS2003 or earlier and which uses time_t will potentially be affected by the year 2038 problem.

[1] https://docs.microsoft.com/de-de/cpp...t?view=vs-2019
[2] https://docs.microsoft.com/de-de/cpp...4?view=vs-2019

[schmidtbag]

I really don't know why it is so hard to you to understand simple things.

I understand perfectly fine, but your childish way of responding is getting us nowhere.

For the record: the news yesterday that broke out pretty much confirmed what I thought Canonical was going to do. It isn't exactly ideal, since they aren't really keeping the 32-bit packages very up-to-date, but clearly sit shows I understood the situation well enough that your "corrections" were largely moot.

[duby229]

I really don't understand the problem. We have years to implement support in a more sustainable way. Why the extreme panic? Linux users are so incredibly emotional.

Explain to me why your 1990s game MUST at all times have the very newest version of a given library?

obviously, its because many, many libraries and drivers don't implement stable interfaces, you -have- to keep them updated or they break.

[the_scx]

Major Microsoft-centric news outlets like Paul Thurrott and ZDNet's Mary Jo Foley seem to think or imply that UWP is pretty much dead.

And major information portals claim that x86 support in Ubuntu is dead. But Canonical say something completely different.

Anyway, the Microsoft's position is quite clear on this:

Officially, the story is UWP is alive and well.

And that's what I was talking about. Reality doesn't matter.

BTW:

Microsoft's Universal Windows Platform is not dead, but it has evolved over the years

This article was published at 7 Jun, 2019, so it's quite new.

Yes, UWP apps will still work going forward, but there will not be a reason to use it for development going forward. Microsoft themselves have announced that all the remaining functionality that UWP has over Win32 will come to Win32. Just yesterday there was the latest high profile departure, Dropbox.

Desktop Bridge in UWP is almost the same thing as i386 Core 18 in Snaps. But we already know that none of these solutions is suitable for everything.

https://www.neowin.net/news/python-for-windows-10-launches-in-the-microsoft-store-but-with-some-limitations/

Currently, the py.exe launcher cannot be used to start Python when it has been installed from the Microsoft Store.

Because of restrictions on Microsoft Store apps, Python scripts may not have full write access to shared locations such as TEMP and the registry. Instead, it will write to a private copy. If your scripts must modify the shared locations, you will need to install the full installer.

Eh, what will work at all then? The new Edge browser is Win32.
Its engine is used to power PWAs.
So no browser, no Win32 apps, no PWAs. Only UWP? I think Microsoft themselves know that this is not going to work out.

https://www.petri.com/how-microsoft-edge-on-chromium-will-change-the-windows-10-lite-and-s-mode-proposition

Unravelling years of legacy code in Windows has been an ongoing mission at Microsoft. First, we had MinWin, then OneCore, and now Windows Core OS (WCOS). But ultimately for end users, this work will culminate in a new OS for mobile devices. Codenamed Santorini, and sometimes referred to as Windows Lite, it is built on top of WCOS and it is a truly stripped back OS designed for users that don’t need the full power of Windows. As Microsoft’s answer to Chrome OS, Windows Lite will run UWP and PWA apps, and updates will be installed in an offline-mirrored partition so that there is no waiting when you reboot.

Of course, I don't believe that they will succeed, but it doesn't matter here.

They are. The limitation in S mode is Store apps, not UWP. The operating system still comes with lots of Win32 apps.

Again, there is no single native Win32 app in Mcrosoft Store. Each Win32 has to use Desktop Bridge. And it comes with limitations. It is almost the same situation as for Snaps.

They used to. Twitter, Dropbox, etc. had UWP apps at some point. But they are mostly gone to PWA now, after seeing the writing on the wall.

Both MonoDevelop and Visual Studio Code developers have dropped support for Flatpak (flatpak package for VSC is supported by community, but it is irrelevant here). Does it mean that Flatpak is dead?
Anyway, I never said that UWP will be successful. What matter here is how Microsoft see its future and what is official statement.

I don't know what that has to do with anything. Of course Ubuntu offering paid software to Linux users is a tough sell. I don't think anybody ever disputed that.

Microsoft Store has been repeatedly described as the worst app store in history. But even so, it attracted more game developers than the Snap Store.

That wasn't the point. If the lack of Win32 was what prevented the success of Windows RT, then Microsoft could have just flipped the switch and allow them. Apparently it was not.

It wouldn't be enough, because people expected support for the x86 Win32 applications. Microsoft tried to sell Windows RT as a new platform, like Android or Chrome OS are compared to the typical GNU/Linux distributions. But of course they failed.

If the lack of x86 support was the problem, they could have implemented an FX!32 like solution over the course of a few months. The x86-to-aarch64 implementation for Windows 10 S was done some time during 2016 by what was apparently a very small team.

Oh, and now you see that lack of support x86 (including x86-32) is a problem. Great!

On the contrary. It is not for everyone, but the ability to have a mobile (not just portable) device plugging into the next monitor's USB-C port is going to transform personal computing. It is not quite ready for end users yet, and businesses will see adoption first, but the first company to make it will grab a significant share of that market.

Microsoft already presented Windows 10 Continuum, but it doesn't worked out.

i386 code on x86_64 needs no binary translation.

I never said that. All it needs is a f*cking multilib/multiarch support. It is the best and easiest way to provide support for i386 apps.
But instead, we hear that we should use Snaps, LXD containers or even virtual machines. There is absolutely no reason to use QEMU-based virtualization and Virgl here, but some people here call it a "solution".

It is however a maintenance and QA burden.

Please, stop this bullsh*t. Multiarch support costs Canonical almost nothing. There is no other distro that have problem with this. Canonical has a lot of money from x86 desktop, and this is why they should support them properly.

Whether Canonical is going to ship binary translation from x86 to aarch64 is unclear at this point, but I doubt it. x86_64 to aarch64 maaaaaybe.

It is clear to me that Canonical is not interested in serious support for Linux desktops, so it is not gonna happen. What is worse, support for ARM hardware (mainly Snapdragon-based ACPC laptops) is pathetic. Apart from numerous problems with various components, Freedreano is even worse than Nouveau, so there is no point to buy expensive hardware and use Linux on it, while support for Intel-based ultrabooks is almost flawless.

Anyway, this discussion does not make much sense.
The point is that the Win32 and POSIX apps are "legacy", and UWP and PWA are "modern". But as we can see, modern not always mean better. The same applies to x86 vs RISC-V. That's all I wanted to say.