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

[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]

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]

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.