https://bugs.winehq.org/show_bug.cgi?id=34739 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Version|unspecified |1.7.4 Component|wine-gecko-unknown |msi CC| |focht(a)gmx.net Assignee|jacek(a)codeweavers.com |wine-bugs(a)winehq.org Ever confirmed|0 |1 Product|Wine-gecko |Wine Severity|major |normal --- Comment #6 from Anastasius Focht <focht(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.