https://bugs.winehq.org/show_bug.cgi?id=34739
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Version|unspecified |1.7.4 Component|wine-gecko-unknown |msi CC| |focht@gmx.net Assignee|jacek@codeweavers.com |wine-bugs@winehq.org Ever confirmed|0 |1 Product|Wine-gecko |Wine Severity|major |normal
--- Comment #6 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming, still present.
Actually this has nothing to do with Wine-Gecko itself. It's a dupe of existing 32-bit/64-bit MSI client-server separation bugs.
The MSI client side bitness doesn't matter here (can be 32-bit or 64-bit). In the end the product install is always handed over to the 64-bit Windows Installer Service (this is how Windows handles it).
The "magic" lies in the default process processing of all package elements. All elements are always assumed to be 32-bit unless marked otherwise, e.g. the package authoring tool explicitly used 'System64Folder' and the like. This allows a single 64-bit MSI package to install both, 32-bit and 64-bit elements.
I looked into the package with ORCA and the folder paths are correctly authored ('GECKODIR' -> 'System64Folder').
Regards