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,
I'm I correct in thinking it would no longer be necessary to install the multilib files?
Thanks.

Reading further down in the release notes one finds,
Not sure what that means.

It will show up in next week's update on SBo:

https://git.slackbuilds.org/slackbui...8e9ffbd016e531

I don't know how to answer the 64/32-bit question.

1 members found this post helpful.

I used Alien Bob's latest SlackBuild and just modified the Gecko and Mono versions to match the requirements of 8.0 and it built just fine.

2 members found this post helpful.

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.

3 members found this post helpful.

If you don't want multi-lib, but want to run 32 bit Windows stuff, you could try Conty:

https://github.com/Kron4ek/Conty

I use it to play StarCraft, Warcraft 3, etc. I don't have multi-lib.

7 members found this post helpful.

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.

1 members found this post helpful.

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.

WINE-8.0 for Slackware is available from Simone Giustetti at,
https://sourceforge.net/projects/win...re%20Packages/

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

4 members found this post helpful.

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.

4 members found this post helpful.

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

5 members found this post helpful.

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.