This change only implements case-sensitivity of technique keywords and related checks when corresponding profile is used. My immediate plan is to add some synthetic type for technique variables, for example as {object, void}, then add named techniques as variables. This is useful because these names are participating in global scope, and should not collide with normal variables. After that "pass_list" will be split, at least in two variants because of how much d3d9 syntax differs. Some trivial changes will be need later to have some top level fx compilation helper that considers only fx objects and calls ps/vs/gs compiler to create inner shader blobs on same original source.
--
v3: vkd3d-shader/hlsl: Improve handling of "technique" tokens.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/111
This is ultimately a follow up for introducing d3d manager support in h264 decoder transform. The last patch avoids unneeded GPU to CPU copy when copying a memory sample to GPU sample (in particular, when sample copier is involved). There are a couple of things to fix on the way.
Patch 1 fixes the crash which otherwise happens in the test introduced in patch 2 due to memory corruption. Flipping the image instead of using absolute pitch will break the test in patch 2.
Patch 3 contradicts to what MS docs says [1] for MFCreate2DMediaBuffer, fBottomUp parameter: "If TRUE, the buffer's IMF2DBuffer::ContiguousCopyTo method copies the buffer into a bottom-up format.". That doesn't match the tests in patch 2. So far I see that fBottomUp parameter only affects what is returned from Lock2D as scanline0 and pitch. Thinking of it, the behaviour of ContiguousCopyFrom makes some sense to me as Lock2D (unlike Lock which converts to contiguous buffer) is not supposed to perform any copies and flips and return the underlying representation as is. And once scanline0 and pitch for that 2d buffer indicate it should be copied bottom up additionally flipping when converting from contiguous buffer wouldn't make much sense. Then, ContiguousCopyTo could flip it actually as the docs suggest, but the test seems to clearly show that it doesn't happen (there is a separate test for clarity showing that ContiguousCopyFrom / ContiguousCopyTo yields the same data).
1. https://learn.microsoft.com/en-us/windows/win32/api/mfapi/nf-mfapi-mfcreate…
--
v2: mfplat/sample: Optimize copying to 2d buffer.
mfplat/sample: Refactor sample_CopyToBuffer().
mfplat/buffer: Do not flip in memory_2d_buffer_ContiguousCopy{From|To}().
mfplat/tests: Add more tests for copying 2d buffers.
mfplat/buffer: Use absolute pitch in memory_1d_2d_buffer_[Un]Lock().
https://gitlab.winehq.org/wine/wine/-/merge_requests/2781
Previously long URI/URLs (> 1024 characters) would cause a stack corruption and crash Wine. After this MR, Wine will no longer crash but the URL is not opened either primarily due to `SHELL_Argify` limitations.
--
v3: shell32: Increase timeout for long URLs
https://gitlab.winehq.org/wine/wine/-/merge_requests/2383
Using a dedicated exit jmpbuf and removing the need for assembly
routines.
When Wine handles an exception in unix code, we return to user mode by
jumping to the last syscall frame. This can leave some pthread cancel
cleanups registered, in the pthread internal linked list, and at the
same time later overwrite the stack frame they were registered for.
In the same way, jumping to the exit frame on thread exit or abort, can
also leave some cleanup handlers registered for invalid stack frames.
Depending on the implementation, calling pthread_exit will cause all the
registered pthread cleanup handlers to be called, possibly jumping back
to now overwritten stack frames and causing segmentation faults.
Exiting a pthread normally, by returning from its procedure, or calling
exit(0) for the main thread doesn't run pthread_exit and doesn't call
cleanup handlers, avoiding that situation.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213
### Additional note:
For robustness, we should probably try to execute these cleanup handlers
when unwinding the stack frames, as we would otherwise leave pthread
objects in a potential problematic state (like a mutex locked, etc).
It is however hard to do so when the handlers are registered from some C
code: pthread C implementation is done by calling some internal pthread
functions to register the handlers, and they aren't registered as
standard unwind handlers.
Only pthread_cancel and pthread_exit can unwind and call / unregister
the C handlers, but interrupting that procedure, for instance calling
setjmp / longjmp from withing our own handler isn't supported.
From C++ code, pthread cleanup handlers are registered through C++ class
constructors / destructors, and it would then be possible to partially
unwind and call them at the same time.
--
v10: ntdll: Remove now unnecessary arch-specific exit frame.
ntdll: Avoid calling pthread_exit from abort_thread.
ntdll: Avoid calling abort_thread from the signal stack.
ntdll: Use is_inside_syscall more consistently.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1088
--
v3: cryptui: Use CertNameToStr(CERT_NAME_STR_NO_QUOTING_FLAG) to disable quoting.
crypt32: Add support for CERT_NAME_STR_NO_QUOTING_FLAG to CertNameToStr().
crypt32/tests: Add some tests for quoted RDN values.
crypt32: Avoid truncating unicode chars.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3729
Rainbow 6 Siege and some other games require this. Type is printed in the FIXME to determine which type the application requires.
--
v2: gdi32: Add stub for D3DKMTQueryAdapterInfo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3777