NtUserMessageCall(..., NtUserSendDriverMessage) does not ensure the
validity of the hwnd, so this check will incorrectly fail if the
last error was ERROR_INVALID_WINDOW_HANDLE by coincidence. The
notify_owner call immediately following this code will catch a
destroyed owner hwnd.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3147
On Fri Jun 23 19:02:05 2023 +0000, Davide Beatrici wrote:
> I would expect the same behavior for `PFD_DRAW_TO_BITMAP` though. Aren't
> both the same flag "class"?
I guess we need more tests to be sure.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3111#note_36674
On Fri Jun 23 18:54:52 2023 +0000, Damjan Jovanovic wrote:
> I don't think it works like that. If the flag is set, it only returns a
> PIXELFORMATDESCRIPTOR with the flag set, but if it is clear, then the
> returned PIXELFORMATDESCRIPTOR can have the flag set or cleared.
I would expect the same behavior for `PFD_DRAW_TO_BITMAP` though. Aren't both the same flag "class"?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3111#note_36673
On Fri Jun 23 18:48:33 2023 +0000, Davide Beatrici wrote:
> For consistency:
> ```suggestion:-0+0
> if ((ppfd->dwFlags & PFD_SUPPORT_GDI) != (format.dwFlags & PFD_SUPPORT_GDI))
> ```
I don't think it works like that. If the flag is set, it only returns a PIXELFORMATDESCRIPTOR with the flag set, but if it is clear, then the returned PIXELFORMATDESCRIPTOR can have the flag set or cleared.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3111#note_36672
And use that instead of duplicating those helpers across the tree.
Besides removing existing duplicates, I am planning to add yet another WinRT dll (gamepad) and we will likely add more in the future, each of those can use that, as well as potentially more common helpers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1045
This MR supercedes !1895 and !3073 as a solution to bug [#50771](https://bugs.winehq.org/show_bug.cgi?id=50771). Rather than fixing the problem of Wine's inability to modify the attributes of read-only files, this patch set instead implements `FileDispositionInformationEx` which the Msys2 and Cygwin runtime libriries can use to avoid needing to modify attributes.
All the flags of `FileDispositionInformationEx` are implemented with the exception of `FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK`.
This MR improves upon !3073 by implementing `FILE_DISPOSITION_POSIX_SEMANTICS` and `FILE_DISPOSITION_ON_CLOSE` where the previous MR only implemented `FILE_DISPOSITION_DELETE` and `FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE`.
--
v2: ntdll: Implement FILE_DISPOSITION_POSIX_SEMANTICS
server: Replace unlink member of closed_fd with disp_flags
ntdll/tests: Add tests for FILE_DISPOSITION_POSIX_SEMANTICS
https://gitlab.winehq.org/wine/wine/-/merge_requests/3122
Unix consoles (created from initial process) are inherited by child
processes for various reasons, like keeping std handles bound to that
unix console.
This differs from Windows as the default for a GUI is not to have
console attached.
If a GUI programs asks for a console, it will succeed on Windows
but fail under Wine as the Unix console is still present.
So, allow AllocConsole() to succeed when called from a GUI program
and tied to a Unix console.
(don't do it for CUI as they are already attached to a console).
This fixes Scrap Mechanic when run with '-dev' option.
(based on suggestion from Zhiyi Zhang)
Signed-off-by: Eric Pouech <epouech(a)codeweavers.com>
--
v2: kernelbase: Only inherit consoles for CUI processes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3022
--
v5: winepulse: Refactor AudioClient's Initialize to match other drivers.
wineoss: Use create_stream's channel count in AudioClient's Initialize.
winecoreaudio: Use create_stream's channel count in AudioClient's Initialize.
winealsa: Use create_stream's channel count in AudioClient's Initialize.
winepulse: Use mmdevapi's set_stream_volumes.
wineoss: Use mmdevapi's set_stream_volumes.
winecoreaudio: Use mmdevapi's set_stream_volumes.
winealsa: Use mmdevapi's set_stream_volumes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3112
This commit is part of a series of commits intended to remove all uses of hlsl_type_get_regset().
However, I think it deserves to be upstreamed sooner since it solves a rather important SM1 regression (explained below) introduced in e0031d2a1f40792ac85619a495bf5197f248b0e1 .
---
In SM1 we can expect all variables to always belong to a single regset.
structs in particular, should always be allocated to HLSL_REGSET_NUM,
since they are only allowed if all their components are numeric.
We are not covering the structs case because of the use of
hlsl_type_get_regset(), which is currently not defined for structs.
So the current shader
```hlsl
struct
{
float4 a;
float4 b;
} apple;
float4 main() : sv_target
{
return apple.a + apple.b;
}
```
fails with
```
vkd3d/libs/vkd3d-shader/hlsl.c:224: Aborting, reached unreachable code.
```
The solution is to iterate over all regsets to find the one where the
variable is allocated (if any), and ignore all others.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/236
On Fri Jun 23 06:46:32 2023 +0000, Huw Davies wrote:
> This is changing the allocator for `vols`, so you'll need commits that
> change that first.
> As this MR is already too long, let's split this into a new one and
> leave the first seven or eight commits here.
Sounds good. `malloc()` and `free()` are preferred, right?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3112#note_36613
Huw Davies (@huw) commented about dlls/winealsa.drv/mmdevdrv.c:
> - params.duration = duration;
> - params.period = period;
> - params.fmt = fmt;
> - params.channel_count = &channel_count;
> - params.stream = &stream;
> -
> - ALSA_CALL(create_stream, ¶ms);
> -
> - free(name);
> -
> - if(FAILED(params.result)){
> - sessions_unlock();
> - return params.result;
> - }
> -
> - This->vols = HeapAlloc(GetProcessHeap(), 0, channel_count * sizeof(float));
This is changing the allocator for `vols`, so you'll need commits that change that first.
As this MR is already too long, let's split this into a new one and leave the first seven or eight commits here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3112#note_36612
--
v3: wineoss: Use mmdevapi's AudioClient's Initialize.
winecoreaudio: Use mmdevapi's AudioClient's Initialize.
winealsa: Use mmdevapi's AudioClient's Initialize.
winepulse: Move AudioClient's Initialize into mmdevapi.
winepulse: Refactor AudioClient's Initialize to match other drivers.
wineoss: Use create_stream's channel count in AudioClient's Initialize.
winecoreaudio: Use create_stream's channel count in AudioClient's Initialize.
winealsa: Use create_stream's channel count in AudioClient's Initialize.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3112
Currently, in PE modules, DECLSPEC_HIDDEN is useful only when cross compiler is missing. This makes non-PE build behavior more similar to proper PE builds, no longer requiring extra attention to support those configurations.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3138
Some of these fixes are subtle (like the first patch) and very annoying to debug. Although the first patch looks like a hack, surprisingly, it's how the spec itself says it is! It's not even an IE quirk, but a special case in the spec.
For example, the variable name (which holds the builtin eval func) **does** matter: if it's called something other than 'eval', it gets treated differently (as if indirect), and this is verified by the tests + the spec's wording (so Microsoft's implementation follows it).
Most of the patches other than the first 2 are pretty small so they're in same MR.
--
v9: jscript: Get rid of the function instance in arguments obj.
jscript: Start from the last argument when adding them to named locals.
jscript: Store detached args into a scope's specialized buffer.
jscript: Don't use iface_to_jsdisp where it's not necessary to grab it.
jscript: Get rid of jsobj in scope_chain_t.
jscript: Fix function leak in scope_init_locals.
jscript: Fix addressing invalid memory if ref is an argument.
jscript: Correctly implement context for indirect eval calls in ES5+ modes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2942
The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps:
1. Associate a window with a Wayland surface and give it the `xdg_toplevel` role, so that the compositor can display it. We also have to implement the required initial `xdg_surface` configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2).
2. Implement the `window_surface` interface for the Wayland driver. For now we provide a simple (and suboptimal) `window_surface_flush` implementation: for each flush we create a new `wl_shm` buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the `window_surface` to minimize copying of data from the `window_surface` to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads.
With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy `notepad` in all its blinking-cursor glory.
Thanks!
--
v6: winewayland.drv: Do not commit buffers to unconfigured surfaces.
winewayland.drv: Implement a simple window_surface flush.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2944
This series adds a couple of features to WinRT's media.speech:
- IVoiceInformation, and synthetizer's options are present
(mainly use to store information, not yet to make fully use of it)
- add a dummy implementation (1 single voice); that should be extended
in future series by using ISpVoice instead
- add a couple of more tests to go with implementation
(the serie should prevent MS Flight simulator to crash on first
connection. Crash is due to exception handling of C# generated
exceptions from E_NOTIMPL with some X11 related critical resources).
A+
--
v3: windows.media.speech: Implement get/put voice on synthesizer.
windows.media.speech: Select a default voice in synthesizer.
windows.media.speech: Add more tests about default voice.
windows.media.speech: Finish implementation of voice information view.
windows.media.speech/tests: Add tests about vector view's content.
windows.media.speech: Add basic implementation of IVoiceInformation.
windows.media.speech: Add more tests about IVoiceInformation.
windows.media.speech: Add basic implementation on synthesizer options.
windows.media.speech: Add a couple of synthesizer's options tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3048
The way CryptAcquireContext is currently used for temporary internal context in CertCreateSelfSignCertificate(), there is always a unique container created and persisted in registry (thus resulting in ever growing registry while an app repeatedly creates ephemeral certs with CertCreateSelfSignCertificate). The unique container name doesn't go anywhere outside of CRYPT_CreateKeyProv, and the crypt context is only used internally in CertCreateSelfSignCertificate() to generate the key and extract the key data (and put that to certificate store), so using a non-persistent context should be better.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3123
Some of these fixes are subtle (like the first patch) and very annoying to debug. Although the first patch looks like a hack, surprisingly, it's how the spec itself says it is! It's not even an IE quirk, but a special case in the spec.
For example, the variable name (which holds the builtin eval func) **does** matter: if it's called something other than 'eval', it gets treated differently (as if indirect), and this is verified by the tests + the spec's wording (so Microsoft's implementation follows it).
Most of the patches other than the first 2 are pretty small so they're in same MR.
--
v8: jscript: Get rid of the function instance in arguments obj.
jscript: Start from the last argument when adding them to named locals.
jscript: Store detached args into a scope's specialized buffer.
jscript: Don't use iface_to_jsdisp where it's not necessary to grab it.
jscript: Get rid of jsobj in scope_chain_t.
jscript: Fix function leak in scope_init_locals.
jscript: Fix addressing invalid memory if ref is an argument.
jscript: Correctly implement context for indirect eval calls in ES5+ modes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2942
The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps:
1. Associate a window with a Wayland surface and give it the `xdg_toplevel` role, so that the compositor can display it. We also have to implement the required initial `xdg_surface` configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2).
2. Implement the `window_surface` interface for the Wayland driver. For now we provide a simple (and suboptimal) `window_surface_flush` implementation: for each flush we create a new `wl_shm` buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the `window_surface` to minimize copying of data from the `window_surface` to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads.
With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy `notepad` in all its blinking-cursor glory.
Thanks!
--
v5: winewayland.drv: Do not commit buffers to unconfigured surfaces.
winewayland.drv: Implement a simple window_surface flush.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2944
I have found some scripts where comparisons that use floats and OLECOLOR directly fail. For example:
```
If Light005.State Then
' State is a float V_R4
End If
If Light005.Colorfull Then
' Colorfull is an OLECOLOR VT_UI4
End If
```
This is because `stack_pop_bool` does not handle `VT_R4` and `VT_UI4` and returns `E_NOTIMPL`.
This adds additional types to `stack_pop_bool` similar to `VARIANT_Coerce`.
Fixes https://bugs.winehq.org/show_bug.cgi?id=54731
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2507
On Wed Jun 21 09:30:59 2023 +0000, Zhiyi Zhang wrote:
> I think it will be better if you can report different driver versions
> for different vendors. For example, NVIDIA, AMD, and Intel drivers
> should have different versions. You can use gpu->vendor_id to
> differentiate them. For other vendors, either report a 1.0.0 version or
> simply don't add this property.
It might be good, but that variable doesn't contain any ID, only zero. I tried running games and applications.
Probably, it could work in ValveSoftware/Wine when they update their repository.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3104#note_36443
Both window station visibility and session id are related to services being
spawned in a non-interactive session, however the process window station
can be manually set by the application while the session id can not be.
The enumerated display config should not change even in the case of a
window station update, hence testing for SessionId == 0 is more reliable
here.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55074
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3130
--
v2: wineoss: Use mmdevapi's AudioClient's Initialize.
winecoreaudio: Use mmdevapi's AudioClient's Initialize.
winealsa: Use mmdevapi's AudioClient's Initialize.
winepulse: Move AudioClient's Initialize into mmdevapi.
winepulse: Refactor AudioClient's Initialize to match other drivers.
wineoss: Use create_stream's channel count in AudioClient's Initialize.
winecoreaudio: Use create_stream's channel count in AudioClient's Initialize.
winealsa: Use create_stream's channel count in AudioClient's Initialize.
winepulse: Use mmdevapi's set_stream_volumes.
wineoss: Use mmdevapi's set_stream_volumes.
winecoreaudio: Use mmdevapi's set_stream_volumes.
winealsa: Use mmdevapi's set_stream_volumes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3112
On my Nvidia GeForce GTX 1050 Ti `ddxddy.shader_test` doesn't pass because of considerably different numeric results.
As Giovanni pointed out, this is because my GPU uses the fine derivate and not the coarse derivate to implement ddx() and ddy().
For this reason, the result for ddx|ddy() is quantized so that the test passes if the GPU uses either coarse or fine derivates.
Additionally, tests for both ddx_coarse|ddy_coarse() and ddx_fine|ddy_fine() are added, that expect a more precise result.
--
v3: vkd3d-shader/hlsl: Support fine derivates.
vkd3d-shader/hlsl: Support coarse derivates.
tests: Quantize regular and coarse derivate test results.
tests: Make ddx() and ddy() test behave correctly for shader models < 4.
tests: Test coarse and fine derivates.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/224
When the child window and the parent window are no longer in the same process,
the parent window shadow does not update the vis rgn of the child window and
modify the WS_VISIBLE style of the child window. so we need to update the vis
rgn when another process gets the DC of the child window.
Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1306
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v7: ws2_32/tests: Fix incorrect test (bug #47560)
ws2_32/tests: Remove todo_wine from now-successful tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
I think it will be better if you can report different driver versions for different vendors. For example, NVIDIA, AMD, and Intel drivers should have different versions. You can use gpu->vendor_id to differentiate them. For other vendors, either report a 1.0.0 version or simply don't add this property.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3104#note_36398
The goal of this MR is to set up the minimum necessary infrastructure to display the contents of some simple, software rendered windows. This involves two major steps:
1. Associate a window with a Wayland surface and give it the `xdg_toplevel` role, so that the compositor can display it. We also have to implement the required initial `xdg_surface` configuration sequence to be able to safely (i.e., without the compositor disconnecting us with an error) attach buffers to the surface in step (2).
2. Implement the `window_surface` interface for the Wayland driver. For now we provide a simple (and suboptimal) `window_surface_flush` implementation: for each flush we create a new `wl_shm` buffer, copy the whole window contents (ignoring damaged bounds for now) into it and attach it to the target Wayland surface. In the next MR I will optimize this implementation in multiple ways: a. implement a buffer queue to avoid constantly allocating new buffers b. respect the damaged bounds of the `window_surface` to minimize copying of data from the `window_surface` to the SHM buffer (and also for correctness) c. communicate damaged surface regions to the compositor to (potentially) allow more efficient texture uploads.
With this MR many (software-rendered) applications can now display dynamic content on screen. We can't interact with the apps yet, but we do get to enjoy `notepad` in all its blinking-cursor glory.
Thanks!
--
v4: winewayland.drv: Do not commit buffers to unconfigured surfaces.
winewayland.drv: Implement a simple window_surface flush.
winewayland.drv: Introduce window_surface for Wayland.
winewayland.drv: Ensure Wayland surface handlers don't access invalid data.
winewayland.drv: Basic Wayland toplevel surface support.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2944
`getpeername()` is currently handled in ntdll. This merge request changes ntdll to forward `getpeername()` to wineserver. The implementation utilises new `peer_addr` and `peer_addr_len` fields in wineserver's `struct sock`.
This fixes multiple `todo_wine`s in `ws2_32/tests` and allows for more accurate peer names to be provided in case the address the socket is bound to on the Unix side does not match what `bind()` was called with on the Windows side.
*This merge request was originally intended to be included in !2786 (Add support for AF_UNIX sockets) but was split into its own merge request because this is not an insignificant change.*
--
v6: ws2_32/tests: Remove todo_wine from now-successful tests.
server: Move getpeername() implementation from ntdll/unix.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3074
After commit b337c5b1a1757b2abbc90a7c6955d64242861ab9 builds on FreeBSD
see 115 instances of
include/windef.h:60: warning: "__fastcall" redefined
which comes from <stdio.h> including <sys/cdefs.h> which in turns has
#define __fastcall __attribute__((__fastcall__))
Simply #undef-ining __fastcall like we do for some other cases already
addresses this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3091
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 supported by this patch.
--
v28: ws2_32/tests: Add test for AF_UNIX sockets.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
This MR supercedes !1895 and !3073 as a solution to bug [#50771](https://bugs.winehq.org/show_bug.cgi?id=50771). Rather than fixing the problem of Wine's inability to modify the attributes of read-only files, this patch set instead implements `FileDispositionInformationEx` which the Msys2 and Cygwin runtime libriries can use to avoid needing to modify attributes.
All the flags of `FileDispositionInformationEx` are implemented with the exception of `FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK`.
This MR improves upon !3073 by implementing `FILE_DISPOSITION_POSIX_SEMANTICS` and `FILE_DISPOSITION_ON_CLOSE` where the previous MR only implemented `FILE_DISPOSITION_DELETE` and `FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3122