Passing exact bounding rectangle from GdipMeasureString() to GdipDrawString() may currently result in nothing being rendered because gdip_format_string decides the string does not fit in the rectangle. The effectively considered width is a result of truncation of float rect->Width. Even without any transform or scaling in play, the float math performed on margin and width in GdipDrawString() is enough to introduce rounding error so that the truncation rounds to smaller integer while float value is very close to the next one.
As tests shows, Windows seems to do some rounding on the value. I bisected the epsilon value more precisely locally and it looks like it is very close to 0.005. The result is a bit biased with the current font size in test (probably due to some extra math and rounding on the way) but doubling font size yields 0.005 almost exactly.
Fixes text rendering in a game which randomly skips characters (in fact, most of them).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4416
A length of -1 has no special meaning for the mbsn*coll functions, and
since it is > INT_MAX, it will eventually trigger _invalid_parameter in
_strnicmp_l in newer versions of msvcrt.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4415
Current copy-prop of swizzle instructions can result in infinite loops,
as with the included test before this commit.
Consider the following sequence of instructions where a load is stored
in the same variable it loads:
1 : A
2 : A = @1
3 : @1.x
In this case @3 would call copy_propagation_get_value() on A.x and
would get @1, without detecting that that is indeed the same node
it is already using as swizzle->value. So it would return true,
keeping copy-prop spinning.
To avoid this, it is check that the replacement instruction is not the
same as the swizzle->load instruction.
---
This was discovered when trying to compile shaders from [Bug 19499](https://www.codeweavers.com/support/bugs/browse?cmd=bug_edit;bug_id=….
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/482
--
v8: vkd3d-shader/dxil: Implement the DXIL LOAD instruction.
vkd3d-shader/dxil: Implement the DXIL GEP instruction.
vkd3d-shader/dxil: Support global variable initialisers.
vkd3d-shader/dxil: Introduce a value type for immediate constant buffers.
vkd3d-shader/dxil: Implement default address space global variables.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/471
--
v3: Revert "vkd3d-shader/hlsl: Do not prioritize an exact match when looking up functions."
vkd3d-shader/hlsl: Discern between signed and unsigned ints when parsing.
tests: Test overloads with signed and unsigned numeric values.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/478
This is the first of (tentatively) 3 MRs that add Vulkan support to the Wayland driver. Here is the proposed breakdown:
* part 10.1 (this one): Basic setup and VkSurfaceKHR integration
* part 10.2: VkSwapchainKHR integration
* part 10.3: Everything else (mostly passthrough implementations of other Vulkan functions)
I chose to go with Vulkan first, instead of OpenGL, since the integration is more straightforward, and allows us to implement required core driver changes (which will also be used for OpenGL later) with fewer distractions.
Please note that all 3 parts need to land before the Vulkan support is actually usable in applications/games. I have uploaded the full (tentative) series for people that want to take a look or try out the final state: https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland-part-10
Finally, part 10 is not based on part 9, so they can land in either order. However, there are interactions and conflicts between the two, so whichever part lands last will need to be (slightly) adapted. Note, though, that without part 9, some things won't work well on scaled outputs (esp. fullscreen).
Thanks!
--
v2: winewayland.drv: Forward all client surface pointer events to parent.
winewayland.drv: Set client area subsurface size.
winewayland.drv: Set client area subsurface position.
winewayland.drv: Use a client area subsurface as the Vulkan target.
winewayland.drv: Implement vkDestroySurfaceKHR.
winewayland.drv: Implement vkCreateWin32SurfaceKHR.
winewayland.drv: Implement vkGetDeviceProcAddr and vkGetInstanceProcAddr.
winewayland.drv: Implement vkDestroyInstance.
winewayland.drv: Implement vkCreateInstance.
winewayland.drv: Implement vkEnumerateInstanceExtensionProperties.
winewayland.drv: Add skeleton Vulkan driver.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4340
--
v7: vkd3d-shader/dxil: Implement the DXIL LOAD instruction.
vkd3d-shader/dxil: Implement the DXIL GEP instruction.
vkd3d-shader/dxil: Support global variable initialisers.
vkd3d-shader/dxil: Introduce a value type for immediate constant buffers.
vkd3d-shader/dxil: Implement default address space global variables.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/471
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
--
v10: wineboot: Compute and write the TSC frequency to registry ~Mhz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
--
v8: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten structured control flow instructions.
vkd3d-shader: Rename shader_instruction_array_add_icb() to shader_instruction_array_add_opaque_param().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
If some Windows services stop while testing EnumServicesStatusW()'s
resume handle support, one possibility is that the still running
services all fit in the specified buffer, invalidating the test so
there is a retry in place.
But in some cases the second call just returns fewer tests than
expected. So retry in that case too.
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=53460
---
This fixes the remaining failures on Windows 8.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4413
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
--
v9: wineboot: Compute and write the TSC frequency to registry ~Mhz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
We used to have some hack for passing information (mainlyi
module related ones) from dbghelp to WineDbg.
This series:
- reimplements properly the sharing, introducing a Wine
entrypoint to dbghelp (sharing debug formats not handled
by native, no longer decorating module names for sharing
that module was in fact a host module...)
- improves "info share" command in WineDbg with more accurate
information (host module type...)
- improves loading time on MacOs (some system libraries no
longer have their images accessible directly on disk by
standard file operation).
--
v4: dbghelp: Pretend mach-o is present in case of failure.
dbghelp: Expose PE native vs builtin information to winedbg.
dbghelp,winedbg: No longer decorate ELF/Mach-O module names.
dbghelp: Expose some internal information about modules to winedbg.
dbghelp: Remove DMT_ entries for .DBG and .PDB files.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4142
We used to have some hack for passing information (mainlyi
module related ones) from dbghelp to WineDbg.
This series:
- reimplements properly the sharing, introducing a Wine
entrypoint to dbghelp (sharing debug formats not handled
by native, no longer decorating module names for sharing
that module was in fact a host module...)
- improves "info share" command in WineDbg with more accurate
information (host module type...)
- improves loading time on MacOs (some system libraries no
longer have their images accessible directly on disk by
standard file operation).
--
v3: dbghelp: Pretend mach-o is present in case of failure.
dbghelp: Expose PE native vs builtin information to winedbg.
dbghelp,winedbg: No longer decorate ELF/Mach-O module names.
dbghelp: Expose some internal information about modules to winedbg.
dbghelp: Remove DMT_ entries for .DBG and .PDB files.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4142
This serie:
- adds a couple of msvcrt env tests (mainly env block inheritance)
- introduces env tests for ucrtbase
- reimplement most of the env related functions to mimic native
behavior (basically when env is modified, native crt uses
a per-variable entry allocation block (instead of having
pointers inside a single chunk of memory).
This fixes programs which keep a pointer on returned getenv()
string and expect that pointer content is not modified when
other variables in env are modified.
@piotr: from previous version
- I dropped the synchronization of \_environ and \_wenviron
hence requiring the duplication of most of the code in
ansi/unicode versions
- I also tested the changes with unicode crt startup code
(you can find in [1] this MR extended with this test code
but I don't think we want to push it upstream)
- there are some init code changes because of ucrtbase tests
and unicode crt startup tests
[1] https://gitlab.winehq.org/epo/wine/-/tree/mr-crt-env-full?ref_type=heads
--
v3: msvcrt: Fix ucrtbase environment initialization.
msvcrt: Reimplement environ related functions.
ucrtbase/tests: Introduce environment tests.
msvcrt/tests: Test passing environment in child process.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4377
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
--
v8: wineboot: Compute and write the TSC frequency to registry ~Mhz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
--
v6: vkd3d-shader/dxil: Implement the DXIL LOAD instruction.
vkd3d-shader/dxil: Implement the DXIL GEP instruction.
vkd3d-shader/dxil: Support global variable initialisers.
vkd3d-shader/dxil: Introduce a value type for immediate constant buffers.
vkd3d-shader/dxil: Implement default address space global variables.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/471
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
--
v7: wineboot: Compute and write the TSC frequency to registry ~Mhz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
--
v6: wineboot: Compute and write the TSC frequency to registry ~Mhz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
--
v5: Apply 1 suggestion(s) to 1 file(s)
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
You most likely want to always use the script, not only for unknown locale.
For unknown countries we should probably fall back to neutral locale in all cases.
Also the user_locale variable needs to be updated.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4357#note_52528
This is my first time contributing wine and there are a lot of things I'm not sure about, so any comments are welcome. :)
--
v11: kernel32: add simple sync barrier test
kernel32: impl sync barrier
https://gitlab.winehq.org/wine/wine/-/merge_requests/4372
--
v7: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten structured control flow instructions.
vkd3d-shader: Rename shader_instruction_array_add_icb() to shader_instruction_array_add_opaque_param().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
--
v3: wineboot: Compute and write the TSC frequency to registry ~Mhz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
```
In HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor
Squashed with patches from:
* Arkadiusz Hiler <ahiler(a)codeweavers.com>
Check if the kernel trusts TSC before using it for Qpc.
Even if the bits are claiming that TSC meets our requirements the
hardware implementation may still be broken.
The Linux kernel does a lot of quality testing before deciding to use as
the clock source. If it (or the user, through an override) does not trust
the TSC we should not trust it either.
* Joshua Ashton <joshua(a)froggi.es>
Some games such as Horizon Zero Dawn use this registry value to
correlate values from rtdsc to real time.
Testing across a few devices, is seems like Windows always returns the
TSC frequency in this entry, not the current/maximum frequency of the
processor.
Returning the nominal/maximum cpu frequency here causes the game to run
in slow motion as it may not match the tsc frequency of the processor.
Ideally we'd not have to measure this and the kernel would return
tsc_khz to userspace, but this is a good enough stop-gap until
https://lkml.org/lkml/2020/12/31/72 or something similar is merged.
CW-Bug-Id: #18918
CW-Bug-Id: #18958
```
--
v2: wineboot: Add comment about TSC trust check.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
--
v2: wined3d: Provide a null counter BO for slots with no corresponding XFB buffer bound.
wined3d: Create the XFB counter BO in wined3d_context_vk_bind_stream_output_buffers().
d3d8: Pass NOOVERWRITE to redundantly discarded maps.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4363
On Thu Nov 16 08:34:17 2023 +0000, Huw Davies wrote:
> ```c
> default:
> FIXME("Message %s needs unmapping\n", MCI_MessageToString(msg));
> break;
> ```
Sorry, I was looking at my wine-string tree, which had it removed.
I'll update the patches shortly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3854#note_52496
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
```
In HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor
Squashed with patches from:
* Arkadiusz Hiler <ahiler(a)codeweavers.com>
Check if the kernel trusts TSC before using it for Qpc.
Even if the bits are claiming that TSC meets our requirements the
hardware implementation may still be broken.
The Linux kernel does a lot of quality testing before deciding to use as
the clock source. If it (or the user, through an override) does not trust
the TSC we should not trust it either.
* Joshua Ashton <joshua(a)froggi.es>
Some games such as Horizon Zero Dawn use this registry value to
correlate values from rtdsc to real time.
Testing across a few devices, is seems like Windows always returns the
TSC frequency in this entry, not the current/maximum frequency of the
processor.
Returning the nominal/maximum cpu frequency here causes the game to run
in slow motion as it may not match the tsc frequency of the processor.
Ideally we'd not have to measure this and the kernel would return
tsc_khz to userspace, but this is a good enough stop-gap until
https://lkml.org/lkml/2020/12/31/72 or something similar is merged.
CW-Bug-Id: #18918
CW-Bug-Id: #18958
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
On Thu Nov 16 08:10:02 2023 +0000, Alistair Leslie-Hughes wrote:
> No. The default action is to just exit if nothing needs to be freed.
```c
default:
FIXME("Message %s needs unmapping\n", MCI_MessageToString(msg));
break;
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3854#note_52495
Fixes a hang when joining a multiplayer game in Burnout Paradise Remastered. The game expects to find a space in the device name and spins forever trying if it can't.
--
v3: winepulse.drv: Change device description.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4096
Freetype's FT_Load_Glyph may return different glyph metrics (in particular, horiAdvance) depending on load target flags (FT_LOAD_TARGET_MONO, FT_LOAD_TARGET_NORMAL ...). Among the consequences of that are:
- the size of, e. g, GetTextExtentPoint() doesn't match the size of actually rendered text;
- DrawTextW() with DT_CALCRECT flag returns wrong bounding rectangle.
In the core of that is GetGlyphOutline() returning different values for GGO_METRICS format (used in various glyph metrics query functions) and the actual format used during rendering.
It probably make sense to use effective fonts rendering option for GGO_METRICS so that matches. I did some ad-hoc testing on Windows with currently problematic Tahoma font and quite expectedly GetGlyphOutline(GGO_METRICS) always returns the same metrics as other output format options. While all the options also have the same metrics between each other (which is still not the case with Wine). I guess it is not easily possible to make all the face load options match each other with freetype (nor I am sure that is always the case on Windows for all the possible fonts), but making GGO_METRICS return the metrics matching actual gdi device context setup looks more important.
Fixes Idle Spiral being unable to render typed text in save / load dialogs (which is using Winforms from Unity's Mono).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4406
Goes atop !459. The last six commits belong to this MR.
--
v5: vkd3d-shader/dxil: Implement the DXIL LOAD instruction.
vkd3d-shader/dxil: Implement the DXIL GEP instruction.
vkd3d-shader/dxil: Support global variable initialisers.
vkd3d-shader/dxil: Introduce a value type for immediate constant buffers.
vkd3d-shader/dxil: Implement default address space global variables.
vkd3d-shader: Delete unused struct list from struct vkd3d_shader_indexable_temp.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/471
On Wed Nov 15 21:05:11 2023 +0000, Zebediah Figura wrote:
> > Because it doesn't really matter,
> On what grounds?
> > and it makes our implementation simpler.
> It makes our implementation simpler to type E_INVALIDARG rather than HRESULT_FROM_WIN32(ERROR_INVALID_NAME)?
In the past when I've added tests for behavior that differs from one Windows version to another, I've been asked to designate one behavior as the "correct" behavior and mark the other as broken. In this case, the applications in question require the function to report success, so testing and implementing the function's argument checking is really just to help us understand what the arguments are. The patch already has an if statement that returns E_INVALIDARG, and it would be slightly simpler to add to the existing if statement than to add a second if statement to return HRESULT_FROM_WIN32(ERROR_INVALID_NAME).
If you would prefer to return HRESULT_FROM_WIN32(ERROR_INVALID_NAME) instead, or to not handle that error case at all in the stub implementation (as Fabian originally proposed), that's totally fine. The applications we're trying to support will work either way.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4343#note_52417
Currently we are not properly handling register(cX) reservations for SM1, this is one of the things required for the SNK shaders (CW Bug Bug 18092).
register(cX) reservations also change the offset in the $Globals buffer in SM4, so support for this is also included.
---
Patch 1/4 is required to specify:
```
[require]
shader model < 4.0
```
so that the tests that follow do not get run with the vulkan backend on SM4. I think nobody disagreed with that patch.
--
v5: vkd3d-shader/hlsl: Turn register(cX) reservations into buffer offset for SM4.
vkd3d-shader/hlsl: Make register(cX) reservations work for SM1.
tests: Test register(cX) reservations.
tests: Rename register-reservations.shader_test to register-reservations-resources.shader_test.
tests/shader-runner: Run compilation tests with SM1 when SM1 models are selected.
tests/shader-runner: Allow passing (sm<4) and (sm>=4) to "fail" and "todo" qualifiers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/458
> Because it doesn't really matter,
On what grounds?
> and it makes our implementation simpler.
It makes our implementation simpler to type E_INVALIDARG rather than HRESULT_FROM_WIN32(ERROR_INVALID_NAME)?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4343#note_52414
On Wed Nov 15 20:52:54 2023 +0000, Zebediah Figura wrote:
> > assume that ERROR_INVALID_NAME is broken behavior, and make Wine
> return E_INVALIDARG in this situation.
> Why?
Because it doesn't really matter, and it makes our implementation simpler.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4343#note_52413