Wine 6.8 Released With Support For Loading Libraries From Arch-Specific Subdirectories

[phoronix]

Phoronix: Wine 6.8 Released With Support For Loading Libraries From Arch-Specific Subdirectories

Wine 6.8 was just released as the newest bi-weekly development snapshot providing the latest support for running the latest Windows games and applications under Linux, macOS, and BSD systems...

https://www.phoronix.com/scan.php?page=news_item&px=Wine-6.8-Released

[uid313]

What is the advantage of Wine switching over more DLL files to the PE format?

[birdie]

Mind that with this Wine release its libraries have been moved around. If you compile and install from sources like I do make sure you delete the old junk.

I install into /opt/wine, so now I have neatly organized /opt/wine/lib/wine/i386-unix and /opt/wine/lib/wine/i386-windows directories. There's no libwine.so.1.0 in /opt/wine/lib/wine any longer.

What is the advantage of Win switching over more DLL files to the PE format?

You can use Wine libraries directly under Windows as well. In a perfect world Wine should operate with a single native library which is libwine.so.1.0

[ssokolow]

What is the advantage of Win switching over more DLL files to the PE format?

From what I heard, certain kinds of anti-cheat checks will validate that the loaded-in-memory copy of the DLL matches its on-disk representation to disallow cheats that work by patching the DLL's memory image, and being compatible with that doesn't require the DLL to have specific contents (what if Microsoft updates the genuine one?) or be in a specific location (Windows provides a surprising number of hooks for customizing where things are stored for things like letting an IT department customize their mass-deployment setup) but does require it to be compatible with the anti-cheat check's PE loader.

[oiaohm]

What is the advantage of Win switching over more DLL files to the PE format?

There are a few reasons.

https://github.com/AndreRH/hangover

is quite at the top of list. Need for split between platform needing code and platform not needing. So PE dll is containing the code that does not need to platform interface and the .so version of the dll is the code that needs to access the host. You see this with ntdll.so and ntdll.dll with wine now and many others.

Next is different copy protection and anticheat solutions were getting up set finding elf headers at the start of dll.so,

You can use Wine libraries directly under Windows as well. In a perfect world Wine should operate with just native library which is libwine.so.1.0

That not the answer. Remember Reactos and even wine use to build decent percentage of wine dlls for windows going back over 20 years now.

There are quite a few dll.so that have been for wine converted to .dll PE with a .so ELF this of course are not going to work under windows even that they have been marked as coveted to PE under wine. So the conversion to PE is not about allowing more wine dlls to be useable with windows.

birdie you need to take a closer look at the /opt/wine/lib/wine/i386-unix and notice there is a overlap to .dll in the /opt/wine/lib/wine/i386-windows. Every one of those overlaps are libraries in the i386-windows directory that cannot be used with windows because there will be a piece missing.

[theriddick]

I'll be glad the day when I hear about ANY progress towards supporting BattlEye or EasyAntiCheat under Wine. Got friends that want me to play some games but those are blockers, forces me back into Windows10 which is a shame.

[Aryma]

this program brought to you by a devs who force C89 Standard C and refuse to support Wayland and more BS like didn't support vulkan and use legacy OpenGL both for macOS and F all Linux and BSD user until DXVK disturb them to do some do minimal change to code to keep people trust them and maybe donate them

enjoy

[CochainComplex]

this program brought to you by a devs who force C89 Standard C and refuse to support Wayland and more BS like didn't support vulkan and use legacy OpenGL both for macOS and F all Linux and BSD user until DXVK disturb them to do some do minimal change to code to keep people trust them and maybe donate them

enjoy

at least the fork of vkd3d became the defacto std there is hope....just outsmart them

[kpedersen]

this program brought to you by a devs who force C89 Standard C

Usually I find C99 is preferable (mainly for integration with existing libraries) however do keep in mind that Wine is a compatibility layer and as such needs to one day support platforms you might not even have heard of. The way C89 works means that it is simpler to build compilers for and as such it could end up being the only compiler available for a platform. For this reason alone I believe it is justified. Also consider that Microsoft Visual C++ didn't fully support anything other than C89 even in their 2017 release!

Why does C89 bother you personally?

[ix900]

Usually I find C99 is preferable (mainly for integration with existing libraries) however do keep in mind that Wine is a compatibility layer and as such needs to one day support platforms you might not even have heard of. The way C89 works means that it is simpler to build compilers for and as such it could end up being the only compiler available for a platform. For this reason alone I believe it is justified. Also consider that Microsoft Visual C++ didn't fully support anything other than C89 even in their 2017 release!

Why does C89 bother you personally?

Seems he feels like everything newer that he uses has to be supported or the devs suck lol.