Wine 5.18 Released With VKD3D 1.2's vkd3d-shader Usage

[oiaohm]

Dude list me one app that supplies its own user32 and that is not malware. user32 is tightly integrated into Windows, like kernel32 and ntdll—you can't just replace it and have it work across (even minor) versions or updates.

O yes you can when you look how anti-cheat systems have done it. They are using updating syscall tables that sets syscall table based on OS detection.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Syscall-Isolate-Memory

The syscall support valve with other developers around wine is working on is the new anti-cheat stuff is going straight past user32.dll, kernel32.dll and ntdll.dll straight to syscalls with all the hell.

Again, this is also illegal, because they are not redistributables. Do you understand this?

Illegal depends if you have have rights from Microsoft or not. Its not a general re-distributable true but that does not mean different parties like games companies owned by Microsoft don't have the rights to distribute their own versions.

.

..you can't link to glibc from a PE file directly, because glibc is ELF... that's why you need msvcrt.

This is you being wrong Weasel Wine historically for testing had been built by cygwin in PE format. http://gnuwin32.sourceforge.net/packages/glibc.htm Funny right glibc can in fact be built for Windows. Yes sections of wine code with out the flag use -mno-cygwin when building PE will serous-ally attempt to link to glibc and expect it to be there.

So the idea that you cannot link to glibc or equal from PE is wrong. To built wine you don't want to have to build the PE version of glibc so you really want it to support msvcrt. Please note cygwin has newlib https://sourceware.org/newlib/ as well. -mno-cygwin is don't use newlib or glibc when building but use msvcrt.

Something interesting weasel wine is building it mingw compliers. Guess what -mno-cygwin is a given from that compiler because newlib/glibc don't exist in a mingw build so that flag is not for the compiler but to have the wine source change its behaviour.

[Weasel]

Dude list me one app that supplies its own user32 and that is not malware. user32 is tightly integrated into Windows, like kernel32 and ntdll—you can't just replace it and have it work across (even minor) versions or updates. Again, this is also illegal, because they are not redistributables. Do you understand this?

Small flag change does not mean small change. That -mno-cygwin flag when building ELF/PE hybrid due to no mingw complier and before PE building support was added also prevents direct linking to glibc to solve things. One flag changes completely how the libc is hooked up and that has a lot of other effects, Adding -mno-cygwin does not set build as PE alone.

-mno-cygwin have existed on things before the build as PE with wine started. Its called build with msvcrt because it changes to using the msvcrt .dll inside wine instead of direct glibc of host. Yes using host glibc of course you cannot built a PE with mingw right. Using msvcrt from the elf/pe hybrid user32.dll.so instead of glibc host has a lot of effects as well.

...you can't link to glibc from a PE file directly, because glibc is ELF... that's why you need msvcrt.

[oiaohm]

I don't know of a single non-malware app that supplies its own user32, because it's not a redistributable, so it's illegal to begin with. Not to mention too low level and can break between Windows versions. Please just stop.

own kind of version user32.dll missing a few features << Note this is not the Microsoft one.

Yes some of the reason particular anti-cheats break badly between windows version is the stunts they are up-to here.

Also, you realize Wine's own drivers interact with user32 in its own way, right? In fact Wine's user32 has extra exports just for drivers (like the X11 driver) to interact with. There's no way in hell a native user32 would ever work on Wine.

There is a total of 2 extra exports in wine user32.
cdecl __wine_send_input(long ptr)

https://source.winehq.org/patches/data/169709

This was added in Wed, 11 Sep 2019

If you don't care for perfectly working raw input this can be skipped.

cdecl __wine_set_pixel_format(long long)

https://www.winehq.org/pipermail/wine-cvs/2012-October/090722.html

You don't need this one if you expect opengl to take what ever buffer type wine user32 spits up or have forced wine user32 back into GDI mode. Microsoft user32 always runs in GDI mode so using gdi32.

This here is a wine performance optimisation to skip over in its user32 from having to interface with gdi32.dll and go directly to opengl instead and that results in having to deal with the case of how to handle what opengl buffer type to use.

The reality you can remove both of those extra functions and wine user32 works with some issues but it does work.

