The practical issue I am trying to solve is the following scenario (encountered with a game using some Uplay plugin) which has regressed with apisets implementation in Wine. The game imports ucrtbase.dll. Then, a plugin calls GetModuleHandle("api-ms-win-crt-runtime-l1-1-0.dll") and expects GetProcAddress("\_crt_atexit") to succeed on the returned handle. The problem is that the game has ucrtbase.dll in its .exe directory. That one currently gets loaded. Then, find_dll_file() resolves api-ms-win-crt-runtime-l1-1-0.dll to the ucrtbase with a full path in system32 and tries to find that one (this part matches Windows behaviour as far as tests show). Since we have ucrtbase loaded with another path this results in NULL module handle.
Windows maintains the list of "Known DLLs" (probably aimed for speeding up processes startup by using pre-mapped dll images for commonly used system dlls). On Windows, known dlls have specifics in load path resolution when dll name doesn't contain path (relative or full):
- they are loaded from system directory even if there is another dll with the same name in priority search path;
- they are found even if library search paths do not contain system directory;
Those "Known DLLs" are basically listed in HKLM\\System\\CurrentControlSet\\Control\\Session Manager\KnownDLLs registry key. But the actual list of "known dlls" is bigger (probably includes all dependencies of those listed under registry key). The full actual list of "known dlls" is in '\\KnownDlls\' directory object which contains image sections under dll names. Most notably, ucrtbase.dll (which is of the concern in the regression) is not listed in registry but is present in \\KnownDlls. Technically nothing prevents us from implementing these mechanics and creating directory object with mapped load dlls, also resolving the explicitly listed dlls' dependencies. But it is not apparent to me if that is going to improve load times noticably in Wine, and also that is worth the inherent complications until anything actually depends on that \\KnownDlls sections. So instead of implementing all of that throughout the loader I added a few missing dlls to registry. The current list in this pat
chset corresponds to the contents of \\KnownDlls directory on an up to date Windows 10.
--
v4: ntdll: Load known dlls from system directory.
loader/wine.inf: Add known dlls key.
ntdll: Factor out prepend_system_dir() function.
kernel32/tests: Add tests for known dlls load specifics.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2127
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54194
If the SendMessageTimeout call takes a long time, we can get other
messages which also set the observed wparam value. Apparently,
this is especially likely on Windows 7.
This also removes the (wParam == 0xbaadbeef) check which may have
been intended to serve the same goal but doesn't work because the
observed wParam value is still assigned.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3862
As shown by the testbot, doubling is not always sufficient.
--
v2: iphlpapi/tests: Call GetExtendedTcp/UdpTable() in a loop.
iphlpapi/tests: Call GetAdaptersAddresses() in a loop.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3833
Changing the colour of the second pixel of the source bitmap clarifies
the incorrect behaviour of PixelOffsetMode Half and HighQuality.
This also provides better proof that PixelOffsetMode None and Fast are
implemented correctly.
Extending tests is starting point for further
improvements of implementation pixel offset modes
to match implementation from native gdiplus.
--
v2: gdiplus/tests: Extend DrawImage scaling tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3774
--
v4: dmsynth/tests: Test DirectMusicSynth class in isolation.
dmsynth/tests: Test DirectMusicSynthSink class in isolation.
dmsynth/tests: Import and use a check_interface helper.
dmsynth/tests: Avoid dynamic format string.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3675
The problem is that registry save is a very heavy operation (scheduled each 30sec in wineserver) during which server doesn't process any requests and the whole prefix is stalled for the duration of the operation.
For some reference, the process takes from 50-100ms here up to 1-1.5sec with default initial registry (after some registry modifications which trigger actual registry flush), depending on the filesystem type and state (as huge time may be spent in file close / rename). With the same registry after this patchset the server part (flush_key returning the whole registry data) is taking ~4-5mcs, measured from the client side so that already includes data transfer.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3124
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>
--
v2: winex11.drv: optimize repeated ClipCursor calls
winex11.drv: create win32 clipping window only once
https://gitlab.winehq.org/wine/wine/-/merge_requests/825
This simplifies future tests that check for object name of devices.
--
v2: server: Fix object name resolution of \Device\Null.
server: Make explicit the ownership of the unix_name buffer.
https://gitlab.winehq.org/wine/wine/-/merge_requests/475
--
v2: d2d1: Implement nodes connection for ID2D1TransformGraph.
d2d1: Implement nodes adding and removal for ID2D1TransformGraph.
d2d1/tests: Add more tests for ID2D1TransformGraph.
https://gitlab.winehq.org/wine/wine/-/merge_requests/698
Every other use of `EDIT_EM_SetSel` updates caret position by calling `EDIT_EM_ScrollCaret` or `EDIT_SetCaretPos`.
Fixes caret blinking in the middle when selecting all text.

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3226
The reference count of host is supposed to go up by one in netconn_create.
The missing ref increment causes error handling paths
where netconn_close or release_host is called
to prematurely decrement the ref count of host to zero.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1121
Fixes balloon tooltips so that they can be drawn outside of the work area (required for system tray icons) and improves the shape of the tooltips so that they resemble their shape on Windows.
--
v4: Diff reduce
https://gitlab.winehq.org/wine/wine/-/merge_requests/3547
I haven't seen any software that uses this, but some older software out there might use it, so it's good idea to export it.
--
v5: ntoskrnl.exe: add KeNumberProcessors export.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1139
Some games with support for the haptic feedback and speaker features of the Sony DualSense controller select the controller's audio output by filtering on the ContainerId IMMDevice property to find one that matches the controller's HID's. This MR allows this information to be accessible from the IMMDevice's property store when the audio driver provides it (none for now, but I intend to add that feature to `winepulse.drv` and maybe `winealsa.drv`)
This is made specific to containerId rather than supporting VT_CLSID on every property because Wine currently stores VT_BLOBs directly in the registry value, which does not allow us to safely disambiguate between VT_CLSID and VT_BLOB values when reading from registry.
--
v7: mmdevapi: Invalidate ContainerID of unavailable audio devices.
https://gitlab.winehq.org/wine/wine/-/merge_requests/359
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v19: include: Add a comment explaining why all kernel callbacks must be in user32.
user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
wineandroid.drv: Route kernel callbacks through user32.
opengl32: Route kernel callbacks through user32.
winevulkan: Route kernel callbacks through user32.
user32: Add NtUserDispatchCallback kernel callback.
user.exe16: Move kernel callbacks to wow_callbacks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
General idea of this test is to show that a lot of factors influence the fog when transformed and untransformed vertex format was used:
- Directly changing z and w (which is not equal in the corners).
- Changing projection matrix that change z and w.
- Using different programmable/ff vs/ps shader.
- Using different depth bias.
- Chaging depth in pixel shader (oDepth) may or may not affect to colors depending on the vendor implementation.
- And various combinations of above.
This gives `succ` in all cases on this configs:
- Windows 10 with Radeon HD 8400 or Ivy Bridge GT1 (Intel HD Graphics).
- Windows 7 with Radeon HD 6450.
- Windows XP with GeForce Go 7300.
--
v2: d3d9/tests: test table fog z vs rhw with shaders, depth bias, oDepth..
https://gitlab.winehq.org/wine/wine/-/merge_requests/2657
This is the first batch of a series implementing faster media source resolution required to workaround an Unreal Engine race condition present in some games, and deterministic stream ordering that decodebin / parsebin cannot provide, which is required to expose the streams in native order, for compatibility in several other applications.
I pushed the full series as a branch here: https://gitlab.winehq.org/rbernon/wine/-/commits/mr/wg-source-part-one
Note that this full series is also a first step in the direction of having a simpler demuxer interface, which will be required in the future for compatibility with applications that build MF or DirectShow pipelines directly and expect the relevant components to behave as a demuxer and expose compressed media types. For now it only delays the use of wg_parser to whenever the media source is started, and matches the non-ordered streams using their media types and tags. This is a best effort solution but I don't think we can do much better for the moment.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3606
This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man…
Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them?
--
v4: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
user32: Add tests for WM_INPUT_DEVICE_CHANGE messages
https://gitlab.winehq.org/wine/wine/-/merge_requests/2120
This avoids one case of spurious wakeup of WaitOnAddress (which could be triggered by prior race on consequent WakeAddressAll and a thread trying to wake on that, leaving the waking thread in an alerted state). And fixes Resident Evil games randomly crashing due to unhandled spurious SleepConditionVariableCS wakeups.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3929