Normally I am a strong proponent of adjusting implementations one small step at
a time, but this is a bit of an extreme case.
The current state of UrlCanonicalize() is a prototypical example of "spaghetti
code": the implementation has been repeatedly adjusted to fix a new discovered
edge case, without properly testing the scope of the new logic, with the effect
that the current logic is a scattered mess of conditions that interact in
unpredictable ways.
To be fair, the actual function is much more complicated than one would
anticipate, and the number of new weird edge cases I found while trying to flesh
out existing logic was rather exhausting.
I initially tried to "fix" the existing implementation one step at a time. After
racking up dozens of commits without an end in sight, though, and having to
waste time carefully unravelling the broken code in the right order so as to
avoid temporary failures, I decided instead to just fix everything at once,
effectively rewriting the function from scratch, and this proved to be much more
productive.
Hopefully the huge swath of new tests is enough to prove that this new
implementation really is correct, and has no more spaghetti than what Microsoft
made necessary.
--
v3: shlwapi/tests: Add many more tests for UrlCanonicalize().
kernelbase: Use scheme_is_opaque() in UrlIs().
kernelbase: Reimplement UrlCanonicalize().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4954
Found while refactoring FFP code; no known application is affected.
--
v2: wined3d/glsl: Pass through the specular varying when SPECULARENABLE is FALSE.
wined3d/glsl: Always set WINED3D_SHADER_CONST_FFP_LIGHTS in FFP constant update masks.
d3d8/tests: Add more tests for SPECULARENABLE.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4956
Fixes "True Reporter. Mystery of Mistwood" broken startup from launcher when the launcher wants to minimize all windows (which is probably not strictly necessary) but we instead pop Start menu.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5025
This series' main purpose is to fix the handles' attributes
of standard I/O handles in CreateProcess.
Needed behavior in CreateProcess is implemented by supporting
the DUPLICATE_SAME_ATTRIBUTES option in NtDuplicateObject() and
DuplicateHandle().
This option is not documented in SDK, but is in DDK.
Manifest constant has been added to DDK header (maybe now
Wine's DUPLICATE_MAKE_GLOBAL could be moved here to).
--
v2: server: Preserve handle flags when inheriting a std handle.
server: Implement support for DUPLICATE_SAME_ATTRIBUTES in DuplicateHandle().
kernel32/tests: Test DUPLICATE_SAME_ATTRIBUTES flag in DuplicateHandle().
kernel32: Added tests about std handle flags inheritance.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4613
copy implementation of CopyFileExW into CopyFile2,
then implement CopyFileExW in terms of CopyFile2
should fix https://bugs.winehq.org/show_bug.cgi?id=55897, as Python does not use any new functionality nor the callback parameter from CopyFile2.
- followed [the Wiki](https://wiki.winehq.org/Developer_Hints#Implementing_new_API_calls) for adding a new API call
- run `file.c` tests and they seem to pass
I have not written extensive documentation since the original function didn't seem to have any; I can do that if recommended.
I originally intended to implement the callback functionality in this MR as well, but realized that would be better as a follow-up.
--
v6: create CopyFile2_impl and CopyFile2
https://gitlab.winehq.org/wine/wine/-/merge_requests/5020
copy implementation of CopyFileExW into CopyFile2,
then implement CopyFileExW in terms of CopyFile2
should fix https://bugs.winehq.org/show_bug.cgi?id=55897, as Python does not use any new functionality nor the callback parameter from CopyFile2.
- followed [the Wiki](https://wiki.winehq.org/Developer_Hints#Implementing_new_API_calls) for adding a new API call
- run `file.c` tests and they seem to pass
I have not written extensive documentation since the original function didn't seem to have any; I can do that if recommended.
I originally intended to implement the callback functionality in this MR as well, but realized that would be better as a follow-up.
--
v5: create CopyFile2_impl and CopyFile2
https://gitlab.winehq.org/wine/wine/-/merge_requests/5020
copy implementation of CopyFileExW into CopyFile2,
then implement CopyFileExW in terms of CopyFile2
should fix https://bugs.winehq.org/show_bug.cgi?id=55897, as Python does not use any new functionality nor the callback parameter from CopyFile2.
- followed [the Wiki](https://wiki.winehq.org/Developer_Hints#Implementing_new_API_calls) for adding a new API call
- run `file.c` tests and they seem to pass
I have not written extensive documentation since the original function didn't seem to have any; I can do that if recommended.
I originally intended to implement the callback functionality in this MR as well, but realized that would be better as a follow-up.
--
v4: CopyFile2_impl: remove unused variable
https://gitlab.winehq.org/wine/wine/-/merge_requests/5020
copy implementation of CopyFileExW into CopyFile2,
then implement CopyFileExW in terms of CopyFile2
should fix https://bugs.winehq.org/show_bug.cgi?id=55897, as Python does not use any new functionality nor the callback parameter from CopyFile2.
- followed [the Wiki](https://wiki.winehq.org/Developer_Hints#Implementing_new_API_calls) for adding a new API call
- run `file.c` tests and they seem to pass
I have not written extensive documentation since the original function didn't seem to have any; I can do that if recommended.
I originally intended to implement the callback functionality in this MR as well, but realized that would be better as a follow-up.
--
v3: create CopyFile2_impl that uses SetLastError error handling
https://gitlab.winehq.org/wine/wine/-/merge_requests/5020
This reworks `set_native_thread_name()` for macOS to not rely on mach thread ports returned server side (which were potentially colliding cross-process anyways) and re-implements what `pthread_setname_np()` would do on wines side, with additionally allowing setting threadnames cross-process.
On the kernel side `bsd_setthreadname()` is apparently "known to race with regards to the contents of the thread name", so that is only exposed for the thread calling it on itself.
Since the pthread struct is private, the location of the thread name is determined at runtime (although in practice, it is constant (80 bytes) from at least 10.15 up to 14.0).
This has an effect on both `pthread_getname_np()` and the `NSThread` implementation on top a native library would use.
Cross-thread naming is only not visible to external debuggers, which have acquired a mach port right and calling `thread_info()` with `THREAD_EXTENDED_INFO`
--
v2: ntdll: Reimplement set_native_thread_name() for macOS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4854
--
v8: gdiplus: Implement font linking for gdiplus.
gdiplus/tests: Add interactive test for font linking.
gdiplus: Replace HDC with GpGraphics in parameters.
mlang: Fix bug with codepage priority in GetStrCodePages.
mlang/tests: Test codepages priority bug in GetStrCodepages.
mlang: Implement GetGlobalFontLinkObject.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4082
Fixes a crash in Microsoft Flight Simulator (which passes some currently invalid values to ucrtbase._gmtime64() and doesn't expect NULL result).
It looks like any msvcrt version on modern Windows accepts wider range of values. Meanwhile, the exact range is different for ucrtbase vs older CRT versions (the exact values for ucrtbase also vary before Win10 1909). Also, older msvcrt.dll matches what we have in Wine now. So the patch keeps old msvcrt behavior, adds universally correct limits for msvcrt 70-120 and the latest (Win10 1909+) for ucrtbase.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5024
This series' main purpose is to fix the handles' attributes
of standard I/O handles in CreateProcess.
Needed behavior in CreateProcess is implemented by supporting
the DUPLICATE_SAME_ATTRIBUTES option in NtDuplicateObject() and
DuplicateHandle().
This option is not documented in SDK, but is in DDK.
Manifest constant has been added to DDK header (maybe now
Wine's DUPLICATE_MAKE_GLOBAL could be moved here to).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4613
copy implementation of CopyFileExW into CopyFile2,
then implement CopyFileExW in terms of CopyFile2
should fix https://bugs.winehq.org/show_bug.cgi?id=55897, as Python does not use any new functionality nor the callback parameter from CopyFile2.
- followed [the Wiki](https://wiki.winehq.org/Developer_Hints#Implementing_new_API_calls) for adding a new API call
- run `file.c` tests and they seem to pass
I have not written extensive documentation since the original function didn't seem to have any; I can do that if recommended.
I originally intended to implement the callback functionality in this MR as well, but realized that would be better as a follow-up.
--
v2: - replace BOOL with HRESULT
https://gitlab.winehq.org/wine/wine/-/merge_requests/5020
--
v3: mshtml/tests: Test builtin function default value getter with custom
mshtml: Expose the IHTMLEventObj5 props to scripts.
mshtml: Implement `initMessageEvent` for MessageEvents.
mshtml: Implement `origin` prop for MessageEvents.
mshtml: Implement `data` getter for MessageEvent objs.
mshtml: Return E_ABORT from postMessage called without a caller
mshtml: Implement `source` prop for MessageEvents.
mshtml: Use a hook to implement postMessage.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4986
When two sends are performed in parallel on a socket the send which came second to server's (socked_send) will always considered blocking if the first send hasn't performed set_async_direct_result() in client's ntdll yet. Similarly, if select() is coming shortly after send() it may report socket as not write ready. We don't care for avoiding a race here because if those two sends or send / select are not synced by app it is unlikely possible for an app to depend on which gets processed first, and the one which was called earlier in wall time now also is not guaranteed to be actually processed first.
The patches fix Tekken 8 which gets frequently disconnected from multiplayer matches. The game treats WSAEWOULDBLOCK from send() on its non-blocking UDP socket, as well as the same socket not reported as write ready from select as a disconnection condition. Those conditions normally (outside of actual network problem / contention) only happen due to the races described above (while the game performs send() concurrently from different threads or is racing send with select).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4967
--
v2: mshtml/tests: Test builtin function default value getter with custom
mshtml: Expose the IHTMLEventObj5 props to scripts.
mshtml: Implement `initMessageEvent` for MessageEvents.
mshtml: Implement `origin` prop for MessageEvents.
mshtml: Implement `data` getter for MessageEvent objs.
mshtml: Implement `source` prop for MessageEvents.
mshtml: Use a hook to implement postMessage.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4986
This goes atop !598 and !603.
--
v7: vkd3d-shader/ir: Introduce a simple control flow graph structurizer.
vkd3d-shader/ir: Handle PHI nodes when materializing SSA registers.
vkd3d-shader/ir: Materialize SSA registers to temporaries.
vkd3d-shader/spirv: Support bool TEMP registers.
vkd3d-shader/spirv: Move bool casting helpers above register loading helpers.
vkd3d-shader/dxil: Set the register before calling src_param_init_scalar().
vkd3d-shader/spirv: Convert the swizzle according to the source bit width.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/607
I originally added this for Minecraft Education Edition to see if it would help with a sign-in issue, but it didn't seem to so I didn't create an MR for it. But this library is also used by Office and other apps. For Office, there are 2 reports[[1](https://forum.winehq.org/viewtopic.php?p=138513)][[2](https://f… that say this is the cause of an installation crash. I can't confirm it as I don't have an Office subscription.
I have some more patches for this that Minecraft Education Edition calls but I don't know if they're helpful for Office.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5021
An alternative approach to `EnumAdapters2` that does not directly call to GDI driver and therefore does not require GDI driver functions to be expanded. The implementation now lives in `sysparams.c` to make it closer to win32u caches it accesses. It still uses `OpenAdapterFromLuid` internally because that's where adapter handles are actually assigned and to make sure returned handles are usable with other functions that rely on GDI driver being aware of what the handle represents to be able to function correctly (like `QueryVideoMemoryInfo`).
See !4791 for some background and why this version might be preferable over the one submitted there.
--
v7: win32u: Implement NtGdiDdDDIEnumAdapters2.
win32u: Maintain a list of GPUs in cache.
gdi32: Add D3DKMTEnumAdapters2() stub.
gdi32/tests: Add D3DKMTEnumAdapters2 tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857
An alternative approach to `EnumAdapters2` that does not directly call to GDI driver and therefore does not require GDI driver functions to be expanded. The implementation now lives in `sysparams.c` to make it closer to win32u caches it accesses. It still uses `OpenAdapterFromLuid` internally because that's where adapter handles are actually assigned and to make sure returned handles are usable with other functions that rely on GDI driver being aware of what the handle represents to be able to function correctly (like `QueryVideoMemoryInfo`).
See !4791 for some background and why this version might be preferable over the one submitted there.
--
v6: win32u: Implement NtGdiDdDDIEnumAdapters2.
win32u: Maintain a list of GPUs in cache.
gdi32: Add D3DKMTEnumAdapters2() stub.
gdi32/tests: Add D3DKMTEnumAdapters2 tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857
copy implementation of CopyFileExW into CopyFile2,
then implement CopyFileExW in terms of CopyFile2
should fix https://bugs.winehq.org/show_bug.cgi?id=55897, as Python does not use any new functionality nor the callback parameter from CopyFile2.
- followed [the Wiki](https://wiki.winehq.org/Developer_Hints#Implementing_new_API_calls) for adding a new API call
- run `file.c` tests and they seem to pass
I have not written extensive documentation since the original function didn't seem to have any; I can do that if recommended.
I originally intended to implement the callback functionality in this MR as well, but realized that would be better as a follow-up.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5020
Should fix the failures on win22H2_newtb-w1064-tsign-64 that started on Jan 23. It's not clear to me *why* this message started appearing on that machine, but it seems to be very consistent.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5018
Normally I am a strong proponent of adjusting implementations one small step at
a time, but this is a bit of an extreme case.
The current state of UrlCanonicalize() is a prototypical example of "spaghetti
code": the implementation has been repeatedly adjusted to fix a new discovered
edge case, without properly testing the scope of the new logic, with the effect
that the current logic is a scattered mess of conditions that interact in
unpredictable ways.
To be fair, the actual function is much more complicated than one would
anticipate, and the number of new weird edge cases I found while trying to flesh
out existing logic was rather exhausting.
I initially tried to "fix" the existing implementation one step at a time. After
racking up dozens of commits without an end in sight, though, and having to
waste time carefully unravelling the broken code in the right order so as to
avoid temporary failures, I decided instead to just fix everything at once,
effectively rewriting the function from scratch, and this proved to be much more
productive.
Hopefully the huge swath of new tests is enough to prove that this new
implementation really is correct, and has no more spaghetti than what Microsoft
made necessary.
--
v2: shlwapi/tests: Add many more tests for UrlCanonicalize().
kernelbase: Use scheme_is_opaque() in UrlIs().
kernelbase: Reimplement UrlCanonicalize().
kernelbase: Do not canonicalize the relative part in UrlCombine().
shlwapi/tests: Move UrlCombine() error tests out of the loop.
shlwapi/tests: Use winetest_push_context() in test_UrlCanonicalizeA().
shlwapi/tests: Remove the unused "wszExpectUrl" variable from check_url_canonicalize().
shlwapi/tests: Move the UrlCanonicalize() tests into test_UrlCanonicalizeA().
urlmon/tests: Add basic tests for CoInternetParseUrl(PARSE_CANONICALIZE).
https://gitlab.winehq.org/wine/wine/-/merge_requests/4954
As per discussion in 606, plumbing constant buffer reflection through
vkd3d-shader requires interface design and API documentation for an interface
which is inherently quite specific to one format. Instead of wasting time on
this interface, just implement RDEF parsing in vkd3d-utils itself. If we change
our mind about this, we can always move the implementation to vkd3d-shader
anyway.
This does not copy the existing implementation from Wine, because:
* Wine does not validate offsets; adding this changes the parsing code
significantly;
* Wine incorrectly handles types, deduplicating them into an rbtree;
* Wine skips several fields which I have been able to find the purpose of.
The implementation is not that complex to begin with, so reimplementing it from
scratch is not much work.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/626
https://bugs.winehq.org/show_bug.cgi?id=51998
The first patch should make no functional change, just move the block out to a helper function. I assume changing to L"" literals is expected?
The second patch handles ImagePaths starting with `System32` similar like it is already done for `\\SystemRoot\\` and adds the windows directory in front of it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5009
--
v6: gdiplus: Implement font linking for gdiplus.
gdiplus/tests: Add interactive test for font linking.
gdiplus: Replace HDC with GpGraphics in parameters.
mlang: Fix bug with codepage priority in GetStrCodePages.
mlang/tests: Test codepages priority bug in GetStrCodepages.
mlang: Implement GetGlobalFontLinkObject.
mlang/tests: Test for GetGlobalFontLinkObject.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4082
Mostly split from https://gitlab.winehq.org/wine/wine/-/merge_requests/4946.
--
v2: dinput/tests: Test rawinput with the virtual HID touchscreen.
dinput/tests: Use a polled HID touchscreen device.
dinput/tests: Test rawinput messages with non-input desktop.
dinput/tests: Add more tests for HID rawinput buffer.
dinput/tests: Add a helper to wait on HID input reads.
user32/tests: Rewrite the rawinput buffer test with keyboard input.
user32/tests: Run rawinput device tests in the separate desktop.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5005
As _WINE_HWND_STYLE and _WINE_HWND_EXSTYLE respectively.
Gamescope parses these to make smarter decisions about what window
to primary focus, or to treat as a dropdown/overlay.
This was originally a Proton commit by Remi Bernon, however,
it would definitely be nice to have support for Gamescope focusing
correctly under upstream Wine as well.
Fixes a bunch of games/launchers run with Wine under Gamescope.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2902
--
v4: vkd3d-shader/spirv: Emit line numbers if debugging info is not stripped.
vkd3d-compiler: Add a command line option for instruction numbering.
vkd3d-shader/d3d-asm: Enable instruction numbering for trace output.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/612
The PE build uses FlsAlloc(), which for our purposes makes no difference vs TlsAlloc(), and allows the use of a destruction callback.
--
v8: vkd3d: Replace the descriptor object cache with a thread-local implementation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/384
An alternative approach to `EnumAdapters2` that does not directly call to GDI driver and therefore does not require GDI driver functions to be expanded. The implementation now lives in `sysparams.c` to make it closer to win32u caches it accesses. It still uses `OpenAdapterFromLuid` internally because that's where adapter handles are actually assigned and to make sure returned handles are usable with other functions that rely on GDI driver being aware of what the handle represents to be able to function correctly (like `QueryVideoMemoryInfo`).
See !4791 for some background and why this version might be preferable over the one submitted there.
--
v5: win32u: Implement NtGdiDdDDIEnumAdapters2.
win32u: Maintain a list of GPUs in cache.
gdi32,win32u: Add stubs for D3DKMTEnumAdapters2 and NtGdiDdDDIEnumAdapters2.
gdi32/tests: Add D3DKMTEnumAdapters2 tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857