Weasel both of the extra exports user32.dll from wine can in fact function without.

These are not the reason why you cannot just remove and replace wine user32.dll. The reason is kind of more horrible. WIN_CreateWindowEx is what CreateWindowEx is called inside wine guess where you end up under wine when you attempt to syscall NtUserCreateWindowEx that right straight back in wine user32.dll. This is why Reactos developers at time says wine is designed by a drunk person because if you are following windows that syscall should lead you intoWin32k not to user32.dll as wine does.

A native user32.dll replacing wine core user32.dll does not work because its not designed to replace kernel functionality and wine one is. The funny part is with the way the syscalls flow around inside wine it is possible to use Microsoft user32.dll on wine just not named user32.dll.

But anticheat systems you will find replacing all calls to user32.dll to their own made up version directly based on gdi32.dll and nt syscalls. Yes Microsoft says don't use NT syscalls because they can change in future as well. This explains why anti-cheat systems can be so touchy on windows updates at times because they are by passing abstractions in the windows design. gdi32.dll changed to PE will effect anti-cheat.

Anti-cheats implementing their own user32.dll replacements don't name them user32.dll but the result is the applications using the anti-cheat solutions are not using user32.dll from Microsoft and yes the bipass they do is not recommend by Microsoft and causes some wacky code paths in wine where what the anti-cheat developers coded to avoid Microsoft user32.dll end up in fact going though wine user32.dll.

Also "user32: Build with msvcrt" just means it was built as PE, but you wouldn't even know that (it adds the -mno-cygwin option, which is what it does, see wine's tools source.

Small flag change does not mean small change. That -mno-cygwin flag when building ELF/PE hybrid due to no mingw complier and before PE building support was added also prevents direct linking to glibc to solve things. One flag changes completely how the libc is hooked up and that has a lot of other effects, Adding -mno-cygwin does not set build as PE alone.

-mno-cygwin have existed on things before the build as PE with wine started. Its called build with msvcrt because it changes to using the msvcrt .dll inside wine instead of direct glibc of host. Yes using host glibc of course you cannot built a PE with mingw right. Using msvcrt from the elf/pe hybrid user32.dll.so instead of glibc host has a lot of effects as well.

[Weasel]

This case no wrong idea. Current highly intrusive anti-cheat or drm applications in fact avoid using user32 mostly because of unthemed feature still in Windows 10 user32 as well as Applnit_DLLs and a few other user32 features allowing third parties to silently add extra executable code any application using user32.dll. Yes this is also why a lot of DRM and anti-cheat protected programs ship with their own kind of version user32.dll missing a few features, User32 is one of those fun Libraries that wine has to run random modified native versions of from different anti-cheat/DRM solutions.

I don't know of a single non-malware app that supplies its own user32, because it's not a redistributable, so it's illegal to begin with. Not to mention too low level and can break between Windows versions. Please just stop.

Also, you realize Wine's own drivers interact with user32 in its own way, right? In fact Wine's user32 has extra exports just for drivers (like the X11 driver) to interact with. There's no way in hell a native user32 would ever work on Wine.

Also "user32: Build with msvcrt" just means it was built as PE, but you wouldn't even know that (it adds the -mno-cygwin option, which is what it does, see wine's tools source).

So you're clueless like always.

[oiaohm]

Simplicity in interfacing with unix libraries.Apps with intrusive shit like anti-cheat or DRM that check if the on-disk file has same memory layout as the one mapped in memory, to name one example.That's not the case here. user32 relies on a unix library, but it's not part of user32.dll itself, it's a "dependency", so it satisfies those apps, who only check user32.dll itself.

This case no wrong idea. Current highly intrusive anti-cheat or drm applications in fact avoid using user32 mostly because of unthemed feature still in Windows 10 user32 as well as Applnit_DLLs and a few other user32 features allowing third parties to silently add extra executable code any application using user32.dll. Yes this is also why a lot of DRM and anti-cheat protected programs ship with their own kind of version user32.dll missing a few features, User32 is one of those fun Libraries that wine has to run random modified native versions of from different anti-cheat/DRM solutions.

