[Bug 28225] New: Wine refuses to load native MSVCP90.dll, and won't even say why.
http://bugs.winehq.org/show_bug.cgi?id=28225 Summary: Wine refuses to load native MSVCP90.dll, and won't even say why. Product: Wine Version: 1.3.27 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: skotlex(a)mailforce.net Back in version 1.3.26 wine was working correctly in the application I was using it for (Ragnarok Online, used to have platinum rating in the appDB), but since 1.3.27 wine cannot launch the application anymore. By default, it tries to use the built-in MSVCP90.dll, which is a no go because it has missing functions (already reported in bug #28215). However, the problem is when I try to force the native version to be used, wine will not load it, and it won't even give any explanation on why. WINEDLLOVERRIDES="msvcp90=n" WINEDEBUG=+loaddll wine ragnarok.exe Will print (relevant part): trace:loaddll:load_builtin_dll Loaded L"c:\\windows\\system32\\iphlpapi.dll" at 0x7e3e0000: builtin trace:loaddll:load_builtin_dll Loaded L"c:\\windows\\system32\\netapi32.dll" at 0x7e410000: builtin err:module:import_dll Library MSVCP90.dll (which is needed by L"C:\\ro\\ragnarok.exe") not found trace:loaddll:load_builtin_dll Loaded L"c:\\windows\\system32\\msvcrt.dll" at 0x7e340000: builtin trace:loaddll:load_builtin_dll Loaded L"c:\\windows\\system32\\msvcr90.dll" at 0x7e3c0000: builtin The file, msvcp90.dll, is in the same directory as the executable, and there is a Manifest for it as well (Microsoft.VC90.CRT.manifest): <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!-- Copyright (c) Microsoft Corporation. All rights reserved. --> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <noInheritable/> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b" /> <file name="msvcr90.dll" /> <file name="msvcp90.dll" /> <file name="msvcm90.dll" /> </assembly> According to winefile, the msvcp90.dll file I have has the following properties: Version: 9.0.21022.8 Size: 568832 Bytes FileVersion: 9.00.21022.8 InternalName: MSVCP90.DLL ProductVersion: 9.00.21022.8 One thing that jumps to the eye is the fact that the different version fields don't agree on whether it is 9.0.X, or 9.00.X, but that may be normal. What I don't find normal is the fact that wine doesn't give me any hint on what is wrong and why it cannot load that dll :/ I am guessing it is related to manifests, since the support for that went in in this Wine version. So, in summary, shouldn't wine print out an error message detailing why it failed to load a particular dll file? -- 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=28225 --- Comment #1 from Skotlex <skotlex(a)mailforce.net> 2011-08-29 11:52:09 CDT --- Oh, and before somebody suggests this, changing the version in the Manifest to "9.00.21022.8" doesn't change anything. -- 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=28225 --- Comment #2 from Alexandre Julliard <julliard(a)winehq.org> 2011-08-29 12:21:00 CDT --- If there's a global manifest it takes precedence over the local one. The load order only comes into play once the dll is located through the manifest. If you want to force native you'll have to install it globally. -- 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=28225 --- Comment #3 from Skotlex <skotlex(a)mailforce.net> 2011-08-29 13:22:58 CDT --- A global manifest? Probably that means the file ".wine/c/windows/winsxs/manifests/x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_deadbeef.manifest" which specifies the file msvcp90.dll, version "9.0.30729.4148"? If this is the case, isn't this a bug by itself? Programs that come packed with their own manifest do so EXACTLY to avoid loading the wrong version of a dll! If "Ragnarok.exe" comes with a manifest that specifies it should run version 9.0.21022.8 and wine comes and overrides that and tries use version 9.0.30729.4148 anyway, ISN'T THIS A BUG? O.O -- 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=28225 --- Comment #4 from Alexandre Julliard <julliard(a)winehq.org> 2011-08-29 13:42:40 CDT --- No. If there's a global manifest with a compatible version it's used first. That's how it's supposed to work. -- 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=28225 --- Comment #5 from Skotlex <skotlex(a)mailforce.net> 2011-08-29 14:08:30 CDT --- Ah, okay. As long as the version is compatible, I can understand that choice. STILL, I think the crux of my bug report is that wine is not being very informative about why a "native DLL" gives a not found error when the dll is staring at the user in the current working directory :S -- 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=28225 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> 2011-08-29 16:20:08 CDT --- If you have a builtin before a native in the path it will behave the same way and load the first one that is found. I don't think it would make sense to continue searching the path and load all possible dlls just to print that we are not going to use them anyway. -- 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=28225 NSLW <lukasz.wojnilowicz(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lukasz.wojnilowicz(a)gmail.co | |m --- Comment #7 from NSLW <lukasz.wojnilowicz(a)gmail.com> 2011-08-31 09:56:26 CDT --- *** Bug 28238 has been marked as a duplicate of this bug. *** -- 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=28225 --- Comment #8 from NSLW <lukasz.wojnilowicz(a)gmail.com> 2011-08-31 10:00:47 CDT --- (In reply to comment #4)
No. If there's a global manifest with a compatible version it's used first. That's how it's supposed to work.
Why local manifest isn't used if global manifest doesn't have required functions? -- 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=28225 --- Comment #9 from Skotlex <skotlex(a)mailforce.net> 2011-08-31 13:37:21 CDT --- When implementing the "windows behaviour", you have to consider the fact that Wine has a very non-windows-like option which allows you to specify DLL selecting priority. When a higher version manifest is picked, but the DLL selected by this manifest is not usable, it is equivalent to not having that DLL installed. Currently Wine will simply bail out, as if the installation is broken. You should uninstall that manifest or restore the DLL. This may not seem like common sense, but I can foretell there will be many bug reports concerning this issue in the future. When you select "DLL=native" and wine wants to force the built-in DLL (and fails because it can), that is against what users expect. Perhaps, when looking for the manifest file to use, you should check if the DLL is available. So before selecting the highest level version manifest, it should ensure that the DLL it is pointed to is selectable, if not, the manifest should be skipped and the next one in the hierarchy should be selected. But then again, this is just what I believe "most users" would expect Wine to behave like, regardless of what the official behaviour is documented to be. -- 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=28225 --- Comment #10 from Alexandre Julliard <julliard(a)winehq.org> 2011-08-31 16:31:50 CDT --- I'm not interested in investing lots of efforts and slowing down every dll load just to favor native dlls, particularly since there's a trivial workaround (install native globally). Our time is much better spent into improving the builtin so that the issue doesn't even arise. -- 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=28225 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |nerv(a)dawncrow.de --- Comment #11 from André H. <nerv(a)dawncrow.de> 2011-09-08 15:58:00 CDT --- closing wontfix -- 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=28225 François <francois.melchior(a)belgacom.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |francois.melchior(a)belgacom. | |net --- Comment #12 from François <francois.melchior(a)belgacom.net> 2012-03-21 08:39:19 CDT --- After having read all the comments I would like to share my totally personal definition of a bug in Wine: "If something works in Windows and not with Wine, then it is a bug"... But I can afford without problem that other people have other ideas! I also have a question: should those DLL like MSVCP90 be considered part of Windows? For instance this one seems to not be present in Windows 95, 98 and even Windows XP! -- 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=28225 --- Comment #13 from Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> 2012-03-21 23:28:56 CDT --- (In reply to comment #12) It doesn't matter if these dlls are part of Windows or not. Wine has several advantages over Windows (wineprefix being one of them). One can create complete custom environment for each application. Adding extra workarounds to slowdown everything just so you can install multiple applications into the same wineprefix makes no sense. -- 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=28225 --- Comment #14 from François <francois.melchior(a)belgacom.net> 2012-03-25 10:07:39 CDT --- (In reply to comment #13) Ok; I just want to clarify: the problem is not installing multiple apps in the same prefix, only one application! I have now read more about that Windows 'manifest' (fortunately found that webpage: http://omnicognate.wordpress.com/2009/10/05/winsxs/). I have then another question: why does Wine need to populate C:\Windows\WinSxS ? Doesn't the "normal" (old) way of finding DLL suffice for builtin libraries? Thanks. -- 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=28225 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry(a)baikal.ru --- Comment #15 from Alexandre Julliard <julliard(a)winehq.org> 2013-05-17 04:30:16 CDT --- *** Bug 33604 has been marked as a duplicate of this bug. *** -- 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=28225 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|dmitry(a)baikal.ru | -- 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=28225 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #16 from Fabian Maurer <dark.shadow4(a)web.de> --- *** Bug 42859 has been marked as a duplicate of this bug. *** -- 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 (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla