Supersedes !482.
Instead of only storing the value that each variable's component has at
the moment of the instruction currently handled by copy-prop, we store
the trace of all the historic values with their timestamps, i.e. the
instruction index on which the value was stored.
This allow us to query the value that the variable's component had at the time of a swizzle's load instead of the swizzle instead, which also preempts copy-prop from getting stuck in an infinite loop, as which the added tests.
--
v2: vkd3d-shader/hlsl: Use values at the time of the swizzle's load in copy-propagation.
vkd3d-shader/hlsl: Record trace of stored values in copy-propagation.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/487
--
v3: ws2_32: Translate AFD_POLL_RESET to FD_CLOSE plus WSAECONNABORTED in WSAEnumNetworkEvents().
server: Translate AFD_POLL_RESET to FD_CLOSE plus WSAECONNABORTED in window messages.
server: Return ERROR_CONNECTION_RESET when trying to recv() on a reset socket.
ws2_32/tests: Work around a Linux bug.
ws2_32/tests: Test send() after TCP reset.
http.sys: Keep connection sockets open after sending a 400 response.
ws2_32/tests: Test sending data to a peer which is closed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/544
Supersedes !482.
Instead of only storing the value that each variable's component has at
the moment of the instruction currently handled by copy-prop, we store
the trace of all the historic values with their timestamps, i.e. the
instruction index on which the value was stored.
This allow us to query the value that the variable's component had at the time of a swizzle's load instead of the swizzle instead, which also preempts copy-prop from getting stuck in an infinite loop, as which the added tests.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/487
Jacek Caban (@jacek) commented about programs/regsvr32/regsvr32.c:
> Unregister = TRUE;
> break;
> case 's':
> + SetThreadLocale(MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT));
We're using the same thread later to call arbitrary DLL code later, so changing locale here doesn't seem right.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4440#note_53347
IMFMediaType_(Get|Free)Representation is called by Samurai Maiden, MFInitAMMediaTypeFromMFMediaType could be useful to simplify DMO / MFT transforms implementations.
--
v4: mfplat: Implement IMFMediaType_(Get|Free)Representation.
mfplat: Implement MFCreateAMMediaTypeFromMFMediaType.
mfplat: Implement MFInitAMMediaTypeFromMFMediaType.
mfplat: Use bits per pixel in uncompressed formats metadata.
mfplat: Only convert MEDIASUBTYPE for the formats which need it.
mfplat/tests: Add IMFMediaType_GetRepresentation tests.
mfplat/tests: Add tests for MFCreateAMMediaTypeFromMFMediaType.
mfplat/tests: Add tests for MFInitAMMediaTypeFromMFMediaType.
mfplat: Add MFInitAMMediaTypeFromMFMediaType stub.
mfplat: Add MFCreateAMMediaTypeFromMFMediaType stub.
mfplat: Add support for internal MFVideoFormat_A2B10G10R10.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4439
IMFMediaType_(Get|Free)Representation is called by Samurai Maiden, MFInitAMMediaTypeFromMFMediaType could be useful to simplify DMO / MFT transforms implementations.
--
v3: mfplat: Implement IMFMediaType_(Get|Free)Representation.
mfplat: Implement MFCreateAMMediaTypeFromMFMediaType.
mfplat: Implement MFInitAMMediaTypeFromMFMediaType.
mfplat: Use bits per pixel in uncompressed formats metadata.
mfplat: Only convert MEDIASUBTYPE for the formats which need it.
mfplat/tests: Add IMFMediaType_GetRepresentation tests.
mfplat/tests: Add tests for MFCreateAMMediaTypeFromMFMediaType.
mfplat/tests: Add tests for MFInitAMMediaTypeFromMFMediaType.
mfplat: Add MFInitAMMediaTypeFromMFMediaType stub.
mfplat: Add MFCreateAMMediaTypeFromMFMediaType stub.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4439
Implements asin, acos, atan, and atan2.
Also includes some tests in a new test file.
One possible problem here is that I'm not sure how to test what Microsoft's atan and atan2 outputs are in boundary cases like atan2(1, 0). I've made the test suites adhere with the calculator program I've been using (Qalculate, which I assume is using libc's atan2).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55154
--
v5: vkd3d-shader/hlsl: Implement atan2.
vkd3d-shader/hlsl: Implement atan.
vkd3d-shader/hlsl: Implement acos and asin trig intrinsics.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/364
Certain characters are considered by GetTextExtentExPointA/W/I to have no width, even if they have a non-zero width and a shape in the font. This MR attempts to bring Wine's implementation of these functions closer to native behavior.
One remaining difference is caused by GetGlyphIndicesA/W returning 0 instead of 0xffff for some characters, for some reason. This also affects the handling by GetTextExtentExPointA/W/I of affected characters. I have compared this with both Uniscribe and DWrite behavior and neither of them match this behavior, so it seems to be a peculiarity of these older functions.
Remaining differences are probably caused by differences in the fallback fonts used when a character is missing from the selected font. Notably, on my system there doesn't seem to be a fallback font for `\t`/`\n`/`\r` that marks those characters as zero-width, and since applications are likely to depend on the metrics of those characters (I know of at least one), I have opted to explicitly make them zero-width in this MR, even though that is technically not what Windows does.
--
v5: win32u: Handle glyphs that are marked by the font as zero-width in GetTextExtentExPoint[AWI].
win32u: Use maximum of (A, A+C, A+C+B) width for character fit test in GetTextExtentExPoint[AWI].
gdi32/tests: Add test for width of carriage return and line feed.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3876
--
v2: dmsynth: Use time instead of position to order events.
dmsynth: Preserve event order when positions are equal.
dmime: Queue note-off one tick early.
dmime: Requeue the note message instead of directly queueing MIDI note-off.
dmime/tests: Test output tool note requeueing.
dmime/tests: Move scale_music_time() and check_dmus_note_pmsg() up.
dmime: Correctly requeue messages with changed time.
dmime: Always queue messages with non-immediate delivery type.
dmime: Don't queue messages with immediate delivery type.
dmime: Factor out timeout computation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4438
--
v16: vkd3d-shader/dxil: Implement the DXIL LOAD instruction.
vkd3d-shader/dxil: Implement the DXIL GEP instruction.
vkd3d-shader/dxil: Support global variable initialisers.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/471
On Wed Nov 22 09:54:08 2023 +0000, Rémi Bernon wrote:
> changed this line in [version 2 of the diff](/wine/wine/-/merge_requests/4455/diffs?diff_id=85135&start_sha=f874b6f423bd4043b0c26c3011371f366b0f9504#61204a3bfaf089b3588b75ee6440092f482a6098_609_596)
Yeah, I had it like that and then, although I agree it's unnecessary, thought that as the mutex is guarding its initialization it should guard its access for consistency. Anyway, I changed it back.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4455#note_53291
This part introduces support for Vulkan swapchains to the Wayland driver:
* Implement several Vulkan functions typically called to get info before swapchain creation.
* Implement swapchain creation/destruction
* Implement getting swapchain images.
I stopped short of adding presentation support since the MR would grow too big (stay tuned for part 10.3).
Thanks!
--
v2: winewayland.drv: Implement vkGetSwapchainImagesKHR.
winewayland.drv: Implement vkGetPhysicalDeviceWin32PresentationSupportKHR.
winewayland.drv: Implement vkGetPhysicalDeviceSurfacePresentModesKHR
winewayland.drv: Implement vkDestroySwapchainKHR.
winewayland.drv: Implement vkCreateSwapchainKHR.
winewayland.drv: Implement vkGetPhysicalDeviceSurfaceCapabilities(2)KHR.
winewayland.drv: Implement vkGetPhysicalDeviceSurfaceFormats(2)KHR.
winewayland.drv: Implement vkGetPhysicalDeviceSurfaceSupportKHR.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4456
On Wed Nov 22 09:15:51 2023 +0000, Zebediah Figura wrote:
> I'm confused about why "scripting" is a concern here. Do any scripts
> currently parse the *text* output, which is currently localized, and
> redundant with the return value anyway? Would changing that to MESSAGE
> actually keep compatibility in that case?
> I think it probably makes sense to keep console output for the sake of
> clear communication, but I don't understand why scripting.
As posted above, some native apps don't return error code (eg. see comments in regedit - didn't retest it though).
So scripts calling these apps want to keep output for at least let the user know (from reading the output) if something went wrong (see https://bugs.winehq.org/show_bug.cgi?id=55723). The concern of 'scripting' is more linked to keeping an output, rather than insuring that output has a given form (or defined structure to be parsed.
The idea was :
* keep an output (at least in case of error) to the Unix console
* MESSAGE avoids reopening fd 1 as handle (at the cost of moving output from stdout to stderr), and also loses proper conversion to unix shell locale, hence the request to force English locale to have something always readable
* if scripters want to parse output, they likely already force a given locale
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4440#note_53283
If explicit_handle is defined in the *.idl file, c/s are uses explicit handles,
then an explicit handle must be passed in to the server-side interface.
And add a test for explicit_handle.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4451
Goes atop !471. The last six commits belong to this MR.
--
v4: vkd3d-shader/dxil: Emit constant global arrays as immediate constant buffers.
vkd3d-shader: Add a register index to struct vkd3d_shader_immediate_constant_buffer.
vkd3d-shader/spirv: Support declared component type and count in immediate constant buffers.
vkd3d-shader/spirv: Support constant initialisers in indexable temps.
vkd3d-shader/dxil: Support null constant arrays.
vkd3d-shader/spirv: Support declared component type and count in indexable temps.
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/477
--
v15: 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
Using a dedicated exit jmpbuf and removing the need for assembly
routines.
When Wine handles an exception in unix code, we return to user mode by
jumping to the last syscall frame. This can leave some pthread cancel
cleanups registered, in the pthread internal linked list, and at the
same time later overwrite the stack frame they were registered for.
In the same way, jumping to the exit frame on thread exit or abort, can
also leave some cleanup handlers registered for invalid stack frames.
Depending on the implementation, calling pthread_exit will cause all the
registered pthread cleanup handlers to be called, possibly jumping back
to now overwritten stack frames and causing segmentation faults.
Exiting a pthread normally, by returning from its procedure, or calling
exit(0) for the main thread doesn't run pthread_exit and doesn't call
cleanup handlers, avoiding that situation.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213
### Additional note:
For robustness, we should probably try to execute these cleanup handlers
when unwinding the stack frames, as we would otherwise leave pthread
objects in a potential problematic state (like a mutex locked, etc).
It is however hard to do so when the handlers are registered from some C
code: pthread C implementation is done by calling some internal pthread
functions to register the handlers, and they aren't registered as
standard unwind handlers.
Only pthread_cancel and pthread_exit can unwind and call / unregister
the C handlers, but interrupting that procedure, for instance calling
setjmp / longjmp from withing our own handler isn't supported.
From C++ code, pthread cleanup handlers are registered through C++ class
constructors / destructors, and it would then be possible to partially
unwind and call them at the same time.
--
v12: ntdll: Remove the signal_exit_thread wrapper.
ntdll: Get rid of the thread exit frame on ARM.
ntdll: Get rid of the thread exit frame on ARM64.
ntdll: Get rid of the thread exit frame on x86-64.
ntdll: Get rid of the thread exit frame on i386.
ntdll: Switch to the kernel stack to abort a thread on ARM.
ntdll: Switch to the kernel stack to abort a thread on ARM64.
ntdll: Switch to the kernel stack to abort a thread on x86-64.
ntdll: Switch to the kernel stack to abort a thread on i386.
ntdll: Connect syscall frames across user callbacks on ARM.
ntdll: Connect syscall frames across user callbacks on ARM64.
ntdll: Connect syscall frames across user callbacks on x86-64.
ntdll: Connect syscall frames across user callbacks on i386.
ntdll: Add a syscall_cfa member to the ARM syscall frame.
ntdll: Add a syscall_cfa member to the ARM64 syscall frame.
ntdll: Add a syscall_cfa member to the x86_64 syscall frame.
ntdll: Add a syscall_cfa member to the i386 syscall frame.
ntdll: Remove unnecessary stack pointer CFI rules.
ntdll: Add comments to stack switches in dispatchers.
ntdll: Directly access the syscall table variable on ARM64.
ntdll: Directly access the syscall table variable on x86-64.
ntdll: Store the syscall table in the TEB on ARM.
ntdll: Store the syscall table in the TEB on i386.
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/1088
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=….
--
v3: vkd3d-shader/hlsl: Avoid replacing with the same swizzle in copy-prop.
vkd3d-shader/hlsl: Move index_instructions() up.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/482
I'm confused about why "scripting" is a concern here. Do any scripts currently parse the *text* output, which is currently localized, and redundant with the return value anyway? Would changing that to MESSAGE actually keep compatibility in that case?
I think it probably makes sense to keep console output for the sake of clear communication, but I don't understand why scripting.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4440#note_53135
This part introduces support for Vulkan swapchains to the Wayland driver:
* Implement several Vulkan functions typically called to get info before swapchain creation.
* Implement swapchain creation/destruction
* Implement getting swapchain images.
I stopped short of adding presentation support since the MR would grow too big (stay tuned for part 10.3).
Thanks!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4456
This program is in GUI subsystem, but expects I/O
with Unix console. This is a Wine specific behavior.
So explicitely use unix fd instead of the inherited
standard handles.
Wine-Bugs: https://bugs.winehq.org/show_bug.cgi?id=55723
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
v2: regedit: Use message boxes by default for output.
regsvr32: Use message boxes by default for output.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4440
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).
--
v2: win32u: Use font AA flags when querying glyph outline with GGO_METRICS.
d3dx9/tests: Make test_ID3DXFont() less dependent on GetGlyphOutlineW(GGO_METRICS) behaviour.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4406
It looks like msvcp doesn't export anything for the std::bad_function_call exception construction and if std::bad_function_call is constructed directly from the app the corresponding class data is generated in the application binary.
I am attaching an ad-hoc test program I used to test it (using MSVC 2022 community edition).
[msvcp_except.cpp](/uploads/558f0911366525d05af4ac69552c4aae/msvcp_except.cpp)
--
v2: msvcp110: Implement std::_Xbad_function_call().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4446
On Tue Nov 21 15:10:16 2023 +0000, Rémi Bernon wrote:
> I suspect this is actually related to the tests using WMAUDIO2 (aka
> WMAudioV8), which, if I believe the headers files, where
> WMAUDIO_BITS_PER_SAMPLE is used, only supports 16bps. The bps is then
> automatically set and the media type doesn't need one.
> Also from the headers, I suspect WMAUDIO3 may support variable bps which
> maybe would require changes here and in other places where we use a
> fixed value. All of which may require more tests to be sure. Which
> probably could be added later.
Yes, more tests always help. But GStreamer/ffmpeg don't have any WMA3/WMALossless/WMV3/WMVA/WVC1 encoders, and Windows' media APIs are _complicated_, so I couldn't produce any suitable test files.
Probably not a huge deal which output format we use, we've got audioconvert elements. But there's also no point hardcoding things when there's a depth field in struct wg_format; fixed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4450#note_53102
On Tue Nov 21 14:32:55 2023 +0000, Rémi Bernon wrote:
> Is this needed by an application or is it just to pass the tests? In the
> latter case we can just keep a todo_wine. This flags fixup looks too arbitrary.
Needed by Wagamama. Without it, the sound channel gets stuck looping the same ~second over and over.
I completely agree it's ugly; feels to me like some kind of GStreamer or ffmpeg bug. If you can think of a better solution, do tell.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4450#note_53101
On Tue Nov 21 14:16:04 2023 +0000, Alfred Agrell wrote:
> Something in mf:transform test_wma_decoder() needs it.
> But unless we can find an actual WMA file that does that, better fix it
> in the test instead. Fixed.
I suspect this is actually related to the tests using WMAUDIO2 (aka WMAudioV8), which, if I believe the headers files, where WMAUDIO_BITS_PER_SAMPLE is used, only supports 16bps. The bps is then automatically set and the media type doesn't need one.
Also from the headers, I suspect WMAUDIO3 may support variable bps which maybe would require changes here and in other places where we use a fixed value. All of which may require more tests to be sure. Which probably be added later.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4450#note_53090
It looks like msvcp doesn't export anything for the std::bad_function_call exception construction and if std::bad_function_call is constructed directly from the app the corresponding class data is generated in the application binary.
I am attaching an ad-hoc test program I used to test it (using MSVC 2022 community edition).
[msvcp_except.cpp](/uploads/558f0911366525d05af4ac69552c4aae/msvcp_except.cpp)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4446
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
--
v5: msvcrt: Fix ucrtbase environment initialization.
msvcrt: Allocate environment variables in separate allocation chunks.
msvcrt: Lazily initialize ___winitenv.
msvcrt: Factor out wenv_get_index helper.
msvcrt: Factor out env_get_index helper.
ucrtbase/tests: Introduce environment tests.
msvcrt/tests: Test passing environment in child process.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4377
This allows initializing locale from Mac locale identifiers like
'zh-Hans-US'. The current implementation recognizes it as 'zh-US'
which isn't a valid locale identifier for Windows.
This patch will try again with the 'lang-script' identifier after
get_win_locale() fails with the 'lang-region' identifier.
--
v3: ntdll/unix: Support to initialize locale from 'lang-script' format language identifier.
ntdll/unix: Use different variable names for Mac locales.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4357
Based on @rbernon's work in !1088, with additional ARM support and
some cleanups.
--
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/4445
I tested a program a user was asking about on the forum (https://forum.winehq.org/viewtopic.php?t=38192).
The program (or in fact a file called Unity.Licensing.Client.exe) looks for namespace "root\\StandardCimv2"
After adding this patch following query is done:
0024:trace:wbemprox:wbem_services_ExecQuery 00007FFB582B6660, L"WQL", L"SELECT Name,InterfaceDescription,PermanentAddress,NetworkAddresses,PNPDeviceID FROM MSFT_NetAdapter", 0x20, 0000000000000000, 00007FFFFE27DCD8
I don't know exactly what the problem is that user is experiencing, I can only tell that I'm not able to login. I provided some
dummy values for the requested properties from the MSFT_NetAdapter class but that didn't help. For now I think adding the MSFT_NetAdapter class
is not yet worth the trouble, but with this patch it is at least visible for what class the program is looking for.
The program can be found at https://unity3d.atlassian.net/wiki/spaces/AR/pages/1571848193/New+in+ArtEng…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4453