[Bug 34739] New: manual install of wine gecko gets in the wrong directory in Wow64 wine
http://bugs.winehq.org/show_bug.cgi?id=34739 Bug #: 34739 Summary: manual install of wine gecko gets in the wrong directory in Wow64 wine Product: Wine-gecko Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-gecko-unknown AssignedTo: jacek(a)codeweavers.com ReportedBy: roland65(a)free.fr Classification: Unclassified When installing the gecko msi package with : msiexec /i wine_gecko-2.21-x86_64.msi on a wine 1.6 WoW64 architecture, then the gecko files are installed in c:\windows\syswow64 directory instead of c:\windows\system32. Thus, 64 bits iexplore doesn't work in this architecture. Note that a manual install of wine_gecko-2.21-x86.msi goes correctly into c:\windows\syswow64. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34739 --- Comment #1 from Hans Leidekker <hans(a)meelstraat.net> 2013-10-16 04:15:35 CDT --- Is that 64-bit msiexec? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34739 --- Comment #2 from Roland Baudin <roland65(a)free.fr> 2013-10-17 01:12:29 CDT --- OK, I understand: misexec is in fact a shell script that calls the wine executable. So, msiexec /i wine_gecko-2.21-x86_64.msi is the same as: wine msiexec /i wine_gecko-2.21-x86_64.msi whatever the architecture. So in a WoW64 architecture, this calls 32 bits wine and not 64 bits wine. If I do: wine64 msiexec /i wine_gecko-2.21-x86_64.msi then the gecko files are correctly installed in c:\windows\system32 IMHO, the msixec shell should detect the current architecture and call the wine or wine64 executable appropriately. Thanks, RB -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34739 --- Comment #3 from Hans Leidekker <hans(a)meelstraat.net> 2013-10-17 02:42:38 CDT --- (In reply to comment #2)
OK, I understand: misexec is in fact a shell script that calls the wine executable. So,
It's not a shell script but a Windows executable that exists in both 32-bit and 64-bit flavors in a Wow64 build. I believe this problem occurs when someone starts a 32-bit winelib program on a 64-bit prefix from the command line or a script, so maybe we should just print a helpful warning message. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34739 --- Comment #4 from Austin English <austinenglish(a)gmail.com> 2013-10-17 05:23:22 CDT --- (In reply to comment #3)
(In reply to comment #2)
OK, I understand: misexec is in fact a shell script that calls the wine executable. So,
It's not a shell script but a Windows executable that exists in both 32-bit and 64-bit flavors in a Wow64 build.
I believe this problem occurs when someone starts a 32-bit winelib program on a 64-bit prefix from the command line or a script, so maybe we should just print a helpful warning message.
Yes, please. It's a very common problem. On that note, why does 'wine foo.exe' default to the 32-bit binary before the 64-bit binary, when in a 64-bit prefix? Why not: wine32 -> 'wine32' wine64 -> 'wine64' wine -> 'wine64', if 64-bit prefix, else just 'wine' I've searched around a bit, but haven't found an explanation. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34739 --- Comment #5 from Roland Baudin <roland65(a)free.fr> 2013-10-17 06:39:23 CDT --- (In reply to comment #3)
(In reply to comment #2)
OK, I understand: misexec is in fact a shell script that calls the wine executable. So,
It's not a shell script but a Windows executable that exists in both 32-bit and 64-bit flavors in a Wow64 build.
Wrong. Typing 'misiexec' on the command line launches the shell script /usr/local/bin/msiexec that executes 'wine msiexec'. This 'msiexec' shell script is installed with wine. There are two Windows executables /usr/local/lib64/wine/fakedlls/msiexec.exe and /usr/local/lib/wine/fakedlls/msiexec.exe, but they are not called by the 'msiexec' shell script. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
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.
https://bugs.winehq.org/show_bug.cgi?id=34739 --- Comment #7 from Austin English <austinenglish(a)gmail.com> --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=34739 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Hans Leidekker <hans(a)meelstraat.net> --- Fixed. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=34739 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #9 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 3.17. -- 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.
participants (1)
-
wine-bugs＠winehq.org