There is one more patch series of refactoring create_key() after this one, then I can start implementing things.
--
v2: kernelbase: Return the last existing key from open_key() when it's called from create_key().
kernelbase: Pass a name pointer to open_key().
kernelbase: Use open_key() to obtain any existing Wow6432node in create_key().
kernelbase: Call open_key() from open_subkey().
advapi32/tests: Copy Software\Classes tests from ntdll.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2445
In preparation to keep action map app data in there, for `SetActionMap`.
--
v2: dinput: Always set the DIPROP_BUFFERSIZE property in SetActionMap.
dinput: Initialize SetActionMap variables in their declarations.
dinput: Always allocate and initialize the object_properties.
dinput: Move mouse_create_device function around.
dinput: Initialize device object format when creating devices.
dinput: Count the actual number of object formats in SetActionMap.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2453
Today, NtCurrentTeb() has a single asm statement when compiling for the
i386, x86-64, or ARM architecture with GCC. This single asm statement
has neither the "volatile" qualifier nor the "memory" clobber.
This can provoke undefined behavior if the current TEB changes between
NtCurrentTeb() calls. This is because GCC assumes that the asm
statement does not depend on memory or the thread-local register. In
fact, given the same address of the "teb" variable, GCC assumes that the
asm statement produces exactly the same value on every invocaton.
This primarily causes issues when switching to another fiber from a
thread that is different from the thread on which the fiber was last
executed. Theoretically, however, this may also cause issues when the
optimizer aliases the "teb" variable to another variable that is shared
between threads, and perform global optimization that can work across
multiple threads in runtime (if any).
Fix this by adding the "memory" clobber to the asm statements that
computes the current TEB address.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2434
Diablo IV (closed beta) depends on DEVPKEY_Device_MatchingDeviceId being present for GPUs (once it is able to match GPU luid to the one obtained from dxgi). It also depends on the MatchingDeviceId conating "ven_" and "dev_" substrings. Without those it doesn't consider the gpu as valid, which currently results in the game complaining about no GPUs found. I guess that maybe it is trying to filter out software GPUs and such this way.
As far as my testing goes, DEVPKEY_Device_MatchingDeviceId has this form with hardware GPUs only and maybe with the recent enough Win10 or Win11.
The other two device properties being added are also queried by the game although they are not strictly needed for it.
--
v2: win32u: Set DEVPKEY_Device_RemovalPolicy for GPUs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2449
Diablo IV (closed beta) depends on DEVPKEY_Device_MatchingDeviceId being present for GPUs (once it is able to match GPU luid to the one obtained from dxgi). It also depends on the MatchingDeviceId conating "ven_" and "dev_" substrings. Without those it doesn't consider the gpu as valid, which currently results in the game complaining about no GPUs found. I guess that maybe it is trying to filter out software GPUs and such this way.
As far as my testing goes, DEVPKEY_Device_MatchingDeviceId has this form with hardware GPUs only and maybe with the recent enough Win10 or Win11.
The other two device properties being added are also queried by the game although they are not strictly needed for it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2449
On my Steam Deck, this reduces the time it takes to initialize the wg_parser radically (by around 1 second). This helps in the game WILD HEARTS, which doesn't present while loading help videos during gameplay, causing large stutters.
Because GStreamer can randomly access the file with no known pattern on our side, I opted to implement this by buffering 4 chunks so that interleaved reads to different areas of the file don't cause us to discard and reload cached data more than we need to.
--
v3: winegstreamer: Cache wg_parser input data.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2390
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v20: ddraw: Increasing the vertex batch size on demand
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
On my Steam Deck, this reduces the time it takes to initialize the wg_parser radically (by around 1 second). This helps in the game WILD HEARTS, which doesn't present while loading help videos during gameplay, causing large stutters.
Because GStreamer can randomly access the file with no known pattern on our side, I opted to implement this by buffering 4 chunks so that interleaved reads to different areas of the file don't cause us to discard and reload cached data more than we need to.
--
v2: winegstreamer: Cache wg_parser input data.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2390
test_loadpaths_execute() was sometimes getting ERROR_ALREADY_EXISTS when
creating its temporary directoryi. That was probably because
GetTempFileNameW() only uses the low 16-bits of the 'random' LUID which
goes over a wider range, potentially leading to collisions in the lower
16-bits.
Avoid AllocateLocallyUniqueId() entirely and add a helper function to
create a guaranteed new directory.
Also try to use the current directory first as it is assumed to have
been configured to ward off anti-virus programs (specifically
Microsoft Defender) which is especially important when writing
executables to that location. Only switch to the system's temporary
directory if the current directory is not a writable location.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54560
---
There are a few other tests where I suspect occasional anti-virus
interference. It may make sense to reuse this function in those.
That said create_new_dir() uses entirely predictable sequenitial
numbers which would be bad if attempting to create a secure directory.
But the new directory does not even have special permissions and this
type of attack shouldn't be an issue for the tests. Still, don't reuse
this code in contexts where security matters.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2446
Today, RtlCreateActivationContext (CreateActCtxW) opens the source
manifest file via NtOpenFile without the FILE_SHARE_DELETE sharing mode.
This causes CreateActCtxW to fail if the source manifest file was
created with the FILE_DELETE_ON_CLOSE flag. FILE_DELETE_ON_CLOSE is
often used for temporary files that should be automatically deleted
after use, even if the creator process crashes.
Fix this by specifying FILE_SHARE_DELETE for sharing mode when opening
the source manifest or module file. This allows the source manifest or
module file to be marked as deleted while it is open.
Note that concurrent deletion is not an issue for the following reasons:
- The ability to read from an open file handle is unaffected by deletion
of the corresponding file's name.
- RtlCreateActivationContext does not open the source manifest or module
file by the given filename (lpSource) more than once.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2433
Hans Leidekker (@hans) commented about loader/wine.inf.in:
> 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
> 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
> 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
> +HKLM,%CurrentVersionNT%,"EditionId",2,"Core"
> HKLM,%CurrentVersionNT%,"ProductName",2,"Windows 10 Pro"
Why "Core"? It seems to me that "Professional" would make more sense given that ProductName is "Windows 10 Pro".
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2438#note_27258
After today's rebase, I found a workaround for creating new documents. You can open an existing document, then click on the home tab, and create a new document in one of the tabs. There seems to a bit of UB left, but it's better than nothing.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2377#note_27257
This fixes a bug in the game "Nioh: The Complete Edition", where the videos after the first video are played too quickly.
--
v2: quartz: Set filter sync source in FilterGraph2_AddFilter.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2380
Convert all consecutive calls to d7_DrawPrimitive(TRIANGLE_FAN) into
a single call to d7_DrawPrimitive(TRIANGLE_LIST) with all the vertices.
Note, it *increase* the number of vertices, but bandwith is much less costly
than multiple calls.
Note, only a very precise subset of the calls get buffered in order to
ensure that the disruption is minimal.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33814
--
v19: ddraw: Increasing the vertex batch size on demand
ddraw: add d3d_perf statistics on buffering
wined3d: Add a TRACE in wined3d_streaming_buffer_unmap()
ddraw: Add a local buffer in d3d_device7_DrawPrimitive()
https://gitlab.winehq.org/wine/wine/-/merge_requests/2105
On Fri Mar 17 10:14:05 2023 +0000, Rémi Bernon wrote:
> Yes, thanks a lot.
> > Yeah, it might be useful to keep them around. I spent a long time
> working on it so it would be nice to keep it, but perhaps I should first
> split it up into smaller additions for easier review. In any case,
> here's a branch of the headers in case you need it in the future: https://gitlab.winehq.org/maljaf/wine/-/commits/WinRT-Core
> I can only imagine the time your spent, and thanks for doing that. It
> may be arguably useful to have them in Wine, but at the same time it's
> also a lot of additions.
> The amount of code that is in the SDK IDL files is quite overwhelming, I
> don't know if there's any saner way to have them than rewriting
> everything by hand. They are actually generated from some binary
> metadata, so maybe we could do that too (but then where to source this
> metadata is a good question).
> An alternative which I thought about was to implement IDL 3.0 syntax,
> which I believe allows much terser interface / runtimeclass declaration,
> and would generate the same header output.
> Or, somehow, we could make WIDL compatible with the SDK IDL files, and
> use them directly, but here like with the .winmd metadata, there's the
> question of how to source it properly.
> In any case I'm really not looking forward the time where we'll need to
> stub or implement all these new interfaces...
No problem, anything to make review easier for you.
Yeah, it is a lot of additions. Maybe I'll wait for an application to need it before submitting it again, even if it's just for compilation like FireFox mingw.
Interesting, I did notice the Windows SDK idl files say they are autogenerated at the top. Sourcing the metadata is indeed the main problem. There are some in C:\Windows\System32\WinMetadata and you could use the tool Ildasm.exe to disassemble them, but this seems like a grey area around clean room design and might be best to avoid it. Another option would be trial-and-error, just writing and rewriting binary metadata until it generates a similar idl file to the Windows SDK one. Though, I'm not sure if it's worth the effort.
I took a look at the IDL 3.0 syntax and you're right, it's much more concise and would help with the bigger idl files like `windows.ui.core.idl`. The documentation is thorough: https://learn.microsoft.com/en-us/uwp/midl-3/intro
I wouldn't mind stubbing the interfaces, though for windows.ui.core.idl there's definitely too many functions in the `ICoreWindow` interface alone. Implementing them is another issue, hopefully they're not too complex.
Also, thanks for the review! :slight_smile:
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2386#note_27267
On Sun Mar 19 11:07:47 2023 +0000, Hans Leidekker wrote:
> Why "Core"? It seems to me that "Professional" would make more sense
> given that ProductName is "Windows 10 Pro".
"Core" is what is says on my win10 virtualbox win10, but I guess "Professional" would indeed make more sense. I`ll try to update merge request
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2438#note_27260
In particular:
* Fix the resume handle comments.
* Don't expect START_PENDING and STOP_PENDING services to have a process id.
* Take into account service start / stop race conditions.
* Enumerate the services using the Unicode API since the ANSI one is broken in some UTF-8 locales.
* Skip some tests if the EventLog service crashed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2431
--
v4: vkd3d: Pass an offset and size to d3d12_heap_unmap() in d3d12_resource_WriteToSubresource().
vkd3d: Call vkFlushMappedMemoryRanges() when a heap remains mapped after an unmapping request.
vkd3d: Pass an offset and size to d3d12_heap_map() in d3d12_resource_ReadFromSubresource().
vkd3d: Call vkInvalidateMappedMemoryRanges() when a mapping is requested on a mapped heap.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/126
Log: The flag that bNoItemMetrics should be reset to TRUE after
calling LISTVIEW_DeleteAllItems().
Signed-off-by: Zhao Yi <zhaoyi(a)uniontech.com>
--
v3: comctl32: Fix the problem that listview cannot display all files.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2413