I recently noted that some Linux* distributions stop their x86 32bit flavor because 32bit care occupies lots of time (apparently more and more since AMD64 mechanisms are missing) not outweighed by the number of 32bit platform users remaining.
I also noted that apparently, there is no way to compile/link the Wine32 executable with 64bit libs.
Since I’m a developer by profession, I would like to ask what the main problems are and if I can help.
Any notes welcome.
On Wed, Jan 15, 2020 at 6:43 PM Klaus-J. Wolf yanestra@gmail.com wrote:
I recently noted that some Linux* distributions stop their x86 32bit flavor because 32bit care occupies lots of time (apparently more and more since AMD64 mechanisms are missing) not outweighed by the number of 32bit platform users remaining.
I also noted that apparently, there is no way to compile/link the Wine32 executable with 64bit libs.
Since I’m a developer by profession, I would like to ask what the main problems are and if I can help.
Any notes welcome.
Hi Klaus,
Just my 2 cents...
While many Linux distributions are ending support for the x86 32bit kernel, most are continuing to support a limited set of x86 32bit libraries for now. Looking forward, something will need to be done of course...
Recently Apple completely dropped 32-bit support for their latest version of OS X, and members of the Codeweavers team did a great deal of work to make their version of Wine work around this. Some of the results of that effort are likely to be helpful for Wine. On the other hand, some of the things done are more on the order of brilliant hacks, but not really suitable for Wine in general. You can take a look at the thread here for a lot more details of what was involved: https://www.winehq.org/pipermail/wine-devel/2019-December/156583.html
As far as a roadmap goes for the Linux, I can't really speak to that.
- Regards, - Jeff
On Thu, Jan 16, 2020 at 2:43 AM Klaus-J. Wolf yanestra@gmail.com wrote:
I recently noted that some Linux* distributions stop their x86 32bit flavor because 32bit care occupies lots of time (apparently more and more since AMD64 mechanisms are missing) not outweighed by the number of 32bit platform users remaining.
I also noted that apparently, there is no way to compile/link the Wine32 executable with 64bit libs.
Since I’m a developer by profession, I would like to ask what the main problems are and if I can help.
Any notes welcome.
There are no fundamental limitations to running x86 software on x86-64. The CPU supports it. The kernel supports it. Libraries can be built into 32 bit binaries. Compilers/linkers/assemblers support 32 bit. The problem is political: lazy distros aspiring to be Apple, that don't want to build 32 bit packages. The solution can also be political: use a distro that allows you to use your computer the way that you want.
Damjan
Am 16.01.2020 um 07:20 schrieb Damjan Jovanovic damjan.jov@gmail.com: The problem is political: lazy distros aspiring to be Apple, that don't want to build 32 bit packages.
I'd phrase the political problem differently: Distros outsourcing backward compatibility support to Wine and expecting us to do magic without their support.
See also: Who still runs the Linux ports of games made in the early 2000s, changing sound API like underwear (although PA has been stable lately, maybe that sticks around now), SNI systray.
On 1/16/20 12:16, Stefan Dösinger wrote:
I'd phrase the political problem differently: Distros outsourcing backward compatibility support to Wine and expecting us to do magic without their support.
See also: Who still runs the Linux ports of games made in the early 2000s, changing sound API like underwear (although PA has been stable lately, maybe that sticks around now), SNI systray.
I am afraid the distros who think of dropping 32 bit libraries are also ignoring the commercial use of Linux with highly specialized or proprietary software, or pretty much any software outside of distributions itself. There is software like that, while the volume it is not comparable to Windows of course. Porting the software which just works to newer technologies just for the sake of renewal without getting any improvement for business looks like a pure waste. Dropping 32 bit support now or soon will also make the decisions to make new commercial software for Linux highly questionable. As it is no warranty that they won't drop something else in the next 10-15 years which will throw the expenses and time for such development away.
On Thu, Jan 16, 2020 at 08:20:55AM +0200, Damjan Jovanovic wrote:
There are no fundamental limitations to running x86 software on x86-64. The CPU supports it. The kernel supports it. Libraries can be built into 32 bit binaries. Compilers/linkers/assemblers support 32 bit. The problem is political: lazy distros aspiring to be Apple, that don't want to build 32 bit packages. The solution can also be political: use a distro that allows you to use your computer the way that you want.
Distro maintainers are not "lazy" because they made a decision to allocate their limited resources differently from how you would have. Please be respectful.
Andrew
On Thu, Jan 16, 2020 at 7:21 AM Damjan Jovanovic damjan.jov@gmail.com wrote:
There are no fundamental limitations to running x86 software on x86-64. The CPU supports it. The kernel supports it. Libraries can be built into 32 bit binaries. Compilers/linkers/assemblers support 32 bit. The problem is political: lazy distros aspiring to be Apple, that don't want to build 32 bit packages. The solution can also be political: use a distro that allows you to use your computer the way that you want.
Hmm, when I asked I rather thought of technical problems and their solution. I mean, 32bit calls can be translated into 64bit ones, if C doesn't, assembler will do, so why not do it?
On 1/17/20 2:35 AM, Klaus-J. Wolf wrote:
On Thu, Jan 16, 2020 at 7:21 AM Damjan Jovanovic <damjan.jov@gmail.com mailto:damjan.jov@gmail.com> wrote:
There are no fundamental limitations to running x86 software on x86-64. The CPU supports it. The kernel supports it. Libraries can be built into 32 bit binaries. Compilers/linkers/assemblers support 32 bit. The problem is political: lazy distros aspiring to be Apple, that don't want to build 32 bit packages. The solution can also be political: use a distro that allows you to use your computer the way that you want.Hmm, when I asked I rather thought of technical problems and their solution. I mean, 32bit calls can be translated into 64bit ones, if C doesn't, assembler will do, so why not do it?
Taking this approach means compiling (probably JIT) or interpreting the entirety of the game's code, neither of which are performant or indeed easy (consider self-modifying code).
If we have no 32-bit libraries (or, in the case of Mac OS, ability to even load 32-bit libraries if they are present), the best solution seems to be to run most code in 32-bit mode (after all, the CPU does still support it) and thunk down to 64-bit when necessary, specifically when entering a host library or something similar.
But this is still a lot of work, and raises a lot of its own nasty problems. It's far better just to have 32-bit libraries available to us.
On 17.01.2020 17:18, Zebediah Figura wrote:
If we have no 32-bit libraries (or, in the case of Mac OS, ability to even load 32-bit libraries if they are present), the best solution seems to be to run most code in 32-bit mode (after all, the CPU does still support it) and thunk down to 64-bit when necessary, specifically when entering a host library or something similar.
But this is still a lot of work, and raises a lot of its own nasty problems. It's far better just to have 32-bit libraries available to us.
I did not understand that the thing would be that Linux distro's would not be able to even load 32-bit libraries? Was it not more that they would not provide 32-bit libraries as a thing, and that it would still be supported due to the kernel still being able to run 32-bit code?
I can't see the "end of all" by this tbh, but that it will be certain distro's that none will bother maintaining 32-bit libraries for, sure.. And it will end up being up to enthusiasts to provide custom libraries just for wine if needed i guess.
Is there non-critical or performant processes that could be "converted" so that ALL the 32-libraries would not be needed?
Sveinar
-
Andrew Eikum -
Damjan Jovanovic -
Jeff Smith -
Klaus-J. Wolf -
Paul Gofman -
Stefan Dösinger -
Sveinar Søpler -
Zebediah Figura