- wine-gitlab - winehq.org

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/device.c: > device->width = desc.dwWidth; > device->height = desc.dwHeight; > > + device->needs_update = FALSE; > + The device is zero-initialized, so I don't think this hunk is necessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63576

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/d3drm_private.h: > IDirect3DRM *d3drm; > IDirectDraw *ddraw; > IDirectDrawSurface *primary_surface, *render_target; > - IDirectDrawClipper *clipper; This should ideally be a separate patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63575

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/viewport.c: > - FIXME("iface %p, x1 %lu, y1 %lu, x2 %lu, y2 %lu stub!\n", iface, x1, y1, x2, y2); > + struct d3drm_viewport *viewport = impl_from_IDirect3DRMViewport2(iface); > + D3DVIEWPORT vp = { sizeof(vp) }; > + HRESULT hr; > > - return E_NOTIMPL; > + TRACE("iface %p, x1 %lu, y1 %lu, x2 %lu, y2 %lu.\n", iface, x1, y1, x2, y2); > + > + if (!viewport->d3d_viewport) > + return D3DRMERR_BADOBJECT; > + > + if (FAILED(hr = IDirect3DViewport_GetViewport(viewport->d3d_viewport, &vp))) > + return hr; > + > + if (x1 > x2 || y1 > y2 || x1 < vp.dwX || y1 < vp.dwY || > + x2 > (vp.dwX + vp.dwWidth) || y2 > (vp.dwY + vp.dwHeight)) It'd be nice to rename these parameters to left/right/top/bottom. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63574

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/tests/d3drm.c: > + struct update_surface_context ctx; > + D3DCOLOR ret_color = 0; > + DWORD clip_list_size; > + RGNDATA *clip_list; > + HWND window; > + HRESULT hr; > + > + window = create_window(); > + > + /* Set up device */ > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ok(hr == DD_OK, "Cannot get IDirectDrawClipper interface, hr %#lx.\n", hr); > + hr = IDirectDrawClipper_SetHWnd(clipper, 0, window); > + ok(hr == DD_OK, "Cannot set HWnd to Clipper, hr %#lx.\n", hr); > + hr = Direct3DRMCreate(&d3drm1); > + ok(SUCCEEDED(hr), "Cannot create IDirect3DRM instance, hr %#lx.\n", hr); Not a big deal, but in the future I'd like to avoid this, and just always check the actual hr value. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63572

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/tests/d3drm.c: > + > + /* Set color of a pixel on primary surface and on render target */ > + ClientToScreen(window, &client_pos); > + hr = set_surface_color(d3drm_primary, 320 + client_pos.x, 240 + client_pos.y, 0x00123456); > + if (FAILED(hr)) > + { > + win_skip("Cannot lock/unlock primary surface, hr %#lx, skipping tests\n", hr); > + goto cleanup; > + } > + ret_color = get_surface_color(d3drm_primary, 320 + client_pos.x, 240 + client_pos.y); > + if (!compare_color(ret_color, 0x00123456, 1)) > + { > + win_skip("Cannot set color of pixel on primary surface, color 0x%08lx, skipping tests\n", ret_color); > + goto cleanup; > + } > + hr = set_surface_color(surface, 320, 240, 0x000000ff); Where do these fail? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63573

1 0

[PATCH 0/3] MR5237: Use futexes on macOS for thread-ID alerts.
by Marc-Aurel Zent (＠mzent) 05 Mar '24

05 Mar '24

This also bumps the minimum supported version of macOS to 10.12 to unconditionally assume the ulock syscalls are present. As discussed with @Gcenx this shouldn't be an issue, as the current minimum support version of 10.8 does not work anyways at the moment with only 10.10+ being useable and even then virtually no-one using wine on versions < 10.12 (and also being unsupported by the prebuilt binaries). Bumping to 10.12 would also have the side-benefit of allowing some cleanup of deprecated functions or legacy codepaths (like `mach_continuous_time` vs `mach_absolute_time` and probably much more). In my testing ulock futexes are about 2x faster for synchronization than kevents. Using the syscall wrappers here should provide protection against changing syscall numbers, and given that ulock is also directly used by libc++, the probability of an incompatible API change here is basically zero imo. By default ulock is also process-private, similar to the current linux implementation, cross-process synchronization would require darwin 19+ (macOS 10.15+) with `UL_COMPARE_AND_WAIT_SHARED`. The diff is a bit bigger than it actually is in effect, since https://gitlab.winehq.org/mzent/wine/-/commit/28a8a991c165f0d37dbf78ca3cdee… is only moving some code around and not actually changing anything. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5237

3 5

[PATCH 0/4] MR5228: Administrator tokens, part 2: Create Wine processes with a limited token.
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Second half of <https://gitlab.winehq.org/wine/wine/-/merge_requests/5118>. This uses a different approach, setting the process token from within the process after it is created. This avoids the need to always relay through start.exe. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5228

2 5

[PATCH 0/1] MR5165: wined3d: Slightly adjust an ERR in shader_spirv_compile_shader().
by Henri Verbeet (＠hverbeet) 05 Mar '24

05 Mar '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5165

4 3

[PATCH 0/2] MR5229: ole32: Do not lock storage in read-only deny-write mode.
by Daniel Lehman (＠dlehman25) 05 Mar '24

05 Mar '24

(STGM_READ | STGM_SHARE_DENY_WRITE) doesn't apply to 20 user limit https://docs.microsoft.com/en-us/windows/win32/stg/structured-storage-inter… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5229

4 4

[PATCH v3 0/2] MR5222: kernelbase: Allow WriteProcessMemory to succeed on PAGE_EXECUTE_READ.
by Marc-Aurel Zent (＠mzent) 05 Mar '24

05 Mar '24

More details here: https://devblogs.microsoft.com/oldnewthing/20181206-00/?p=100415 However it does not mention that `PAGE_NOACCESS` and `PAGE_READONLY` still result in an error on Windows, which is properly implemented in this MR. Only `WriteProcessMemory` offers this "service", `NtWriteVirtualMemory` will fail on non-writeable and executable regions (and already does so, except for the the mach server backend, which needs https://gitlab.winehq.org/wine/wine/-/merge_requests/4826 to also behave correctly here). -- v3: kernelbase: Flush instruction cache when necessary in WriteProcessMemory. kernelbase: Allow WriteProcessMemory to succeed on PAGE_EXECUTE_READ. https://gitlab.winehq.org/wine/wine/-/merge_requests/5222

5 14

2025

2024

2023

2022

wine-gitlab