SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,119
Rep:
WINE on Slackware64
Has anyone installed the most recent WINE-8.0?
The release notes can be found here, https://www.winehq.org/announce/8.0
This, below, is what I find the most interesting,
Quote:
This is an important milestone on the road to supporting various features such as...... 32-bit applications on 64-bit hosts.....
I'm I correct in thinking it would no longer be necessary to install the multilib files?
Thanks.
Last edited by cwizardone; 01-25-2023 at 11:31 AM.
Reason: Typo.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,119
Original Poster
Rep:
Reading further down in the release notes one finds,
Quote:
- Building mixed Windows/Unix libraries in ELF format (.dll.so libraries) is still supported for use in Winelib applications. However, such applications won't support features enabled by the NT syscall interface, such as WoW64 without 32-bit libraries.
Not sure what that means.
Last edited by cwizardone; 01-25-2023 at 11:38 AM.
cwizardone, my initial interpretation is would be that windows code compiled against winelib will not be able to thunk, but would still need 32-bit native libraries; however an actual Windows binary run by wine perhaps can thunk?
I hope that is what it means because wine is about the last thing that keeps me using multilib on my main box. Not that Alien does not make it pretty painless but would be nice to be able to just run stock Slackware libs.
rkelsen, that is a neat project I had not seen. For a while I ran Wine in a 32-bit LXC container, which worked great for me until windows stuff started wanting 64 bit. The container let me bind mount and make it so my home directory was shared and stuff. This looks like a nice approach. I might give it look sometime.
It's basically wine-*-noarch now, but probably best to call it *-multiarch, since noarch would mean it supports all platforms.
And since the change only affects wine64, and not wine32 (on 32bit host) which did not previously require multilib:
Not impressed too much by this. It would be much more impressive if wine32 could run 64bit code on pure 32bit hosts without any 64bit libs.
Clearly you don't understand the amount of work involved, or appreciate the significance of this achievement. This is a huge step for Wine.
The Wine project has been running for decades, and they just keep on keeping on. Milestone achievements are few and far between, but they continue plugging away. This is one such milestone... Credit where it is due, eh?
Quote:
Originally Posted by elcore
It would be much more impressive if wine32 could run 64bit code on pure 32bit hosts without any 64bit libs.
What you ask is not possible.
And neither is it necessary, given that pure 32 bit hardware has long since gone the way of the dodo.
elcore - for a bit explanation about why what you're asking for is hard.
You can generally create thunks for software expecting a smaller address space to call into a larger one. IE 32-bit calling into 64-bit modules. Provided you can control somethings when create the process and map memory, namely ensuring everything 32-bit land needs to call in 64-bit land falls inside a 32-bit address space - but more than that other 64-bit land stuff that might be passed around by address that needs to transition thru 32-bit is either inside the 32-bit space or mapped in some why.
With some hacking around memory locations of things you can do this because and of the 64-bit code that has to store values like memory-address (think pointers) that come out the 32-bit will fit into whatever logical structures the 64-bit code lays out. Similarly that will be true at the hardware level, we can put 32-bit integer into 64-bit wide register just fine. None of this is true going the other way round though.
64-bit values won't fit into code that has 32-bit structures. Some library wants callback function or something and expects a 32-bit memory pointer, we are going have problems when our 64-bit code try to put long long in there. Additionally at the hardware layer, 64-bit x86-64 is (more or less) a super-set of 32-bit. So no problems there but again going the other direction does not work, you'll have instructions trying to do stuff with registers that don't exist, and instructions that don't exist.
The only approach is a virtual machine, there is stuff qemu + wine hacks out there for ARM I thought I saw somewhere in my travels, for ruining Windows stuff on ARM but you are back to full 64/32 bit software land to support that; even if you don't visualize all the hardware.
I see, now "it'd be impressive if it could do that" means I'm asking for something. Was there a question mark?
I'm not requesting shit, don't care either way. And still not impressed by wine/multilib or whatever it's called these days.
This is news to me. Just as impressive as android-x86, which is a prime example of reversing something that was originally unsupported.
Don't get me wrong, I don't disrespect wine, I just don't see any progress for my use-case here because I don't have/use any 64bit windows stuff.
My mother taught me : If you have nothing positive to contribute, then say nothing...
And yet, you contribute this completely unrelated comment.. Point taken.
Why do you think this little celebration party here gets on my nerves?
I'll just say this: While these guys celebrate less depends for wine64, all I see here is wine32 may require a 64bit host soon.
So excuse me for not celebrating regressions, which I might have to work around in the future.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.