Jacek Caban (@jacek) commented about dlls/winevulkan/vulkan_thunks.c:
> return (void *)out;
> }
>
> +static inline void convert_VkDeviceOrHostAddressKHR_win32_to_host(const VkDeviceOrHostAddressKHR32 *in, VkDeviceOrHostAddressKHR *out)
> +{
> + if (!in) return;
> +
> + out->deviceAddress = in->deviceAddress;
> + out->hostAddress = (void *)UlongToPtr(in->hostAddress);
FWIW, this will not do the right thing on wow64 when the address is meant to be device address. It will override the upper part of deviceAddress. It was broken in a different way before that commit by not zeroing upper 32 bits when host address should be used, so it essentially depended on caller to initialize that part. Unfortunately, I don't see a good way of solving it properly.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1508#note_17182
On Windows, application-specific settings are stored in the registry
under HKCU\Console\<path_to_app>.
Our implementation of conhost.exe does not know which process is
connected to it, so we need to get the full process image name before
loading any application-specific console settings.
To do this, we extend the server protocol to pass the process Id of
the connected console process to conhost.exe.
Please run tools/make_requests before merging.
--
v3: conhost: Load application-specific settings using the full process image name
server: Send console process ID via get_next_console_request()
https://gitlab.winehq.org/wine/wine/-/merge_requests/1492
It is possible that a stream is destroyed while another thread is waiting on
event_empty_cond or event_cond. The waiting thread should have the opportunity
to be rescheduled and exit the critical section before the condition variables
and the mutex are destroyed.
--
v5: winegstreamer: Synchronize media source async commands and shutdown.
winegstreamer: Free the GStreamer buffer when freeing a WG parser stream.
winegstreamer: Synchronize access to the media source from callbacks.
winegstreamer: Synchronize concurrent access to the media stream.
winegstreamer: Synchronize concurrent access to the media source.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1278
It is possible that a stream is destroyed while another thread is waiting on
event_empty_cond or event_cond. The waiting thread should have the opportunity
to be rescheduled and exit the critical section before the condition variables
and the mutex are destroyed.
--
v4: winegstreamer: Synchronize media source async commands and shutdown.
winegstreamer: Free the GStreamer buffer when freeing a WG parser stream.
winegstreamer: Synchronize access to the media source from callbacks.
winegstreamer: Synchronize concurrent access to the media stream.
winegstreamer: Synchronize concurrent access to the media source.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1278
In ept_map, rpcss uses TowerConstruct to allocate tower array elements.
The array is later released by the generated stub code, and each element
is ultimately freed using MIDL_user_free.
TowerConstruct always allocate memory using I_RpcAllocate, we must use
I_RpcFree to free it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1521
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
v9: imm32: Prevent deadlock on unload
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
v2: Expose wined3d_streaming_buffer_map() and wined3d_streaming_buffer_unmap() for strided data upload.
--
v2: wined3d: Add a lower size bound for the streaming buffer allocation.
ddraw: Use the wined3d_streaming_buffer helpers to manage the streaming index buffer.
ddraw: Use the wined3d_streaming_buffer helpers to manage the streaming vertex buffer.
wined3d: Factor out and expose functions to map/unmap wined3d_streaming_buffer.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1427
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45273
--
v15: gdiplus: Add GdipSetCustomLineCapStrokeCaps implementation and usage.
gdiplus: fix shape of CustomLineCap created by GdipCreateAdjustableArrowCap.
gdiplus: Add support for widen path with GpCustomLineCap.
gdiplus: use GpPointF for drawing in widen_closed_figure
gdiplus: Add GdipSetCustomLineCapBaseInset implementation.
gdiplus: Remove not used LineCustomCap parameter.
gdiplus: Add GdipSetCustomLineCapBaseCap implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1297
Also fixes a segmentation fault when exiting winedevice.exe.
I can file a separate bug report, but it seems related to Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213
On my system the core dump can be provoked when using the bus_udev backend in winebus.sys ("Enable SDL" 0). It creates two hid devices - a mouse and a keyboard. Since it resides in the same winedevice.exe process as wineusb.sys, something similar to the above bug occurs when handling the SIGQUIT signal. The actual crash happens in the libusb event thread while waiting in pthread_cond_wait().
I'm using this for months without any issues (with a device driver which uses wineusb.sys for device access, etc.).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1503
These functions are needed by a steam game called Super Naughty Maid.
It uses DMO wrapper filter to play WMV videos.
--
v2: winegstreamer: Implement media_object_GetInputType for WMV decoder.
mf/tests: Test IMediaObject_GetInputType for WMV decoder.
winegstreamer: Implement media_object_GetStreamCount for WMV decoder.
mf/tests: Test IMediaObject_GetStreamCount for WMV decoder.
winegstreamer: Implement profile_GetStreamByNumber.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1423
- v2:
- Allocate 3 buffers instead of 100.
- Add support for MFSampleExtension_Discontinuity.
- v3: Destroy the queue instead of flusing it.
--
v3: winegstreamer: Set the discontinuity flag in wg_transform.
include: Add MFSampleExtension_Discontinuity to mfapi.h.
winegstreamer: Allocate at least 3 buffers for MPEG audio in quartz parser.
winegstreamer: Destroy the sample queue when stopping the quartz transform.
winegstreamer: Hold the streaming lock while destroying wg_transform.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1384
This reimplements all logic from the server in kernelbase, which is needed because Nt*Key ignores KEY_WOW64_32KEY. Unfortunately this requires a lot of server calls.
The full branch can be found here
https://gitlab.winehq.org/sbaars/wine/-/tree/shared-classes-new
The old approach that doesn't duplicate code to kernelbase can be found here
https://gitlab.winehq.org/sbaars/wine/-/tree/shared-classes-old
I ran make_requests by the way, not sure if we should still leave that out with the gitlab workflow.
--
v2: kernelbase: Recursively obtain the Wow6432Node parent.
kernelbase: Add support for shared registry keys.
ntdll: Add a KeyFlagsInformation query.
kernelbase: Factor out the common parts of open_key() and create_key().
kernelbase: Reimplement create_key() using open_subkey().
kernelbase: Factor out opening a subkey.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1445
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45273
--
v13: gdiplus: Add GdipSetCustomLineCapStrokeCaps implementation and usage.
gdiplus: fix shape of CustomLineCap created by GdipCreateAdjustableArrowCap.
gdiplus: Add support for widen path with GpCustomLineCap.
gdiplus: use GpPointF for drawing in widen_closed_figure
gdiplus: Add GdipSetCustomLineCapBaseInset implementation.
gdiplus: Remove not used LineCustomCap parameter.
gdiplus: Add GdipSetCustomLineCapBaseCap implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1297
This video codec is used by games such as Richman 4, and Zwei: The Arges Adventure.
The decoder logic is based on code from the FFmpeg project.
--
v4: loader/wine.inf: Enable ir50_32 video codec.
ir50_32: Implement decompression to 24-bit RGB.
ir50_32: Implement IV50_DecompressGetFormat.
ir50_32: Implement IV50_DecompressQuery.
ir50_32: Implement IV50_GetInfo.
ir50_32: Add stub dll.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1301
With commit 1d1690782b167f3ea24990c260665f71a0e70d1c init_builtin_dll
gained a return value, alas the FreeBSD-specific code (under #ifdef)
was not adjusted and still returned void.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1509
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
v8: imm32: Prevent deadlock on unload
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
v7: imm32: Prevent deadlock on unload
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
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.
--
v17: 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
This is supposedly fixing some games (Age of Empires II Definitive Edition) but I must say that I don't remember in which circumstances this happens.
In any case the `get_process_image_name` request doesn't set any reply when `process->image` is NULL, and in which case it also doesn't set any error. Having an error status seems to be a correct fix.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1499
We need to make sure all (important) cleanup is finished when we exit DllMain,
otherwise we might already unload krnl386 and deadlock
Since we can't have a synchronous DestroyWindow, use an extra message
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
Code flow is like follows:
- DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread
- acquire loader lock
- send DLL_THREAD_DETACH to imm32
- - calls DestroyWindow on its window
- - WM_DESTROY is handled asynchonously!
- send DLL_THREAD_DETACH to krnl386.exe
- - TASK_ExitTask
- - try get win16 lock, is blocked by ime32
meanwhile, at ime32
- handles WM_DESTROY
- already have win16 lock from user32
- __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy
- LdrGetProcedureAddress (want CoRevokeInitializeSpy)
- try get loader_lock, is blocked
Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished.
--
v6: imm32: Prevent deadlock on unload
https://gitlab.winehq.org/wine/wine/-/merge_requests/1456
On Windows, application-specific settings are stored in the registry
under HKCU\Console\<path_to_app>.
Our implementation of conhost.exe does not know which process is
connected to it, so we need to get the full process image name before
loading any application-specific console settings.
To do this, we extend the server protocol to pass the process Id of
the connected console process to conhost.exe.
Please run tools/make_requests before merging.
--
v2: conhost: Load application-specific settings using the full process image name
https://gitlab.winehq.org/wine/wine/-/merge_requests/1492
On Windows, application-specific settings are stored in the registry
under HKCU\Console\<path_to_app>.
Our implementation of conhost.exe does not know which process is
connected to it, so we need to get the full process image name before
loading any application-specific console settings.
To do this, we extend the server protocol to pass the process Id of
the connected console process to conhost.exe.
Please run tools/make_requests before merging.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1492
This video codec is used by games such as Richman 4, and Zwei: The Arges Adventure.
The decoder logic is based on code from the FFmpeg project.
--
v3: loader/wine.inf: Enable ir50_32 video codec.
ir50_32: Implement decompression to 24-bit RGB.
ir50_32: Implement IV50_DecompressGetFormat.
ir50_32: Implement IV50_DecompressQuery.
ir50_32: Implement IV50_GetInfo.
ir50_32: Add stub dll.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1301
On Tue Nov 22 10:05:37 2022 +0000, Mohamad Al-Jaf wrote:
> Thanks for the detailed feedback and review @besentv and @rbernon. :)
No problem. I actually intend to expand the Wiki article on WinRT programming but I currently don't have much time.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1343#note_16909