Because WINENV is limited (32767 bytes), and HOSTENV can be much larger,
a whitelisting approach is used to keep WINENV as small as possible.
Currently, only the following envvars are propagated from the host env to WINENV
WINEPATH, WINEPWD, WINEHOME, WINETEMP, WINETMP, WINEQT_, WINEVK_, WINEXDG_SESSION_TYPE
Moreover, the NIXENV (env for running wine processes - not applications) on the
host system is not produced from WINENV anymore, but the global ENV
is propagated to all wine processes and threads.
This might be an alternative approach to MR!5231, MR!6140, bug #56941
and should provide a more deterministic behaviour of wine, because unrelated
envvars do have no influence on the env for running windows applications.
Initial tests (winemine, notepad, cmd, etc) seem to run fine, but some envvars might need additional
consideration. XVDK_* was mentioned, WINE*, MESA_*, VK_*, QT_*, LIBGL_* are other suspects.
Moreover, this is my first merge request, so your feedback is highly appreciated.
--
v23: ntdll: main_envp has been replaced by environ
ntdll: remove is_dynamic_env_var(...) because it is not needed anymore
ntdll: remove unused vars
ntdll: remove dead code
ntdll: conversion from HOSTENV to WINENV is now using whitelisting instead of blacklisting of envvars currently only envvars "WINE"<special_var> (as defined in is_special_env_var() ) are whitelisted.
ntdll: separate env for windows applications (WINENV) from env for wine processes (NIXENV) WINENV is typically limited to 32767 WCHAR, the host environment where wine processes are running can be much larger. Keeping the two envs separate enables a more granula handling of envvars. (see also MR!5231, MR!6140, bug #56941)
https://gitlab.winehq.org/wine/wine/-/merge_requests/6166
After an X11 event handler queues messages to another thread, TRUE should be returned and eventually
propagated to X11DRV_ProcessEvents().
When FALSE is always returned in xrandr14_device_change_handler(), a possible hang can happen for
the desktop message queue as follows:
1. The explorer.exe calls GetMessageW() -> NtUserGetMessage() -> wait_objects() -> wait_message().
2. In wait_message(), user_driver->pProcessEvents() gets called in the desktop window thread to
handle RRNotify events and calls xrandr14_device_change_handler() -> display_mode_changed(FALSE)
-> send_message(get_desktop_window(), WM_DISPLAYCHANGE, ...) -> desktop_window_proc() ->
send_message_timeout() -> send_client_message() -> process_message() -> broadcast_message() ->
send_message_timeout() -> send_client_message() -> process_message() -> send_inter_thread_message()
-> wait_message_reply() -> a server set_queue_mask() with skip_wait being 1 -> wake_mask and
changed_mask are set to 0.
3. In wait_message(), user_driver->pProcessEvents() returns FALSE from xrandr14_device_change_handler().
So wait_message() continues to call NtWaitForMultipleObjects().
4. Now NtWaitForMultipleObjects() hangs for INFINITE timeout because wake_mask and changed_mask
for the message queue are set to 0 so the thread is not woke up.
The hang is sensitive to message ordering and only happens in this specific case so it's hard to
reproduce with tests. I believe some of the past test timeouts on TestBots can be attributed to this
bug.
--
v2: winex11.drv: Fix a possible desktop window message queue hang.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5890
Performance issues can occur when a video output sample has a 2D buffer,
because winegstreamer currently outputs only to a linear buffer, which
must then be copied into the 2D buffer. Worse, a linear lock of the 2D
buffer requires the current contents to be copied to a linear buffer,
even when we intend to overwrite it, because MF linear buffers do not
support write-only locking.
--
v4: mf/tests: Test H.264 sink media type height alignment.
winegstreamer: Support 2D sample buffer.
mf: Test color convert 2D buffers.
mf: Test WMV decoder 2D buffers.
mf: Test H.264 decoder 2D buffers.
mf: Test sample copier 2D buffers.
mfplat/tests: Test NV12 negative stride in MFCreateMediaBufferFromMediaType().
mf/tests: Remove todo for an H.264 decoder test.
mf/tests: Stop checking samples at the end of the expected array.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8812
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57343
This is what the Java JRE installer does:
- It calls MsiInstallProductW - this opens the msi read/write
- The msi runs installer.exe
- installer.exe tries to open the msi readonly
--
v2: msi: Make MsiInstallProductW open msi readonly
msi/tests: Add test for MsiOpenDatabaseA during MsiInstallProductA
https://gitlab.winehq.org/wine/wine/-/merge_requests/6760
This should allow the CI to fully pass on this merge request.
If it does, master branch could have CI tests enabled to ensure
any actual broken test caused by a merge request is visible just
by the CI status, and master can also reflect the passing status.
Signed-off-by: Damien Zammit <damien(a)zamaudio.com>
--
v2: test-linux32: Disable broken tests that are already released broken
https://gitlab.winehq.org/wine/wine/-/merge_requests/7410