Some applications use FindWindowA() with class Shell_TrayWnd to find the taskbar window on Windows.
Then GetWindowRect() is called to get the taskbar window rectangle. Finally, the taskbar window
rectangle is subtracted from the primary screen rectangle to calculate the work area. Without a
valid taskbar window position, these applications end up getting an incorrect work area and going
down the wrong path. So use the same position and size as the host system panel for explorer taskbar
when it's hidden.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1399
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v16: include: Add a comment explaining why all kernel callbacks must be in user32.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
--
v2: ntdll: Check non-volatile rflags and skip popfq when possible.
ntdll: Use -nofpu for NtQueryPerformanceCounter syscall.
ntdll: Inline __wine_unix_call_fast in the dispatcher.
winecrt0: Inline PE __wine_unix_call(_fast) function calls.
ntdll: Only save non-volatile FPU registers for -nofpu syscalls.
opengl32: Use __wine_unix_call_fast instead of __wine_unix_call.
ntdll: Introduce a new __wine_unix_call_fast syscall.
winebuild: Introduce a new -nofpu syscall spec flag.
ntdll: Use named labels for jumps in the syscall dispatcher.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1324
Currently it's not obvious when the HLSL compiler fails, either due to a missing
feature or incorrectly coded error check, which can unnecessarily complicate
debugging.
It's legal for well-behaved programs to try to compile invalid shaders, but that
should be a rare enough case that it's worth printing it to Wine debug output
regardless.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1340
mrac tries to get function pointers for these functions using MmGetSystemRoutineAddress, I haven't seen them being used by it, but might as well implement it since they are very easy to implement.
--
v8: ntoskrnl.exe: Implement KeQueryActiveProcessorCount.
ntoskrnl.exe: implement KeQueryMaximumProcessorCount/Ex.
https://gitlab.winehq.org/wine/wine/-/merge_requests/914
I believe this information could be very useful for newcomers to the HLSL compiler.
Documentation often needs to reference other parts of the code, so it can be a problem
to update these references if the referenced code is modified.
However, I think that documentation in the data definitions (as opposed to documentation inside the
functions) is easier to maintain, since each data type is declared in a single place, to which one
often keeps going back for reference, so it is less probable to forget to update a comment.
Also, it opens up the possibility of explaining **what** things are, instead of **how they are used**, in
some cases, avoiding these references to other places in the code.
I can think on the following additional benefits:
* Updates in these documentation comments, when the way a field is used changes, or when new fields are added,
can help making future commits more readable.
* Some IDEs display the comments above the field/struct declaration when the cursor is over an use of
this field/struct.
A hopefully not deceiving sketch:

--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/38