The game "Marvel Heroes" uses AES for some session validation on login. It uses `CryptImportKey` to configure the key, but this fails in Wine (see for example the documentation of MHServerEmu: https://github.com/Crypto137/MHServerEmu/blob/f250fbd8d62a8d18afa6592e39058…) because it leaves garbage(?) data in the reserved field of the key blob header. This is ignored on Windows (tested on Windows 10, but seems to be the same on other Windows versions, since the game runs without problem), but Wine verifies this value and exits early. This removes the check and adds a barebones test to verify this behavior.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7744
--
v8: win32u: Properly scale monitor work area when emulate_modeset is enabled.
win32u: Use a more fitting name for a helper function.
win32u: Check against the monitor work area in update_maximized_pos().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7708
--
v7: win32u: Properly scale monitor work area when emulate_modeset is enabled.
win32u: Use a more fitting name for a helper function.
win32u: Check against the monitor work area in update_maximized_pos().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7708
This implements handling of HTTP status code 308 ([Permanant Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Statu…) in wininet/winhttp. I added handling at all places I could find, but could only test the one in `dlls/wininet/http.c` with the program where it failed (Marvel Heroes).
I tried to keep the implementation parallel to 307, since they serve a similar purpose (redirect while keeping the request intact).
PS: `case` labels are sometimes in different order, would it be a good idea to sort them in numerical HTTP status order while I'm at it?
--
v3: urlmon: Handle HTTP status code 308 (Permanent Redirect)
winhttp: Handle HTTP status code 308 (Permanent Redirect)
wininet: Handle HTTP status code 308 (Permanent Redirect)
https://gitlab.winehq.org/wine/wine/-/merge_requests/7735
--
v6: win32u: Properly scale monitor work area when emulate_modeset is enabled.
win32u: Use a more fitting name for a helper function.
win32u: Check against the monitor work area in update_maximized_pos().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7708
These functions are used by Visual Studio 2019, when opening or converting some projects.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v19: kernelbase: Check for PERF_SIZE_LARGE in PerfSetULongLongCounterValue and PerfSetULongCounterValue
kernelbase : Check for PERF_ATTRIB_BY_REFERENCE attribute in PerfSetCounterRefValue
advapi32/test: Add Test For PerfSetULongLongCounterValue
advapi32/tests: Create Tests for PerfSetULongCounterValue.
advapi32: Forward PerfSetULongCounterValue and PerfSetULongLongCounterValue to kernelbase
kernelbase: Add implementation for PerfSetULongLongCounterValue
kernelbase: Add implementation of PerfSetULongCounterValue
kernelbase: factor out common functionality for performance counter functions
https://gitlab.winehq.org/wine/wine/-/merge_requests/3799
Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
v23: ntdll: main_envp has been replaced by environ
ntdll: remove is_dynamic_env_var(...) because it is not needed anymore
ntdll: remove unused vars
ntdll: remove dead code
ntdll: conversion from HOSTENV to WINENV is now using whitelisting instead of blacklisting of envvars currently only envvars "WINE"<special_var> (as defined in is_special_env_var() ) are whitelisted.
ntdll: separate env for windows applications (WINENV) from env for wine processes (NIXENV) WINENV is typically limited to 32767 WCHAR, the host environment where wine processes are running can be much larger. Keeping the two envs separate enables a more granula handling of envvars. (see also MR!5231, MR!6140, bug #56941)
https://gitlab.winehq.org/wine/wine/-/merge_requests/6166
Commit b1b5105ceb moved the following block
#ifdef AT_HWCAP2
if (getauxval( AT_HWCAP2 ) & 2) syscall_flags |= SYSCALL_HAVE_WRFSGSBASE;
#endif
out of an #ifdef __linux__ block and it now causes failures on FreeBSD
and others which do not have getauxval. Guard this invocation properly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7754
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: windowscodecs/tests: Use wide-char literals in metadata tests.
windowscodecs/tests: Remove redundant string length check for VT_LPSTR metadata value.
windowscodecs/tests: Add line context to the metadata comparison helper.
windowscodecs/tests: Add some tests for bKGD chunk.
windowscodecs/tests: Add more tests for the item id handling.
windowscodecs/tests: Add some tests for initial metadata readers content.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7741
Reported-By: Alexander Leithner <aleithner(a)level101.at>
Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de>
--
v2: configure.ac: avoid problems with -Werror=return-type in check
https://gitlab.winehq.org/wine/wine/-/merge_requests/7753
Implementation and test function for ADsBuildVarArrayInt, using ADsBuildVarArrayStr as reference.
- /dlls/activeds/activeds_main.c
- /dlls/activeds/tests/activeds.c
- /include/adshlp.h
--
v3: activeds/tests: enable
https://gitlab.winehq.org/wine/wine/-/merge_requests/7752
Implementation and test function for ADsBuildVarArrayInt, using ADsBuildVarArrayStr as reference.
- /dlls/activeds/activeds_main.c
- /dlls/activeds/tests/activeds.c
- /include/adshlp.h
--
v2: activeds/tests: consistent types
https://gitlab.winehq.org/wine/wine/-/merge_requests/7752
Implementation and test function for ADsBuildVarArrayInt, using ADsBuildVarArrayStr as reference.
- /dlls/activeds/activeds_main.c
- /dlls/activeds/tests/activeds.c
- /include/adshlp.h
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7752
Wine starts processes non-elevated since e92ba2de43d7afbe0704b11b29f7c30f44dfaeca
but some installers exit prematurely when not elevated.
The elevation mechanism is taken from 8cc22a60c304fc1398fab1ce8413b2b81fc2ccec.
Would this be an acceptable extension?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7751
A standard CD-ROM has up to 360,000 sectors that hold 2 KiB of data
each, making the total capcity 703.125 MiB. Anything larger than that is
almost certainly a DVD or a Blu-ray, and Windows does not distinguish
between those two.
There is probably some tiny DVD somewhere in the world that will still
be misdetected, but I'm not sure that issuing SCSI commands to the drive
to try to determine the disc type would be any more reliable.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57790
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7747
On Fri Apr 4 21:07:44 2025 +0000, Paul Gofman wrote:
> Yes, it seems to be using it (while that worked for me without
> CM_Get_Parent at least with some controllers).
> CM_Get_Parent() per se is easy to implement, but to make any sense of it
> the first thing is that the actual HID drivers (or ntoskrnl rather,
> maybe) should be setting DEVPKEY_Device_Parent property. But also before
> that, as I understand, currently Wine HID stack ends in xinput or SDL
> backends and not in USD or Bluetooth Wine driver, that is probably the
> major thing here. I think the linked hidapi library code only hits
> CM_Get_Parent() in hid_internal_detect_bus_type() and failure there
> results in HID_API_BUS_UNKNOWN, which doesn't fail the whole thing but
> misses some properties.
Maybe in theory those backends may expose device properties to partially mimic USB or BTH devices and make this library fully happy, but I am not sure, didn't really look into that part.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7727#note_100024
On Fri Apr 4 20:22:39 2025 +0000, Ivo Ivanov wrote:
> They probably use "hidapi" to communicate with hid devices:
> https://github.com/libusb/hidapi/blob/8c9cbf6c020974d23e4690497778f3df173d1…
> The Simucube Tuner app, which is used to control Simucube 2 FFB wheel
> bases, is also affected by this. Seems the usblib devs have switched
> from setupapi to cfgmgr32 in the recent years, and now this is starting
> to appear in games/apps. Looks like only CM_Get_Parent remains to be implemented.
> BTW, Steam shows a similar usage pattern of these apis in the logs, so
> it probably uses hidapi as well.
Yes, it seems to be using it (while that worked for me without CM_Get_Parent at least with some controllers).
CM_Get_Parent() per se is easy to implement, but to make any sense of it the first thing is that the actual HID drivers (or ntoskrnl rather, maybe) should be setting DEVPKEY_Device_Parent property. But also before that, as I understand, currently Wine HID stack ends in xinput or SDL backends and not in USD or Bluetooth Wine driver, that is probably the major thing here. I think the linked hidapi library code only hits CM_Get_Parent() in hid_internal_detect_bus_type() and failure there results in HID_API_BUS_UNKNOWN, which doesn't fail the whole thing but misses some properties.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7727#note_100023
On Fri Apr 4 20:22:39 2025 +0000, Paul Gofman wrote:
> Fixes MySims Kingdom not working with controllers.
> WRT the last patch, we don't set any properties for devicee interfaces
> currently. I could not find device id in the properties subkeys for
> device interfaces on Windows (as well as any properties, actually,
> across a few interfaces I checked). So I guess even we will be adding
> properties for device interfaces device instance id will be treated as a
> special case anyway. DEVPKEY_Device_InstanceId is the only property
> which this specific game queries with
> CM_Get_Device_Interface_PropertyW(), so I don't have a real world
> example of any other been used.
They probably use "hidapi" to communicate with hid devices:
https://github.com/libusb/hidapi/blob/8c9cbf6c020974d23e4690497778f3df173d1…
The Simucube Tuner app, which is used to control Simucube 2 FFB wheel bases, is also affected by this. Seems the usblib devs have switched from setupapi to cfgmgr32 in the recent years, and now this is starting to appear in games/apps. Looks like only CM_Get_Parent remains to be implemented.
BTW, Steam shows a similar usage pattern of these apis in the logs, so it probably uses hidapi as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7727#note_100022
This is part XXIX of the rewrite of cmd engine.
It's time to tackle the lexer...
So far, I left it mainly untouched. As it's a &#:!\_%% piece of code.
It maintains (or actually tries to maintain) a state machine with a dozen
of boolean variables. Which makes the code quickly unreadable...
Not speaking of changing it...
[ Exercice for the reader: think of the boolean variables as a set of ]
[ binary digits, which is the base two representation of the state number. ]
[ Rewrite the code using a single state number in order to get rid of ]
[ all the boolean variables. ]
[ -- Good luck. -- ]
There's a small amount of known bugs in the lexer (some in bugzilla, some
I got from direct reports -- thanks Hans --, others from local testings).
This is the first MR (out of 3) to go for that lexer rewrite.
Basically, it's done with:
- reusing the already parsed token stack to get back to the state for lexer,
- reducing leaves directly (tokens for which we can from first character(s)
work on end condition) instead of handling every character in the state
machine,
- factorizing (eg end of line was handled at two different places,
needless to say there "slight" differences in the two parts).
The good news: LoC for lexer (after third MR) is reduced by 30% and fixes
most of bugzilla entries related to cmd's lexer.
The bad news: wait for bug reports.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7742
Match the behavior on Windows: When the CryptUIWizImport function is
called, the "Certificate store" textbox initially says "Determined by
the program" instead of having the specific name of the store passed to
the function. When the user clicks Browse to select a store, the stores
are listed by localized name. After clicking OK, the selected store's
localized name is copied into the textbox.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58057
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7738
For some reason I thought it wasn't needed anymore (I had it initially), sorry for the mess up.
--
v2: jscript: Don't leak when return value of host constructor is not used.
jscript: Don't leak when popping (u)int values off the stack.
mshtml: Don't mess with the outer window if we're already detached.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7737
Sending key events through `-[NSTextInputContext handleEvent:]`, as we do in `macdrv_send_text_input_event`, results in doubled characters for certain macOS input sources. The Romaji source does this reliably, as do certain third-party sources. (The built-in dictation does it as well, but we already blacklist that - !5660 - because it remains "active" even when it's not.)
I can't find this spelled out directly, but if you read between the lines, it seems clear that you're only supposed to send key *down* events to `-[NSTextInputContext handleEvent:]` and not key ups. Supporting evidence:
1. [The old documentation on the text system](https://developer.apple.com/library/archive/documentation/TextFonts… only mentions `handleEvent:` being called in the context of `-keyDown:`.
2. [The guide to implementing a custom text view/NSTextInputClient](https://developer.apple.com/library/archive/documen… only mentions overriding `-keyDown:` and sending those events to `-handleEvent:`.
3. [iTerm only sends key down events to `-handleEvent:`](https://github.com/gnachman/iTerm2/blob/6134ea0a9d9d0fee5e7d7704fc98efec1fc77c24/sources/iTermKeyboardHandler.m#L355). You have to unpack the logic a bit from there, but `-handleKeyDownEvent:...` is the only method that calls `-handleEventWithCocoa:inputContext:`, which is what (usually) calls `-handleEvent:` on the `inputContext`.
4. [The InputMethodKit method on the IMKServerInput protocol to handle NSEvents directly](https://developer.apple.com/documentation/objectivec/nsobject/138… only mentions getting key down events.
So presumably input source authors sometimes do not check the type of the NSEvent they're receiving and process all key events equally, be they downs or ups, which results in the doubled input.
This patch fixes the issues with Romaji and the problematic third-party method we've encountered.
--
v2: winemac.drv: Only send key down events to the window's inputContext.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7701
create_dest_file was unaware of the `FILE_SHARE_READ | FILE_SHARE_DELETE` share mode that these SessionMgr entries are opened with. This avoids noisy `(error=80)` messages during prefix creation/update.
Fixes: 81ea1e7a20c9cd0698c0416282d9ad7c0109e865
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7705
This implements handling of HTTP status code 308 ([Permanant Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Statu…) in wininet/winhttp. I added handling at all places I could find, but could only test the one in `dlls/wininet/http.c` with the program where it failed (Marvel Heroes).
I tried to keep the implementation parallel to 307, since they serve a similar purpose (redirect while keeping the request intact).
PS: `case` labels are sometimes in different order, would it be a good idea to sort them in numerical HTTP status order while I'm at it?
--
v2: urlmon: Handle HTTP status code 308 (Permanent Redirect)
winhttp: Handle HTTP status code 308 (Permanent Redirect)
wininet: Handle HTTP status code 308 (Permanent Redirect)
https://gitlab.winehq.org/wine/wine/-/merge_requests/7735
This serie mainly moves line information for top level function
(not including the inlined parts) into the new PDB reader.
In details:
- cleaning up current internal private structure for line information
(in order to share it with PDB backend)
- introduce methods to get line info from address, move to next/prev
location, enumeration of line numbers and source files.
Note for source files enumeration:
- current implementation still needs some more fixes (no full scoping,
but that's unrelated to PDB rewrite)
- fixes by module scoping
- it still uses the global source hash table (as there isn't one
in PDB). No plan to improve that for now.
--
v2: dbghelp: No longer store line information from old PDB reader.
dbghelp: Add method to enumerate source files.
dbghelp: Introduce method to enumerate line numbers.
dbghelp: Introduce method to get next/prev line information.
dbghelp: Introduce interface for line info access.
dbghelp: Always copy the source file string.
dbghelp: Rename struct internal_line into lineinfo.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7698
This implements handling of HTTP status code 308 ([Permanant Redirect](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Statu…) in wininet/winhttp. I added handling at all places I could find, but could only test the one in `dlls/wininet/http.c` with the program where it failed (Marvel Heroes).
I tried to keep the implementation parallel to 307, since they serve a similar purpose (redirect while keeping the request intact).
PS: `case` labels are sometimes in different order, would it be a good idea to sort them in numerical HTTP status order while I'm at it?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7735
Sending key events through `-[NSTextInputContext handleEvent:]`, as we do in `macdrv_send_text_input_event`, results in doubled characters for certain macOS input sources. The Romaji source does this reliably, as do certain third-party sources. (The built-in dictation does it as well, but we already blacklist that - !5660 - because it remains "active" even when it's not.)
I can't find this spelled out directly, but if you read between the lines, it seems clear that you're only supposed to send key *down* events to `-[NSTextInputContext handleEvent:]`, and not key ups. Supporting evidence:
1. [The old documentation on the text system](https://developer.apple.com/library/archive/documentation/TextFonts… only mentions `handleEvent:` being called in the context of `-keyDown:`.
2. [The guide to implementing a custom text view/NSTextInputClient](https://developer.apple.com/library/archive/documen… only mentions overriding `-keyDown:` and sending those events to `-handleEvent:`.
3. [iTerm only sends key down events to `-handleEvent:`](https://github.com/gnachman/iTerm2/blob/6134ea0a9d9d0fee5e7d7704fc98efec1fc77c24/sources/iTermKeyboardHandler.m#L355). You have to unpack the logic a bit from there, but `-handleKeyDownEvent:...` is the only method that calls `-handleEventWithCocoa:inputContext:`, which is what (usually) calls `-handleEvent:` on the `inputContext`.
4. [The InputMethodKit method on the IMKServerInput protocol to handle NSEvents directly](https://developer.apple.com/documentation/objectivec/nsobject/138… only mentions getting key down events.
So presumably input source authors sometimes do not check the type of the NSEvent they're receiving and process all key events equally, be they downs or ups.
This change fixes doubled input with Romaji and the problematic third-party method we've encountered.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7701
This serie mainly moves line information for top level function
(not including the inlined parts) into the new PDB reader.
In details:
- cleaning up current internal private structure for line information
(in order to share it with PDB backend)
- introduce methods to get line info from address, move to next/prev
location, enumeration of line numbers and source files.
Note for source files enumeration:
- current implementation still needs some more fixes (no full scoping,
but that's unrelated to PDB rewrite)
- fixes by module scoping
- it still uses the global source hash table (as there isn't one
in PDB). No plan to improve that for now.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7698
--
v3: comctl32/tests: Test MSAA events for SysLink.
comctl32/tests: Test SetWindowText and LM_GETITEM for SysLink.
comctl32/tests: Test accLocation values on SysLink control.
comctl32: Implement accDoDefaultAction for SysLink controls.
comctl32/tests: Add test for SysLink accDoDefaultAction.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7618