Description:
When flags does not include DT_CALCRECT, since len is calculated in the middle,
it will be reduced to zero. Resulting in the length of the processed string that
is finally returned to zero and the non-processing string length is unchanged.
But some application taking the non-processing string length to zero as the loop
end condition.
Log:
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: Icc0f250f5f4faba1bee8326fc911a4fc9cd7c012
--
v6: user32: Fix the number of characters processed by DrawTextExW.
user32/tests: Add tests for DrawTextExW.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4812
Wayland has 3 types of scrolling events:
- axis. Used for e.g., touchpad 2 finger smooth scrolling
- axis_discrete. Used for mouse scroll wheels (i.e., notches)
- axis_value120. Used for high resolution input devices
Wine currently only supports axis_discrete, meaning that
2 finger scroll events get ignored.
This commit tries to add basic support for axis scrolling events,
by translating the smooth motion in scroll increments using some
primitive assumptions about line height and number of lines to scroll.
--
v11: wip! winewayland.drv: Try to support smooth scroll events
https://gitlab.winehq.org/wine/wine/-/merge_requests/4809
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
Description: The printing function (non-Windows application call) used by Wine developers
is unnecessary to abort process when the string is super long. For example, the developer
prints a long commandline of wwmapp.exe by MESSAGE. As a result, the process cannot be
started, and the conference function cannot be used.
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: If06f0309f9745777f89b07dff8d302cb34b2a90e
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4635
Not really needed for 16k pages, but since the comment says "one page" the logic should reflect that.
Not 100% sure about that since I don't know why it should use exactly one page, so please double check.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4740
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are not fully supported by this patch, matching the behavior of Windows.
--
v67: ws2_32/tests: Add test for AF_UNIX sockets.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
My hardware is Ryzen 7 4700u with the integrated graphics
Flatout (Direct3D 9): 20 fps (renders correctly)
Unigine Heaven (OpenGL): ~40-60 fps (renders correctly)
Unigine Heaven (Direct3D 9): 20-30 fps (renders correctly)
Unigine Heaven (Direct3D 11): 20-30 fps as well (renders correctly)
Elder Scrolls IV (Direct3D 9): 20 fps (renders correctly)
BeamNG Tech Demo 0.3 (Direct3D 9): 2 fps (renders correctly, but still runs poorly)
Massive step up from getting 2 fps across many wined3d games, but it's still pretty bad, ~~and sometimes runs worse than the original code~~. Now with a combination of using the new and old code dynamically you can get the best of both worlds!
Unfortunately, we lose the ability to get lucky with the mapping just happening to be in the 32 bit range.
--
v7: opengl32: speed up wow64 mapping.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5145
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
This WIP branch prototypes the usage of virtual display devices (through "virtual desktop" mode at the moment) to support display mode emulation in the Wayland driver.
It works by allowing the driver to mark each host adapter with a virtual_id, which, if present, signals to win32u that it should include the adapter in the virtual display configuration. The virtual configuration (along with the virtual ids) is reported back to the driver though a new user driver function. If none of the host adapters is marked with a virtual id (i.e., all other drivers) we fall back to the single virtual display mode as before.
Some deficiencies and open questions with the prototype:
1. Virtual desktop mode implies a lot of behavior that we don't want at this point the Wayland driver (e.g., taskbar window, changing the display mode to the virtual desktop resolution at startup, some changes in fsclip behavior). One way forward would be to have a "virtual display devices" mode separate from the "virtual desktop" mode, so that drivers can opt in only to the desired behavior (virtual desktop would imply virtual devices, to maintain the current behavior).
2. It's not clear to me what would be the best way for a driver to opt in or out of certain core behavior. Perhaps the driver would change some volatile registry key which other components would consult? Or introduce a user driver function for core to query the driver about such features on demand? Is there some precedence I can get inspiration from?
3. At the moment, the prototype calls the new "NotifyVirtualDevices" user driver callback only in the process which the display update occurred. This means that other processes don't get notified of the virtual devices mapping to host devices, so, in the Wayland driver case, we are not able to scale windows from those processes properly. One approach would be for core to ensure that the NotifyVirtualDevices callback is called once in all processes, but I am not sure what's the best way to achieve this (or even if this is the preferred approach). Another way would be to have a mechanism for the driver to query the virtual device info (+mappings) on demand, and just broadcast a message to all windows. In this case it could even be done internally by the driver (so more in line with what the part-12 MR is doing), if we don't want to introduce a more global behavior. Perhaps there is some even better mechanism, which would also be more fitting to how we envision the virtual display/devic
es to evolve going forward.
Let me know what you think!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5057
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
This resolves the issue in StudioTax where the bounding box dimensions is reported as 0.
Because the height is less than 0, the check for height in GdipAddPathRectangle fails,
and the X and Y coordinates of the points is never set.
I am fairly ignorant of this code, this seems like a good approach, however I am happy for guidance from others more familiar in how gdiplus works.
--
v3: gdiplus: Fix text height calculation when exceeding rect
gdiplus: Check for NoClip in text height calculation
https://gitlab.winehq.org/wine/wine/-/merge_requests/5360
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
Recent changes allowed the Wayland driver to properly deal with numpad keys depending on numlock status. This MR ensures that numlock and other lock state is properly synced, and concludes the fix for https://bugs.winehq.org/show_bug.cgi?id=56397.
This MR also syncs the key press state when a window gains keyboard focus, including any modifier press state. Note that we currently ignore the modifier press information from the `modifier` event, since: 1. it doesn't differentiate between left-right keys, 2. mod press state changes will be normally preceded by a matching key event, so we are able to sync properly. However, if we find that we need to handle mod press state changes without corresponding key events, we will need to implement some sensible way to sync these, too.
Although I would like for the driver work exclusively in terms of scancodes, I still needed to use vkeys in this case, since this is how wineserver expresses keyboard state at the moment. This means that I had to introduce/duplicate some extra scan->vkey logic in the driver (e.g., numpad keys based on numlock state) to get things right.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5712
--
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
--
v2: jscript: Implement Uint8ClampedArray.
jscript: Implement 'set' for Typed Arrays.
jscript: Implement 'subarray' for Typed Arrays.
jscript: Implement Typed Array construction from objects.
jscript: Implement ArrayBuffer.isView.
jscript: Implement Typed Array construction on ArrayBuffers.
jscript: Add initial implementation of Typed Arrays.
jscript: Use DISP_E_UNKNOWNNAME when looking up a prop that doesn't exist.
jscript: Avoid allocating props for indexed props unless necessary.
jscript: Move the indexed prop idx lookup into a helper.
mshtml/tests: Test redefining a writable indexed prop.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5085
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
This MR implements `NtContinueEx(PCONTEXT, PCONTINUE_OPTIONS)` which was added in Windows 10 20H1.
Also added basic test reusing existing `test_continue()` (included from !4720)
League of Legends game hooks `NtContinue()` and `NtContinueEx()` by putting `jmp` instruction in front of it.
Note that LoL doesn't actually use `NtContinueEx()` itself and game will work fine without it but if game doesn't find `NtContinueEx()` it will permanently ban your account due to detecting "scripting program"
--
v6: ntdll/tests: Implement APC test for NtContinue()
ntdll/tests: Add basic test for NtContinueEx()
ntdll: Implement NtContinueEx()
https://gitlab.winehq.org/wine/wine/-/merge_requests/4761
The "GdiInterop" is a sample application (source code is avaiable in [Github][source_code], relative guide in [MSDN][msdn_guide]) that demostracts how to display DirectWrite text on a GDI surface. After set dpi to 168 in `winecfg`, and run sample application with wine, the font size is normal, but the position of glyph is incorrect.
| Dpi: 96 | Dpi: 168 |
|:----------------:|:-----------------:|
| ![ss1][sc_96dpi] | ![ss2][sc_168dpi] |
There is the sample application after compile: [Release_x64.tar.gz](/uploads/c70e32824efcaa5d16ab39bbb4b86e30/Release_x64.tar.gz)
After change transform matrix that pass to `IDWriteFactory7_CreateGlyphRunAnalysis`, it can display glyph correctly.
[source_code]: https://github.com/microsoft/Windows-classic-samples/blob/main/Samples/Win7…
[msdn_guide]: https://learn.microsoft.com/en-us/windows/win32/directwrite/render-to-a-gdi…
[sc_96dpi]: /uploads/59cc343cfaa025f4ff4c32a84ab8cfeb/图片.png
[sc_168dpi]: /uploads/938be653362bb6ac58471b69ab66099a/图片.png
--
v5: dwrite: Fix incorrect position of glyph when rendering with BitmapRenderTarget in HiDPI
dwrite: Return render bounds if text not intersect to BitmapRenderTarget
https://gitlab.winehq.org/wine/wine/-/merge_requests/3718
The cast there seems safe from looking at the struct definitions, and is also used elsewhere in the codebase (dlls/kernelbase/locale.c:5682).
It's obviously not a full implementation, but works well enough for my usecase and maybe others as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4851
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
This MR uses the existing compositor side surface scaling in the driver (through wp_viewporter, currently used for Hi-DPI scaling) to emulate display mode changes. This works wonderfully in coordination with fullscreen since the compositor is required non only to scale the surface, but also to position it properly and provide opaque surroundings (note: some compositors don't implement the last two features properly!).
Since: 1. Wayland doesn't allow clients to change the actual display configuration, and 2. there is no queryable service that holds the display information in a consistent manner (à la xrandr), the MR uses the win32 device settings as the source of truth for the current display mode. We let win32u handle the display mode change in the default manner (i.e., just updating the registry settings), and provide access to the current mode when updating the display devices through a new `gdi_display_manager.get_adapter()` function.
In order to be able to consistently (across all processes) associate an adapter device with its corresponding `wl_output` the MR introduces per-adapter driver data.
Note for people trying this out: many modern games don't change the hardware display settings, but rather scale themselves in right way to achieve the visual effect of a mode change (similarly to how this MR works, but they do it on the application side). To exercise most of the functionality in this MR you need an application that actually uses the `ChangeDisplaySettings` win32 API.
Thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4947
Added suppot for DXGI_FORMAT_R8G8B8A8_UNORM to d2d_wic_render_target_init. For further testing i can provide and .exe that renders a red circle over a blue background.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5925
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
I've tried implementing this before but importing user32 from ntdll isn't a reliable
thing (so I recently rewrote it using the ntdll equivalents of LoadLibrary() and GetProcAddress())
Note: This is a weird way to implement this function (Windows implements this
in ntdll instead) but that would probably require a user32/ntdll rewrite (so this
is the next best tning to get the application working)
--
v4: ntdll: Implement NtdllDefWindowProc_A().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5236
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
wow64: Add TokenIntegrityLevel surpport to wow64_NtSetInformationToken as NtSetInformationToken does.
Description: synchronize wow64_NtSetInformationToken and
NtSetInformationToken.Avoid crash of some application due
to TokenIntegrityLevel failure in wow64 mode.
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
Change-Id: I556ab5cc6531dfab2c404e6769e053f42ada70a7
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5440
musl itself expects to be configured to compile with either
-ffloat-store or -fexcess-precision=standard - but when imported
into Wine, those flags aren't used.
This seems to be essential for getting reasonable precision
from some math functions such as exp2() - without the expected
precision truncation, the output value of exp2() can be off by
as much as 0.2% in some cases.
As Wine doesn't build the musl sources with those flags, use
volatile to force storing/reloading floats in order to limit
their intermediate precision, as musl expects. Only do this on
i386 where this is known be required.
This fixes https://bugs.winehq.org/show_bug.cgi?id=56372.
Apparently this issue only appears when compiled with GCC; with
Clang, this already works as expected.
Signed-off-by: Martin Storsjö <martin(a)martin.st>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5276
Some cleanup for expressions, sanitizing the structure a bit especially for abstract operations with multiple args.
I also found out about named bison variables, implicit (as `$token` referring to `token`), or explicit (as `$name` referring to `token[name]`). I think it would make the rules much more readable so I started using them here. My plan is to add them progressively to the rules, unless there's some good reason not to (like idk how portable they are, if that's something we should be worried about).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4201
I'm not completely sure about the mechanism, but I think it's simple enough to consider having that upstream now. This shows at least how we can leverage win32u surface changes to decide to switch surfaces on/off-screen and fallback to manual blitting.
Having the surfaces on-screen makes sure they are presented as efficiently as possible, having them off-screen we use GDI blit to indirectly call XCopyArea and this will be suboptimal, probably with visible tearing, but hopefully not too common.
--
v4: win32u: Use GDI blit to implement partial or other process presentation.
winex11: Return an offscreen HDC from vulkan_surface_detach.
win32u: Pass a HDC parameter to vulkan_surface_detach.
winex11: Create a window surface even when there is client window.
winex11: Also attach child client windows to their toplevel window.
win32u: Make sure vulkan windows have a pixel format selected.
win32u: Detach vulkan surfaces that aren't fully visible.
win32u: Detach offscreen, child or vulkan surfaces for another process.
win32u: Move vulkan surfaces to their new parent when reparenting.
win32u: Introduce a new vulkan offscreen surfaces list.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk>
--
v2: ntdll: Add support for FILE_{RENAME,LINK}_POSIX_SEMANTICS.
ntdll: Factor out get_inode_open_sharing.
ntdll/test: Add tests for FILE_LINK_POSIX_SEMANTICS.
ntdll/test: Add tests for FILE_RENAME_POSIX_SEMANTICS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4457
Adds the tray icons implementation based on org.kde.StatusNotifierItem interface usage. Does allow restarting StatusNotifierWatcher object, but will fallback to XEMBED or internal tray, if wine gets initialized when there is no StatusNotifierWatcher object registered.
--
v41: win32u: Handle dbus notification balloons from system_tray_call
win32u: Handle notification balloons through org.freedesktop.Notifications dbus interface
win32u: Add a ShowBalloon driver interface
win32u: Handle StatusNotifierItem management from system_tray_call
win32u: Handle StatusNotifierWatcher owner changing and registering objects to a new watcher
win32u: Add SNI driver for systray handling
win32u: Add DBus event loop for SNI handling
win32u: Add a SystrayRunLoop driver interface
https://gitlab.winehq.org/wine/wine/-/merge_requests/2808
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