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:
![Hopefully not deceiving sketch.](/uploads/3f9e65a0dc091904e8267e23e58e37be/field_level_doc.png)
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/38