This fixes various problems I've run into while trying to use Fusion 360 in wine.
- stacking issues in unmanaged mode
- I also attempted to apply the same fix for managed mode, but it looks difficult to do this in a way that plays well with window managers; I think it's best left up to them to keep override_redirect windows at the top of the stack)
- when the window manager sets our state to withdrawn, tell the window that it's been minimized, since the semantics are very similar
- the last one is a hack because I don't really know what to do about it, when clicking on the floating popups, they gain focus, which causes wine to incorrectly make them managed and that breaks everything
--
v2: winex11: don't make a window managed because it's active
winex11: pass ICCCM withdrawn state as minimized
winex11: restack a window's owned popups above it
https://gitlab.winehq.org/wine/wine/-/merge_requests/2343
Trying to reduce the likelihood of spurious failures. Keyboard / mouse devices are more subject to window foreground issues and less reliable than the HID joystick device. This also increases the timeout of some waits that aren't supposed to fail, trying to mitigate possible failures on Gitlab CI, under suspected heavy load.
Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/2261.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54558
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54594
--
v3: dinput/tests: Increase timeouts for waits not supposed to fail.
dinput/tests: Remove BuildActionMap / SaveActionMap mouse and keyboard tests.
dinput/tests: Test SaveActionMap effect on HID joystick input.
dinput/tests: Test SaveActionMap effect on DIPROP_RANGE property.
dinput/tests: Test SaveActionMap effect on DIPROP_BUFFERSIZE property.
dinput/tests: Test SaveActionMap effect on DIPROP_APPDATA property.
dinput/tests: Test SaveActionMap effect on DIPROP_USERNAME property.
dinput/tests: Test BuildActionMap / SaveActionMap with the HID joystick.
include: Add some dinput.h action semantics definitions.
dinput/tests: Skip the tests if acquiring the device fails.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2421
On Thu Mar 16 10:28:20 2023 +0000, Huw Davies wrote:
> I don't think we want these in the other drivers. They're more of an
> historical artefact - they used to be the only pulse endpoints before
> support for enumerating the others was added. We may even want to
> remove them from pulse; I think @ivyl had been looking into an issue
> with them on the Steam Deck.
I think they're still useful, since they're the only "movable" devices (in PA Volume Control for example). They use the largest channel mask out of all the sources/sinks, so it's not a problem to have them movable with no notifications to the app, unlike the others.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2364#note_27048
--
v2: imm32/tests: Test basic ImmEnumInputContext usage.
imm32/tests: Test ImmUnregisterWord with the installed IME.
imm32/tests: Test ImmGetRegisterWordStyle with the installed IME.
imm32/tests: Test ImmRegisterWord with the installed IME.
imm32/tests: Test ImmEnumRegisterWord with the installed IME.
imm32/tests: Test ImmEscape with the installed IME.
imm32/tests: Test ImmGetProperty with the installed IME.
imm32/tests: Test ImmIsIME with the installed IME.
imm32/tests: Use LANG_INVARIANT for the installed IME.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2419
On Thu Mar 16 06:06:15 2023 +0000, Davide Beatrici wrote:
> @huw Bump.
I don't think we want these in the other drivers. They're more of an historical artefact - they used to be the only pulse endpoints before support for enumerating the others was added. We may even want to remove them from pulse; I think @ivyl had been looking into an issue with them on the Steam Deck.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2364#note_27025
The pop-up dialog requesting installation of Mono can be an inconvenience when automating processes involving Wine. In some cases it's also helpful to be able to install a clean Wine prefix without having Mono auto-installed as part of the prefix initialisation. This MR adds environment variables allowing the user to prevent installation of the Mono and Gecko.
--
v2: appwiz.cpl: Allow installation of add-ons to be skipped.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1661
On Sat Mar 11 02:06:48 2023 +0000, Davide Beatrici wrote:
> Actually, I just realized only `winepulse` defines a GUID for the
> default render and capture device...
> Should we do that in the other drivers too?
@huw Bump.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2364#note_27017
Log: The flag that bNoItemMetrics should be reset to TRUE after
calling LISTVIEW_DeleteAllItems().
Signed-off-by: Zhao Yi <zhaoyi(a)uniontech.com>
--
v2: light.msstyles: Add nonclient metrics.
user32/tests: Do not modify cursor position when simulating clicks.
gitlab: Make FVWM respect position hints.
kernelbase: Restructure the create_key() loop.
kernelbase: Add a fast path to create_key().
kernelbase: Move create_key() below open_key().
kernelbase: Factor opening a subkey out of open_key().
kernelbase: Always try to open the Wow6432Node in open_key().
kernelbase: Restructure the open_key() loop.
kernelbase: Pass the key name to create_key().
kernelbase: Pass the root key to create_key().
kernelbase: Pass the key name to open_key().
kernelbase: Pass the root key to open_key().
imm32: Use CRT allocation functions.
imm32: Rewrite ImmGetDescription(A|W).
imm32: Rewrite ImmGetIMEFileName(A|W).
imm32: Transform "Ime File" value in ImmInstallIMEW.
imm32: Rename szImeRegFmt to layouts_formatW.
wineboot: Add processor features for supported WoW64 architectures on ARM64.
wow64: Forward NtWow64IsProcessorFeaturePresent() to the CPU backend.
ntdll: Implement NtWow64IsProcessorFeaturePresent().
ntdll/tests: Update some todos that succeed with the new wow64 architecture.
ntdll/tests: Fix Wow64 tests failures on Windows 11 ARM64.
ntdll/tests: Handle another possible status when SystemProcessorFeaturesInformation is not supported.
d3dcompiler: Handle some newer D3D_BLOB_PART values in debug_d3dcompiler_d3d_blob_part().
widl: Remove unused temp_name member.
widl: Use bison-bridge option.
widl: Use noyywrap lexer option.
widl: Add missing rule end semicolons.
widl: Use explicit %empty token for empty rules.
windows.networking: Stub DllGetActivationFactory().
wofutil: Stub WofIsExternalFile().
wintypes: Stub RoIsApiContractMajorVersionPresent().
winex11: Remove now unnecessary user locale change checks.
win32u: Prevent user locale change in NtUserActivateKeyboardLayout.
win32u: Keep the current user locale when loading layout.
win32u: Keep the current user locale when enumerating layouts.
winegstreamer/media_source: Close bytestream in ::Shutdown.
mfplat/tests: Test bytestream closing behavior in IMFMediaSource::Shutdown.
d3d8/tests: Remove an unused call to IDirect3D8_GetAdapterDisplayMode().
wined3d: Sort the exports.
d3d11: Get rid of the DXBC tag definitions.
wineboot: Use the SystemProcessorBrandString query instead of cpuid.
ntdll: Implement the SystemProcessorFeaturesInformation query.
ntdll: Implement the SystemProcessorBrandString query.
ntdll: Fix some CPU information tests on ARM64.
imm32: Use a single ime_is_unicode helper.
imm32: Delete unnecessary uSelected struct ime member.
imm32: Rename some struct ime members.
imm32: Implement ImmLoadIME and ImmFreeLayout.
ddraw: Move sub-resource surface initialization to ddraw_surface_create_wined3d_texture().
ddraw: Factor out more common initialization into ddraw_surface_create_wined3d_texture().
ddraw: Move sysmem_fallback setting to ddraw_surface_create_wined3d_texture().
ddraw: Remove some outdated comments from ddraw_surface7_SetSurfaceDesc().
ddraw: Rename "is_complex_root" to "is_root".
wined3d: Move the WINED3D_RS_COLORKEYBLENDENABLE stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_EXTENTS stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_WRAP0 stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_WRAP1 stub to wined3d_device_apply_stateblock.
wined3d: Move the WINED3D_RS_WRAP2 stub to wined3d_device_apply_stateblock.
wined3d: Use wined3d_get_line() in shader_spirv_scan_shader().
wined3d: Use wined3d_get_line() in shader_spirv_compile_shader().
wined3d: Use wined3d_get_line() in shader_arb_compile().
wined3d: Use wined3d_get_line() in shader_glsl_dump_program_source().
wined3d: Use wined3d_get_line() in shader_glsl_compile().
wined3d: Don't bother explicitly terminating the GLSL info log in print_glsl_info_log().
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2413
So the other MR was merged and I have to comment here. Creating word documents no longer works after the rebase. There was a trick to get it working if you use the New tab instead of the Home tab, but that doesn't work either now. Opening Word documents still works.
This problem relates to X11. It and other force-closes print logs related to X11 BadWindow. Some things worked in Openbox, some things worked in kwin-wayland XWayland.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2377#note_27007
This node type is intended for use during parse-time.
While we parse an indexing expression such as `a[3]`, we don't know if
it will end up as part of an expression (in which case it must be folded
into a load) or it is for the lhs of a store (in which case it must be
folded into the store's deref). This node type is used to represent these accesses and no longer rely on building an `hlsl_ir_load` for each array index or struct record access.
`hlsl_ir_index` chains are lowered into derefs when (and if) they are used to specify the lhs of an assignment. All `hlsl_ir_index`es are lowered into `hlsl_ir_load`s with a compilation pass.
The changes introduced in these series allow to solve the problem with the return variable of function calls presented in !93, and to properly support assignment to matrix indexes, which is something we are not doing correctly.
Further patches (in my [index node](https://gitlab.winehq.org/fcasas/vkd3d/-/commits/index_node) branch) add support for indexing non-load expressions, such as `(a + b)[1]` and allowing to represent resource loads through `hlsl_ir_index`, so that `hlsl_ir_resource_store`s don't have to rely on `hlsl_ir_resource_load`s.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/124
FVWM doesn't respect PPosition hints by default and tries to tile a window according to its rules.
This might break tests that require a window at a specific position. For example, when setting the
caption bar height to anything other than 18, some user32 tests start to fail. They succeeded
previously just because the caption bar and border height on FVWM totals to 18, which is happens to
be the same value used by Wine by default.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2410
Hans Leidekker (@hans) commented about dlls/crypt32/str.c:
> - oid = szOID_RSA_emailAddr;
> - nameAttr = CertFindRDNAttr(oid, nameInfo);
> + if (oid)
> + nameAttr = CertFindRDNAttr(oid, nameInfo);
> + else
> + {
> + static const LPCSTR attributeOIDs[] =
> + {
> + szOID_RSA_emailAddr, szOID_COMMON_NAME,
> + szOID_ORGANIZATIONAL_UNIT_NAME, szOID_ORGANIZATION_NAME
> + };
> + DWORD i;
> +
> + for (i = 0; !nameAttr && i < ARRAY_SIZE(attributeOIDs); i++)
> + nameAttr = CertFindRDNAttr(attributeOIDs[i], nameInfo);
> + }
Thanks for the patch. Could you add a test to crypt32/tests/str.c? At least one fallback case would be good to have.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2403#note_26961
LPWSTR __cdecl wcsncpy( LPWSTR s1, LPCWSTR s2, size_t n )
{
WCHAR *ret = s1;
**//When encountering 0, the loop will jump out directly, but the pointer of s1 has been++, which leads to the memory overflow of the second for**
for ( ; n; n--) if (!(*s1++ = *s2++)) break;
for ( ; n; n--) *s1++ = 0;
return ret;
}
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2363
Introduction
------------
This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know.
A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland.
Part 1
-------
~~This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files.~~
This MR introduces the Wayland driver PE and unixlib components with some basic code, and reports some basic monitor information to Wine.
Please see the individual commit message for more details.
Some questions I would appreciate some feedback on in the context of this MR:
1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland)
2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland)
Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list.
~~Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.~~
Part 2 preview: We will report more monitor information and implement GetCurrentDisplaySettings.
--
v11: winewayland.drv: Report all advertised monitor modes to Wine.
winewayland.drv: Report basic monitor information.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2275
Introduction
------------
This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know.
A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland.
Part 1
-------
~~This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files.~~
This MR introduces the Wayland driver PE and unixlib components with some basic code, and reports some basic monitor information to Wine.
Please see the individual commit message for more details.
Some questions I would appreciate some feedback on in the context of this MR:
1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland)
2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland)
Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list.
~~Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.~~
Part 2 preview: We will report more monitor information and implement GetCurrentDisplaySettings.
--
v10: winewayland.drv: Report all advertised monitor modes to Wine.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2275
Some preliminary changes, to later improve widl error messages location, as well as compatibility with Windows SDK IDLs.
I'm not sure if the latter will be very useful, but it may be interesting to have.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2396
Introduction
------------
This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know.
A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland.
Part 1
-------
~~This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files.~~
This MR introduces the Wayland driver PE and unixlib components with some basic code, and reports some basic monitor information to Wine.
Please see the individual commit message for more details.
Some questions I would appreciate some feedback on in the context of this MR:
1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland)
2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland)
Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list.
~~Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.~~
Part 2 preview: We will report more monitor information and implement GetCurrentDisplaySettings.
--
v9: winewayland.drv: Report all advertised monitor modes to Wine.
winewayland.drv: Report basic monitor information.
win32u: Allow drivers to set the null user driver.
winewayland.drv: Perform basic per-process Wayland initialization.
winewayland.drv: Add initial unixlib stub.
winewayland.drv: Add initial driver stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2275
Otherwise we get nested exceptions on linux on any breakpoint in
a multi-arch wow64 (AMD64) configuration, running a 32bit debuggee.
With this patch, winetest kernel32:debugger runs to the end (it times
out without), yet spitting a couple of failures (that don't exist in
old wow64 configuration).
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2157
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2390
Rémi Bernon (@rbernon) commented about include/windows.graphics.holographic.idl:
> +import "windows.graphics.directx.direct3d11.idl";
> +import "windows.perception.idl";
> +import "windows.perception.spatial.idl";
> +import "windows.ui.core.idl";
> +
> +namespace Windows.Graphics.Holographic {
> + typedef enum HolographicFramePresentResult HolographicFramePresentResult;
> + typedef enum HolographicFramePresentWaitBehavior HolographicFramePresentWaitBehavior;
> + typedef struct HolographicAdapterId HolographicAdapterId;
> + typedef struct HolographicStereoTransform HolographicStereoTransform;
> +
> + interface IHolographicCameraPose;
> + interface IHolographicCameraRenderingParameters;
> + interface IHolographicFrame;
> + interface IHolographicFramePrediction;
> + interface IHolographicSpaceStatics2;
If you only forward declare `IHolographicSpaceStatics` here, you don't need its definition later in the file, as you also don't implement it.
This then makes 5ec7b6eecc89f2e88df836e1e68c9d59fa640816 ad31506143de193058129e2981818b6e7fc5c252 8fbfa09fd86eb7306688e0914c44964860165a0d 2e1f8bd100e040e8025c5801cecdf7636187582c aaeb3ffc5ce074ddea6a16e5b28788f73b1fd12c also unnecessary, which to be honest, seems appealing to me at least from a review perspective, given the number of new classes and interfaces.
Of course, we might need them later and could be useful to keep them around, but then it would be nice to have it done more gradually if possible.
Regarding 04ee932ff5e261b9aceee47542f91aa6b4f115c1, and for similar changes, it'd be nice to make smaller additions, for instance adding one interface definition at a time (and its dependencies if they aren't too much, or add them beforehand), so that reviewing what needs what is easier.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2386#note_26841
--
v4: winex11: Remove now unnecessary user locale change checks.
win32u: Prevent user locale change in NtUserActivateKeyboardLayout.
win32u: Keep the current user locale when loading layout.
win32u: Keep the current user locale when enumerating layouts.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2355
After this and the related MRs, MS Office 365 finally loads. We see the fancy start screen, and we need modify the options to trust the folder we have our Word documents in. This works for `WINWORD.EXE`, `EXCEL.EXE` and `POWERPNT.exe`. I am able to open an existing file and view it.
This MR is limited to showing the first page or so of the Word document. It freezes with the Wine crash dialog basically the moment right after the screen is rendered. There is no backtrace in the dialog, but winedbg points to `v8jsi.dll` and so does the console output without winedbg. Creating new documents is not achieved by this MR either.
--
v5: Sleep forever in SLOpen.
Add SLGetApplicationPolicy stub.
Add SLLoadApplicationPolicies stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2377
This fixes a crash in `OneDriveSetup.exe`. It still doesn't install with "A supported version of Windows 10 or Windows 11 is required to proceed," but at least it doesn't crash. After this patch, we can now see the OneDrive logo, the progress bar, and the "Installing OneDrive" label.
--
v2: wofutil: Stub WofIsExternalFile().
https://gitlab.winehq.org/wine/wine/-/merge_requests/2375
After this and the related MRs, MS Office 365 finally loads. We see the fancy start screen, and we need modify the options to trust the folder we have our Word documents in. This works for `WINWORD.EXE`, `EXCEL.EXE` and `POWERPNT.exe`. I am able to open an existing file and view it.
This MR is limited to showing the first page or so of the Word document. It freezes with the Wine crash dialog basically the moment right after the screen is rendered. There is no backtrace in the dialog, but winedbg points to `v8jsi.dll` and so does the console output without winedbg. Creating new documents is not achieved by this MR either.
--
v4: sppc: Add stubs for MS Office.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2377
With this MR, now I can create documents in Word. Applied together with my other patches, we will have the 3 main apps of Microsoft Office working!
--
v2: windows.networking: Stub DllGetActivationFactory().
https://gitlab.winehq.org/wine/wine/-/merge_requests/2379