Currently usr1_handler always delivers the context to server. With AVX enabled the single context size is around 1k (while there are two of those for wow64). I am now working on a more generic xstate support in contexts (mostly motivated by AVX512), with AVX512 the single context to be transferred to server is ~1k bigger.
The context is needed to be passed to the server from usr1_handler only for NtGetContextThread, NtSetContextThread and NtSuspendThread handling (e. g., when stop_thread is called on the server). The vast majority of usr1_handler usage is for kernel APCs (e. g., APC_ASYNC_IO involved in every async operation) that don't need the thread context transferred to the server and back.
My measurements of single SERVER_START_REQ( select ) in server_select() shows that the turnaround time of the request with the context (on native x64 without wow context) is almost two times bigger on average when currently supported AVX context is involved (that is, on every usr1_handle invocation on a machine supporting AVX). So, this patch is expected to increase the time of relatively rare calls which actually need contexts by roughly 50% but decrease the turnaround time of frequent calls involving system APCs by 50%. The difference will be more in favour of this patch once huge AVX512 contexts are added.
--
v3: ntdll: Avoid sending context in wait_suspend() when not required.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4914
--
v2: testtmp
dinput: Once again support creating joystick device with GUID_Joystick.
dinput: Derive DIPROP_JOYSTICKID from device path enumeration.
dinput/tests: Add tests for joystick id.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6878
The offending font is NotoColorEmoji.ttf which is present in, e. g., google-noto-emoji-color-fonts or noto-fonts-emoji packages available in various distribution. Attempting to load this font on Windows 10 (with AddFontResourceA() or open it with default font viewer) fails while currently succeeds on Windows. fontforge also refuses to open this font. That is because the font is bitmap only but missing bitmap table.
Some apps (Glyph launcher is an example) try to GetOutlineTextMetrics() on this font and do not expect that to have an error return (as we currenly do), which leads to crash on unhandled division by zero exception.
I am attaching a bitmap-only ttf test font (with only one bitmap) which I created with fontforge to make sure that such font can still be loaded in Wine. This font also loads on Windows (both with AddFontResourceA() and with default font viewer).
There are other font types which can be legitimately missing EBDT table, but FT_Load_Sfnt_Table() returns a different error for those and my patch doesn't reject those fonts.
[test.ttf](/uploads/b41472180b80c2c53f9dcc06055990f0/test.ttf)
--
v2: win32u: Don't load bitmap only TTF fonts without bitmap table.
https://gitlab.winehq.org/wine/wine/-/merge_requests/411
I think the behaviour of SetWindowPos() in this case is partially explained by the fact that topmost state is not strictly applicable to child windows and so Windows denies such requests. Child window can still end up with WS_EX_TOPMOST style if it was set at window creation (doesn't work this way in Wine now) or, e. g., like in the test added in the patch.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=20190
Also fixes game load dialog in Indiana Jones and the Infernal Machine.
--
v2: win32u: Ignore SetWindowPos() if it is trying to change topmost state for child window.
https://gitlab.winehq.org/wine/wine/-/merge_requests/667
Fixes The Rising of The Shield Hero: Relieve the Animation hangs on start (and maybe something else with ENIGMA protector).
The protector implements virtual file system which hotpatches a lot of file related functions, in particular, NtOpenFile(). When NtOpenFile() is called from RtlSetCurrentDirectory_U() with peb lock held the hotpatcher takes its own lock and that can deadlock with other threads performing file / path operations ending up in get_full_path_helper() which also takes PEB lock. Once the hotpatcher is initialized the game only sets "." or the same full path as current and may do that rather often.
It seems that reopening the file handle for the same directory is redundant anyway, so probably makes sense to just avoid that part.
--
v5: ntdll: Do not open directory file when setting the same directory path.
https://gitlab.winehq.org/wine/wine/-/merge_requests/256
The `Allocate` method has two variants:
* Allocate(size_t): Performs a normal allocation, but throws a COMException on OOM.
* Allocate(ptrdiff_t offset, size_t size): Allocates a block of size `size`, and initializes a control block for an `IWeakReference` at `offset`. The weak reference resolves to the allocated object, which can finally be freed by calling `ControlBlock::ReleaseTarget`.
The IWeakReference implementation seems to be rather odd, which I have tried to demonstrate (and test) in the unit tests:
* `ReleaseTarget` only frees the object if the strong ref count is _below_ 0.
* `IWeakReference::Resolve` will _not_ set the output pointer to `NULL` if the weak reference is no longer alive.
This MR implements these functions sans exception support.
--
v3: vccorlib140: Implement Platform::Details::{Allocate(ptrdiff_t, size_t), ControlBlock::ReleaseTarget}.
vccorlib140: Add stub for Platform::Details::{Allocate(ptrdiff_t, size_t), ControlBlock::ReleaseTarget}.
vccorlib140: Add semi-stub for Platform::Details::Heap::{Allocate, Free}.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8774
Commit 518e394794160818ffe6826c874ff2f550c95bbb introduced new and important default behavior for PE binaries built using `winegcc`/`wineg++`/`winebuild`.
* `/DYNAMICBASE` - Generates an executable image that can be randomly rebased at load time by using the address space layout randomization (ASLR) feature of Windows that was first available in Windows Vista.
* `/HIGHENTROPYVA` - Randomized 64-bit virtual addresses make it more difficult for an attacker to guess the location of a particular memory region.
... however as identified in https://bugs.winehq.org/show_bug.cgi?id=58480, this new default behavior can severely impact applications that interact with binaries created for Windows XP and older. This is quite common for legacy audio plugins, such as VST2(TM) plugins.
This MR keeps the new default "dynamicbase" and "highentropyva" flags by default, but mirrors the mingw/msys2 `--disable-dynamicbase` flag as explained here: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default. MSVC also provides a similarly named flag [here](https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase).
Downstream, the LMMS project has successfully deployed the mingw flag and the MSVC flag for our Windows builds. Our Linux builds use a custom wine-bridge and would benefit from the same.
We've currently tested this MR downstream against a snapshot of master branch to passing results.
Downstream PRs:
* Linux: https://github.com/LMMS/lmms/pull/7987
* Windows: https://github.com/LMMS/lmms/pull/7976
--
v4: Revert HIGHENTROPYVA flag
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786
--
v3: wineusb.sys: Print a warning for unhandled IRP_MN_QUERY_DEVICE_TEXT text types.
winebth.sys: Print a warning for unhandled IRP_MN_QUERY_DEVICE_TEXT text types.
hidclass: Print a warning for unhandled IRP_MN_QUERY_DEVICE_TEXT text types.
winebus: Handle IRP_MN_QUERY_DEVICE_TEXT.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8770
This pull request fixes Wine's MIDI synthesizer reset process to be the same as Windows'.
When playing Touhou Project games in MIDI BGM mode, the music playback becomes buggy when the BGM changes.
The video below is an example of an anomaly that occurs when playing The Fantastic Tales from Tono after playing Crystallized Silver in Touhou 7.
https://youtu.be/O69sndJ45Ag
Here's a correct example of The Fantastic Tales from Tono playback:
https://youtu.be/XlFAQEbbNDg?list=RDXlFAQEbbNDg
Piano sound is clearly missing on Wine.
This issue occurs due to an Wine's incorrect reset process for MIDI synthesizer.
When I ran FluidSynth on Windows and checked the log, I found that CC123 and CC121 were executed for each MIDI channel when switching songs.
CC123 means All Notes Off, CC121 means Reset All Controllers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8808