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@codeweavers.com ReportedBy: roland65@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.
http://bugs.winehq.org/show_bug.cgi?id=34739
--- Comment #1 from Hans Leidekker hans@meelstraat.net 2013-10-16 04:15:35 CDT --- Is that 64-bit msiexec?
http://bugs.winehq.org/show_bug.cgi?id=34739
--- Comment #2 from Roland Baudin roland65@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
http://bugs.winehq.org/show_bug.cgi?id=34739
--- Comment #3 from Hans Leidekker hans@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.
http://bugs.winehq.org/show_bug.cgi?id=34739
--- Comment #4 from Austin English austinenglish@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.
http://bugs.winehq.org/show_bug.cgi?id=34739
--- Comment #5 from Roland Baudin roland65@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.
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
https://bugs.winehq.org/show_bug.cgi?id=34739
--- Comment #7 from Austin English austinenglish@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?
https://bugs.winehq.org/show_bug.cgi?id=34739
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #8 from Hans Leidekker hans@meelstraat.net --- Fixed.
https://bugs.winehq.org/show_bug.cgi?id=34739
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 3.17.
-
wine-bugs＠winehq.org