This allows using one single wineprefix, one wineserver and one single wine executable for running both arm and arm64 executables.
This setup actually has worked earlier; Ubuntu 22.04 packages Wine 6.0, where the wine32 + wine64 packages together end up working this way. However, since Wine 6.0, a couple of refactorings has broken this setup along the way; reinstate this way of working.
The new wow64 mode probably won't work on arm, as it's not easily possible to switch between 32 and 64 bit execution mode within a process, as far as I know, but the old wow64 mode is still a great convenience - especially considering distro-packaged use for users who aren't familiar with the particular quirks on this architecture.
--
v2: configure: Allow using --enable-win64 on aarch64
server: Include ARMNT as one of the supported architectures on aarch64
ntdll: Allow running arm/aarch64 in (old) wow64 mode
https://gitlab.winehq.org/wine/wine/-/merge_requests/7204
Startup and lock counts in native Windows are separate, and the lock count does not decrease when an async result is freed if the platform has been started.
--
v4: rtworkq: Introduce an async result object cache.
rtworkq: Introduce a platform startup count.
rtworkq/tests: Test work queue.
mfplat/tests: Test platform startup and lock counts.
mfplat/tests: Test mixing of MF platform functions with their Rtwq equivalents.
mfplat/tests: Introduce a helper to check the platform lock count.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7174
--
v4: server: When renaming, only fstat the source once.
server: Remove source when renaming to a hardlink of itself.
kernel32/tests: Test renaming a file into a hardlink of itself.
kernel32/tests: Use FindClose instead of CloseHandle when closing
https://gitlab.winehq.org/wine/wine/-/merge_requests/6855
* * *
BTW I did try to create tests to make sure we connect collection the same way Windows does it. Problem is `GUID_ConnectToDLSCollection` is not gettable. Then I tried to create a `IDirectMusicPerformance` implementation and intercept `DownloadInstrument`. Interestingly Windows `IDirectMusicSegment::Download` doesn't call `DownloadInstrument` at all, instead it downloads instruments through a private, undocumented interface. So there seems to be no way to test this.
--
v2: dmimi: Connect default collection to MIDI bandtrack.
dmime: Handle IStream EOF correctly in MIDI parser.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7230