Adapted from [check_invalid_gs](https://gitlab.winehq.org/wine/wine/-/blob/d7a7cae2e2d1ad… in signal_i386.c. This prevents crashing when the %gs register is manipulated, such as in 32-bit code on "new-style" WoW64.
"Exertus: Darkness Approaches" is a 32-bit game that triggers this crash (on WoW64), which can be downloaded from the Bugzilla page's attachments. For another example, [test.c](https://bugs.winehq.org/attachment.cgi?id=77444) can reproduce it, courtesy of Fabian Maurer from the Bugzilla comments. This will crash whether it's compiled as 32-bit or 64-bit, while it works fine on Windows.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57444
Also, excuse me if submitting this is against some sort of code-freeze etiquette, it wasn't my intention try to have it merged immediately.
--
v8: ntdll/tests: Re-enable a previously crashing test.
ntdll: Check for invalid gs_base in the 64-bit segv_handler.
ntdll/tests: Add an exception test for accessing a modified %gs on x86_64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7064
Componenets installed by winetricks have "deadbeef.manifest" trailer
in their manifests, so it's not clear that filtering logic works. On
the other hand when manifests for versions 1.2.3.4 and 1.2.3.10 are
installed and application exe needs version 1.2.0.0 and later uses
LoadLibrary() to load a plugin.dll that needs 1.2.3.7, version 1.2.3.4
gets loaded with an .exe (because manifest for version 1.2.3.10 is
ignored) and version 1.2.3.10 gets loaded with a plugin.dll, and
this leads to crashes.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7028
(For after the code freeze.)
I think we want to have this DLL living in Wine for easier development, and probably dynamically load our custom Chromium fork from here. (just like MSHTML and wine-Gecko)
The code for that fork could then be created in its own repo.
--
v7: embeddedbrowserwebview: Create CreateWebViewEnvironmentWithOptionsInternal stub.
embeddedbrowserwebview: Add stub dll.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7032
Not really needed for 16k pages, but since the comment says "one page" the logic should reflect that.
Not 100% sure about that since I don't know why it should use exactly one page, so please double check.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4740
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are not fully supported by this patch, matching the behavior of Windows.
--
v67: ws2_32/tests: Add test for AF_UNIX sockets.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786