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

[skeevy420]

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.

And what's funny is that I have no problem with that. My problem is their solution of DIY and that it appears to be unsupported.

Why use a supposed noob distribution that may or may not need another distribution as a chroot* in a possibly unsupported manner over a distribution that actually supports multilib or chroots*?

*or VMs or containers or whatever...I'm not being picky here.

[jo-erlend]

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?

[oiaohm]

I remember something else important. https://en.wikipedia.org/wiki/Year_2038_problem

2038 clock problem effects the Linux kernel 32 bit syscall calls. To use time domains to cover this problem applications need to be on cgroups/namespaces. So in some ways getting rid of 32 bit support from the default install and forcing those programs into flatpaks or docker or snap is the correct solution.

[schmidtbag]

You.

No, I really didn't.

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

No... I literally didn't... I never used those words.
I said it's their job to pre-package libraries that will get their application running. I didn't say they needed to provide GPU drivers, glibc, or whatever else.
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.

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

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

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.

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.

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.

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. Why is this so hard to understand?

[oiaohm]

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. Why is this so hard to understand?

You have to remember the 32 bit syscall system of Linux has the 2038 problem. To use time domains you will at some point want to get 32 bit applications in containers. There maybe absolutely no valid reason for the host OS to maintain 32 bit userspace as this maybe maintaining a problem. Basically host and guest separation.

Forcing 32 bit into snap or flatpak or docker could absolutely be the right way forwards. Wine developers with hangover and what being developed for OS X is working to a world where 32 bit does not exist at all in the kernel or host API this is painful.

The question that has not been answered that is critical is will 32 bit snap/flatpak/docker/chroot in fact still work on 19.10 if so its an annoyance most likely to get us to migrate away from the multi lib solution to a containerised solution that will be required in time to deal with using linux 32 programs past 2038 by using time domains.

[Azrael5]

It is probable that this won't happen on large scale within our lifetimes. Today is limited just to toy examples of such a technology.

SO, the only solution is to have a legacy computer provided by legacy Os, such as XP as example, where to play legacy games.

[Weasel]

You have to remember the 32 bit syscall system of Linux has the 2038 problem.

It doesn't. Only the old API has it. And for most apps, time doesn't really matter, so who cares? If the app is online, I'm pretty darn sure it uses the new APIs with 64-bit time_t, since it's probably updated. If it's offline, wrong time is merely an inconvenience in most cases.

[oiaohm]

It doesn't. Only the old API has it. And for most apps, time doesn't really matter, so who cares? If the app is online, I'm pretty darn sure it uses the new APIs with 64-bit time_t, since it's probably updated. If it's offline, wrong time is merely an inconvenience in most cases.

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. 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).

Offline this 99% of cases clock being wrong who cares but overflowed 32bit time causes different program code to go stupid reason why path of change the EPOCH has been built into the Linux kernel and moving the EPOCH means application has to be in namespace/container of some form..

Time domains in the Linux kernel are namespace feature and you apply namespaces on per container base if you want stablity.

[chithanh]

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.

No, this is wrong. What is unsupported in long (64-bit) mode is the virtual 8086 mode code. 16-bit protected mode code is supported. And that is precisely what Wine does, use emulation for v86 and native execution for protected mode.

Windows however supports no 16-bit code at all in long mode, which is probably how people have gotten the idea that the CPU doesn't support it.

What about this?

35% of Americans are PC gamers

Given that Steam is by far the most popular PC gaming storefront, and Steam has around 90 million monthly active users, and that PC global installed base is 2.2 billion, I'll let you do the math.

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

That would be hard to believe, given that LibreOffice is installed by default on Ubuntu desktop.
If by "Ubuntu statistics" you mean Ubuntu popcon, that has several problems, being skewed towards those who opt-in to popcon, and the fact that until recent years, Windows software was necessary for citizens to submit taxes to financial authorities in several countries where Ubuntu is popular.

Also, for whatever reason, OpenOffice is even more popular than LibreOffice and Wine in Ubuntu popcon, so there's that.

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

They don't say it's not gonna happen, they say it is not ready for end users.

[chithanh]

This is not really related to this discussion, but two inaccuracies that I would like to point out:

Modern UWP and PWA apps are all you need!

UWP is widely seen at the end of its road. There is almost nothing left which goes for UWP. Even Microsoft basically stopped development of their UWP Office apps, and there were several high-profile departures (e.g. Twitter) switching from UWP to PWA.

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

Microsoft tried to sell Windows RT without Win32 support and they failed. That's why they put a lot of effort into providing support for transparent x86 emulation in Windows 10 on ARM. They know that without it they have absolutely no chance in this market.

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. 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.