This is a cleanup in preparation for !7. Originally, !7 extended the use of `current_modref`, but I think we could avoid that with a more direct approach. Most of these changes are no-ops.
For the relay handler, we no longer treat `GetProcAddress` calls inside `DllMain` as coming from a loaded DLL. I believe this was more of a side effect of how the code was structured rather than an intentional behavior that needs to be preserved.
One more use of `current_modref` remains, which will be removed by !7.
--
v4: ntdll: Remove no longer needed current_modref.
ntdll: Use NULL importer in LdrGetProcedureAddress.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7287
This is a cleanup in preparation for !7. Originally, !7 extended the use of `current_modref`, but I think we could avoid that with a more direct approach. Most of these changes are no-ops.
For the relay handler, we no longer treat `GetProcAddress` calls inside `DllMain` as coming from a loaded DLL. I believe this was more of a side effect of how the code was structured rather than an intentional behavior that needs to be preserved.
One more use of `current_modref` remains, which will be removed by !7.
--
v3: ntdll: Remove no longer needed current_modref.
null: Use NULL importer in LdrGetProcedureAddress.
ntdll: Pass importer pointer to build_import_name.
ntdll: Pass importer pointer to find_forwarded_export.
ntdll: Pass importer pointer to find_named_export.
ntdll: Pass importer pointer to find_ordinal_export.
ntdll: Pass WINE_MODREF to import_dll.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7287
This is a cleanup in preparation for !7. Originally, !7 extended the use of `current_modref`, but I think we could avoid that with a more direct approach. Most of these changes are no-ops.
For the relay handler, we no longer treat `GetProcAddress` calls inside `DllMain` as coming from a loaded DLL. I believe this was more of a side effect of how the code was structured rather than an intentional behavior that needs to be preserved.
One more use of `current_modref` remains, which will be removed by !7.
--
v2: ntdll: Remove no longer needed current_modref.
null: Use NULL importer in LdrGetProcedureAddress.
ntdll: Pass importer pointer to build_import_name.
ntdll: Pass importer pointer to find_forwarded_export.
ntdll: Pass importer pointer to find_named_export.
ntdll: Pass importer pointer to find_ordinal_export.
ntdll: Pass WINE_MODREF to import_dll.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7287
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
This is a bit convoluted because of the amount of pieces involved. I'll
try to untangle things a bit.
The container id is meant to be globally unique and stable. We therefore
need a suitable amount of stable entropy that we can feed into a hash
function to get a stable and unique output.
This happens in winebus. The corner stone of hash inputs is the linux
device topology (sysfs path) obtained via udev. Along with all other
possible data we feed this into a hash function to obtain our container
id.
A bunch of extra wine-specific keys needed to be added to carry the
necessary metadata from the driver into the ntoskrnl (where it gets
written to the property registry of the relevant device).
Separate from this we also ingest the linux device topology (sysfs path)
in the winepulse driver.
In mmdevapi we then use winepulse's sysfs path to find the matching
device in the setupapi and query its container id. We now have the same
container id in both the device and the MMDevice, allowing applications
(in particular Games) to find the MMDevice for a given device.
For practical reasons we always resolve the sysfs path to the root
device as early as possible. Container ids are meant to be equal for sub
devices inside a "container" anyway.
--
v3: winebus,mmdevapi: implement audio device container id
https://gitlab.winehq.org/wine/wine/-/merge_requests/7238