The man reason for user32.dll as PE with wine is hangover requirements not anti-cheat or DRM stuff because its a rare anti-cheat that does not avoid user32.dll or replace user32.dll with own. Application functionally difference between having user32.dll.so (the hybrid) vs user32.dll the PE on a x86 system is basically nothing due to anti-cheat due to developer avoiding user32.dll to make inserting cheats and hacks into program harder, This is also why there are no bug fixes with 5.18 fixing any anti-cheat linked user32.dll coming PE fixed because does nothing in that department.

Weasel there are other libraries where wine changing them to PE will make anti-cheat/DRM difference user32.dll is just not one of them. I know it simple to miss that particular libraries those making anti-cheat and DRM solutions avoid or replace with own due to Microsoft design choices with those libraries that produces a list of libraries where ELF/PE hybrid or PE formated file makes no difference for items using anti-cheat and DRM.

For effects on applications people use with user32 the bigger change in 5.18 is "user32: Build with msvcrt" that sorts out some of the applications that hook in their own memory tracking and other things.

[Weasel]

I understand nothing in this whole PE conversion but:

$ file user32*
user32.dll.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=, not stripped
user32.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=, not stripped

$ file * | grep -v LSB
fakedlls: directory

$ wine --version
wine-5.18

Sounds like you don't have mingw installed, or Wine's configure didn't pick it up.

[Weasel]

What was the reason, that the WINE developers thought for a long time, that it is better, to compile the WINE libraries and programs to Linux native ELF format?

Simplicity in interfacing with unix libraries.

And what is the reason, that the WINE developers in the last times, thinking, that it is better to compile it to Windows native PE format?

Apps with intrusive shit like anti-cheat or DRM that check if the on-disk file has same memory layout as the one mapped in memory, to name one example.

Now some WINE programs and libaries can in binary form direct tested on Windows.

That's not the case here. user32 relies on a unix library, but it's not part of user32.dll itself, it's a "dependency", so it satisfies those apps, who only check user32.dll itself.

[birdie]

I understand nothing in this whole PE conversion but:

$ file user32*
user32.dll.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=, not stripped
user32.so:     ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=, not stripped

$ file * | grep -v LSB
fakedlls:                                                directory

$ wine --version
wine-5.18

[oiaohm]

What was the reason, that the WINE developers thought for a long time, that it is better, to compile the WINE libraries and programs to Linux native ELF format?

https://wiki.winehq.org/Wine_Developer%27s_Guide/Architecture_Overview

The DLL descriptor, when the DLL is instantiated, is used to create an in-memory PE header, which will provide access to various information about the DLL, including but not limited to its entry point, its resources, its sections, its debug information...

Except winebuild produced ELF files are not pure ELF files they have in memory generated PE headers and other things. I refer to this beast as a ELF/PE as it a hybrid of ELF and PE stuff.

And what is the reason, that the WINE developers in the last times, thinking, that it is better to compile it to Windows native PE format?

It useful for work in the direction of hangover https://github.com/AndreRH/hangover
1) PE libraries cannot be link out to host native libraries directly. That helps with the hangover process to rule out the PE libraries from needing major work.
2) Simpler cross complier using a PE complier compared to a than multi host compilers.

Now some WINE programs and libaries can in binary form direct tested on Windows.

This was already the case with like "wined3d on windows" and other examples.

But still exists the possibility to compile all in ELF format?

That is not what you think it is. Yes ELF/PE hybrid build still remains at this stage.

For example if anybody wants only the WINElib, to "port" its program from Windows to Linux.

WINELib port still need the wine PE loader to process the PE parts in the produced ELF files and for windows style memory structures. Winelib port is like having your feet on both sides of windows and host at the same time. Yes there can be advantages but there are a high number of disadvantages as well and a stack of creative ways to make 100 percent unique bugs.

Winelib has it usage for making binding from windows applications to host but for porting programs turns in most cases not to be that much of advantage. Yes there are many reason why winelib ports are so rare.

Also wine is horrible for those porting for example support graphics cards for directx are hard coded in wine so using old version of wine with new graphics cards equals trouble. So using winelib to port you application are you going to be releasing regular updates or will it be just better to be wine compatible.

[Kepsz]

".NET 4.0 and higher fail to install via winetricks" - finally, they fixed this extremely important thing after many weeks.