This series has been split up more than the prior two, keeping the non-tests diffs below 200. Hopefully it's easier to review now. If not, please let me know and I can _try_ to split it further, but I'm not sure it can get much more split up than this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/832
On Wed Sep 14 11:53:01 2022 +0000, Santino Mazza wrote:
> Because it simplifies the implementation for saving the registry into
> the file when NtClose get's called. If I want to keep the object handle
> implementation the server should take control for closing the file
> handle, and I don't like that idea so much, I think the caller should be
> responsible for closing the objects it opens.
Ok, let me look into that more.
There are a couple more changes you could make in the meantime:
- Split the `REG_LOAD_APP_KEY` logic and the return key logic into two commits.
- Move the `NtClose()` outside of the `SERVER_START_REQ` block.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8415
On Wed Sep 14 10:35:23 2022 +0000, Huw Davies wrote:
> Why are you now sending the filename, rather than the file object
> handle, to the server?
Because it simplifies the implementation for saving the registry into the file when NtClose get's called. If I want to keep the object handle implementation the server should take control for closing the file handle, and I don't like that idea so much, I think the caller should be responsible for closing the objects it opens.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8405
On Wed Sep 14 10:36:44 2022 +0000, Alexandre Julliard wrote:
> > I bisected the failure and it looks like it's caused instead by
> 44d6f2adbcca119faebc095f3cfbeeafc50d04f3, from
> https://gitlab.winehq.org/wine/wine/-/merge_requests/657. Reverting it
> alone fixes it:
> Ah sorry about that, reverting your MR fixed it for me but it's possible
> that I screwed up the test.
- Just a test message from E-Mail. -
Am Mi., 14. Sept. 2022 um 11:05 Uhr schrieb Alexandre Julliard
(@julliard) <gitlab(a)winehq.org>:
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/814#note_8404
Huw Davies (@huw) commented about server/protocol.def:
>
> /* Load a registry branch from a file */
> @REQ(load_registry)
> - obj_handle_t file; /* file to load from */
> + unsigned int flags; /* flags */
> + unsigned int access; /* wanted access rights */
> VARARG(objattr,object_attributes); /* object attributes */
> + VARARG(filename,string); /* file to load name */
Why are you now sending the filename, rather than the file object handle, to the server?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8403
Huw Davies (@huw) commented about dlls/advapi32/tests/registry.c:
> /* Test simple key load */
> /* Check if the changes are saved */
> ret = RegLoadAppKeyA(hivefilepath, &appkey, KEY_READ | KEY_WRITE, 0, 0);
> - ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %ld\n", ret);
> - ok(appkey != NULL, "got a null key\n");
> + todo_wine ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %ld\n", ret);
> + todo_wine ok(appkey != NULL, "got a null key\n");
I'd suggest swapping the order of these commits so that you don't end up having to flip-flop these `todo_wine`s.
Also note that there's now no need to add the Signed-off-by tags.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/820#note_8402
--
v3: winecoreaudio: Switch to mmdevapi's unixlib.h.
winecoreaudio: Adapt "get_capture_buffer_params" struct to mmdevapi's.
winecoreaudio: Adapt "release_render_buffer_params" struct to mmdevapi's.
winecoreaudio: Adapt "release_stream_params" struct to mmdevapi's.
winecoreaudio: Adapt "create_stream_params" struct to mmdevapi's.
winecoreaudio: Adapt "endpoint" struct to mmdevapi's.
winecoreaudio: Drop "unix_" prefix in unixlib enum, apply it to the functions instead.
mmdevapi: Integrate winecoreaudio's additions in unixlib.h.
winecoreaudio: Switch to string as device identifier, to match other drivers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/813
--
v2: mf/tests: Factor IMFTransform required attributes checks together.
mf/tests: Test AAC decoder MFT presence and media types.
mf/tests: Test AAC encoder MFT presence and media types.
mf/tests: Split create_transform into check_(mft|dmo)_(enum|get_info).
mf/tests: Add some winetest context to MFT tests.
mf/tests: Split IMFTransform tests to transform.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/791
> As far as I can tell it was changed (perhaps inadvertently) by Mesa commit 0cb42c57c569443b0af8296dfff4da1e6ab241ef. Previously "AMD" string would be present in the renderer string for cases where there was no marketing name (i.e. Etaash's gpu would have a GL_RENDERER value beginning with "AMD RENOIR").
Looks plausible enough; ideally we'd get that fixed.
> As far as I can tell, radeonsi has only ever reported a GL_VENDOR of "X.org" or (more recently) "AMD", so we've been relying on "AMD" being present in the renderer string.
It's slightly worse, actually. Cards with a "marketing" name will have a renderer string like "Radeon RX Vega (VEGA10, ...)", so for these we'd depend on the "Radeon"/"FirePro" strings. If the vendor string now includes "AMD" we'd certainly want to use that; in that regard the original commit is fine.
> It may also be a good idea to try matching the card vendor based on the PCI vendor first; I imagine that will remain a bit more stable against changes like this.
Yes, I think that would be helpful.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/826#note_8323
On Tue Sep 13 15:10:00 2022 +0000, Henri Verbeet wrote:
> > As far as I can tell it was changed (perhaps inadvertently) by Mesa
> commit 0cb42c57c569443b0af8296dfff4da1e6ab241ef. Previously "AMD" string
> would be present in the renderer string for cases where there was no
> marketing name (i.e. Etaash's gpu would have a GL_RENDERER value
> beginning with "AMD RENOIR").
> Looks plausible enough; ideally we'd get that fixed.
> > As far as I can tell, radeonsi has only ever reported a GL_VENDOR of
> "X.org" or (more recently) "AMD", so we've been relying on "AMD" being
> present in the renderer string.
> It's slightly worse, actually. Cards with a "marketing" name will have a
> renderer string like "Radeon RX Vega (VEGA10, ...)", so for these we'd
> depend on the "Radeon"/"FirePro" strings. If the vendor string now
> includes "AMD" we'd certainly want to use that; in that regard the
> original commit is fine.
> > It may also be a good idea to try matching the card vendor based on
> the PCI vendor first; I imagine that will remain a bit more stable
> against changes like this.
> Yes, I think that would be helpful.
I modified the PR to use the PCI id yesterday, so there's no need to "guess" which card this is anymore, and it works as expected.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/826#note_8343
As well as a few other fixes for https://gitlab.winehq.org/wine/wine/-/merge_requests/551.
--
v3: win32u: Introduce a new internal WINE_DM_UNSUPPORTED display flag.
win32u: Pass adapter parameter to (read|write)_registry_settings.
win32u: Avoid unnecessary copy of adapter path and device name.
win32u: Avoid copying the modes array in NtUserChangeDisplaySettings.
win32u: Introduce reference counting to struct adapter.
win32u: Fill the local full_mode variable instead of using the modes array.
win32u: Rename get_full_mode variables and avoid using devmode directly.
wineandroid.drv: Add missing DM_DISPLAYORIENTATION flag on display mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/814
This implements sending StorageEvents to the same window/doc from where the storage change happened, which seems to be a thing on native IE. For some reason I was unable to have them actually sent to other windows, so that's not implemented since I've no idea how that even gets triggered to test it, and if it does it will probably be in a follow up MR, even though that's *supposed* to be the use of these events���
localStorage sends for `onstoragecommit` on the doc that did the change, while sessionStorage sends for `onstorage` on the window and doc that did the change, depending on compat mode. Although the event sent to the document's `onstorage` seems to be a legacy/old-style event (as tests show).
Tests are on the last patch since events have to be sent properly (else it hangs).
--
v5: mshtml: Send StorageEvents to iframe windows properly.
mshtml: Don't expose document.onstorage for IE9+ modes.
mshtml/tests: Add tests for StorageEvents with parallel documents.
mshtml: Send StorageEvents when removing an existing item.
mshtml: Send StorageEvents when setting an item.
mshtml: Implement StorageEvent and send it when clearing the storage.
mshtml: Move the MessageEvent construction to a helper.
include/mshtml: Add IDOMStorageEvent and DispDOMStorageEvent interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/795
What do the linked test results show? I assume you made those runs with the changed tests as in the patch. If so, it seems that this proposed behavior is correct for d3d8, but not for d3d9? If that's right, we should probably include this distinction in the implementation; and the d3d9 test should be changed to reflect actual behavior.
As an aside, the commit could be improved in terms of style: Don't Capitalize Every Word, fix oddly placed whitespace, and drop the `<br>`.
Thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/722#note_8315
--
v2: rsaenh: Use BCrypt algorithm pseudo-handles.
ncrypt: Use BCrypt algorithm pseudo-handles.
fusion: Use BCrypt algorithm pseudo-handles.
dssenh: Use BCrypt algorithm pseudo-handles.
crypt32: Use BCrypt algorithm pseudo-handles.
appwiz.cpl: Use BCryptHash().
appwiz.cpl: Use BCrypt algorithm pseudo-handles.
bcrypt: Rename mode_id to chain_mode.
bcrypt: Add full support for algorithm pseudo-handles.
https://gitlab.winehq.org/wine/wine/-/merge_requests/834
At least Doom 64 calls ClipCursor() with identical parameters
repeatedly, which seems to cause a considerable overhead. Together with
high polling rate mouse input this causes the game to almost freeze
while the mouse is being moved. So if the clipping did not change we can
bail out early because it will not cause any observable difference
anyway.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46976
Signed-off-by: Jan Kl��tzke <jan(a)kloetzke.net>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/825
As well as a few other fixes for https://gitlab.winehq.org/wine/wine/-/merge_requests/551.
--
v2: win32u: Introduce a new internal WINE_DM_UNSUPPORTED display flag.
win32u: Rename (read|write)_registry_settings to adapter_(set|get)_default_mode.
win32u: Avoid unnecessary copy of adapter path and device name.
win32u: Avoid copying the modes array in NtUserChangeDisplaySettings.
win32u: Introduce reference counting to struct adapter.
win32u: Fill the local full_mode variable instead of using the modes array.
win32u: Rename get_full_mode variables and avoid using devmode directly.
wineandroid.drv: Add missing DM_DISPLAYORIENTATION flag on display mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/814
Due to me updating to mesa-git, the gl vendor string got changed and now wine thinks it's an nvidia card, so this patch fixes it
--
v2: wined3d: Fix bug with AMD gl vendor returning nvidia
https://gitlab.winehq.org/wine/wine/-/merge_requests/826
Due to me updating to mesa-git, the gl vendor string got changed and now wine thinks it's an nvidia card, so this patch fixes it
--
v4: wined3d: Add support for renoir graphics
https://gitlab.winehq.org/wine/wine/-/merge_requests/826
This implements sending StorageEvents to the same window/doc from where the storage change happened, which seems to be a thing on native IE. For some reason I was unable to have them actually sent to other windows, so that's not implemented since I've no idea how that even gets triggered to test it, and if it does it will probably be in a follow up MR, even though that's *supposed* to be the use of these events���
localStorage sends for `onstoragecommit` on the doc that did the change, while sessionStorage sends for `onstorage` on the window and doc that did the change, depending on compat mode. Although the event sent to the document's `onstorage` seems to be a legacy/old-style event (as tests show).
Tests are on the last patch since events have to be sent properly (else it hangs).
--
v4: mshtml: Send StorageEvents to iframe windows properly.
mshtml: Don't expose document.onstorage for IE9+ modes.
mshtml/tests: Add tests for StorageEvents with parallel documents.
mshtml: Send StorageEvents when removing an existing item.
mshtml: Send StorageEvents when setting an item.
mshtml: Implement StorageEvent and send it when clearing the storage.
mshtml: Move the MessageEvent construction to a helper.
include/mshtml: Add IDOMStorageEvent and DispDOMStorageEvent interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/795
--
v2: winegstreamer: Request the wm_reader stream only when necessary.
winegstreamer: Introduce a new async_reader_wait_pts helper.
winegstreamer: Factor async_reader waits using async_reader_get_wait_timeout.
winegstreamer: Check whether the reader is still running before user time.
winegstreamer: Keep start time in the async_reader struct.
winegstreamer: Implement async reader asynchronous seeking.
winegstreamer: Unconditionally assign new context for ASYNC_OP_START.
winegstreamer: Wrap async reader op new_context in a union.
wmvcore/tests: Add some tests starting WM reader with NULL context.
https://gitlab.winehq.org/wine/wine/-/merge_requests/803
Both non-visual and visual runs go through fallback mapping process, and
could end up with hard coded default at the end if fallback was insufficient.
Visual runs are using custom fallback and then the system one, non-visual ones
are using only system fallback.
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/831
So that d2d_device_context_IsSupported() can know what type and usage a render target is created for.
--
v2: d2d1: Implement d2d_device_context_IsSupported().
d2d1: Save render target type and usage.
d2d1/tests: Test d2d_device_context_IsSupported().
https://gitlab.winehq.org/wine/wine/-/merge_requests/811
This implements sending StorageEvents to the same window/doc from where the storage change happened, which seems to be a thing on native IE. For some reason I was unable to have them actually sent to other windows, so that's not implemented since I've no idea how that even gets triggered to test it, and if it does it will probably be in a follow up MR, even though that's *supposed* to be the use of these events���
localStorage sends for `onstoragecommit` on the doc that did the change, while sessionStorage sends for `onstorage` on the window and doc that did the change, depending on compat mode. Although the event sent to the document's `onstorage` seems to be a legacy/old-style event (as tests show).
Tests are on the last patch since events have to be sent properly (else it hangs).
--
v3: mshtml/tests: Add tests for StorageEvents.
mshtml: Send StorageEvents when removing an existing item.
mshtml: Send StorageEvents when setting an item.
mshtml: Implement StorageEvent and send it when clearing the storage.
mshtml: Move the MessageEvent construction to a helper.
include: Add IDOMStorageEvent and DispDOMStorageEvent interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/795
--
v2: winecoreaudio: Switch to mmdevapi's unixlib.h.
winecoreaudio: Adapt "get_mix_format_params" struct to mmdevapi's.
winecoreaudio: Adapt "is_format_supported_params" struct to mmdevapi's.
winecoreaudio: Adapt "get_capture_buffer_params" struct to mmdevapi's.
winecoreaudio: Adapt "release_render_buffer_params" struct to mmdevapi's.
winecoreaudio: Adapt "release_stream_params" struct to mmdevapi's.
winecoreaudio: Adapt "create_stream_params" struct to mmdevapi's.
winecoreaudio: Adapt "endpoint" struct to mmdevapi's.
winecoreaudio: Drop "unix_" prefix in unixlib enum, apply it to the functions instead.
mmdevapi: Integrate winecoreaudio's additions in unixlib.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/813
this gets the YSDrv service to start successfully (with the MmAllocateContiguousMemorySpecifyCache semi-stub)
this service is used by the nox android emulator
--
v17: ntoskrnl: Add KeInsertQueueDpc stub
https://gitlab.winehq.org/wine/wine/-/merge_requests/778
this gets the YSDrv service to start successfully (with the MmAllocateContiguousMemorySpecifyCache semi-stub)
this service is used by the nox android emulator
--
v16: Add KeInsertQueueDpc stub
https://gitlab.winehq.org/wine/wine/-/merge_requests/778
This MR accomplishes two things:
1. It removes unused obsolete tests for Windows XP or earlier.
2. It synchronizes RtlUniform so that it matches that of Windows Vista or later.
--
v3: ntdll: Fix integer overflow in RtlUniform.
ntdll/tests: Update test_RtlUniform to match Windows Vista or later.
https://gitlab.winehq.org/wine/wine/-/merge_requests/821
This MR accomplishes two things:
1. It removes unused obsolete tests for Windows XP or earlier.
2. It synchronizes RtlUniform so that it matches that of Windows Vista or later.
--
v2: ntdll: Fix integer overflow in RtlUniform.
https://gitlab.winehq.org/wine/wine/-/merge_requests/821
This MR accomplishes two things:
1. It removes unused obsolete tests for Windows XP or earlier.
2. It synchronizes RtlUniform so that it matches that of Windows Vista or later.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/821