[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: [e-mail]
        ReportedBy: [e-mail]

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?

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #1 from Skotlex  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.

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #2 from Alexandre Julliard  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.

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #3 from Skotlex  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

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #4 from Alexandre Julliard  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.

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #5 from Skotlex  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

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #6 from Alexandre Julliard  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.

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

NSLW  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]
                   |                            |m

--- Comment #7 from NSLW  2011-08-31 09:56:26 CDT ---
*** Bug 28238 has been marked as a duplicate of this bug. ***

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #8 from NSLW  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?

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #9 from Skotlex  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.

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #10 from Alexandre Julliard  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.

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

André H.  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED
                 CC|                            |[e-mail]

--- Comment #11 from André H.  2011-09-08 15:58:00 CDT ---
closing wontfix

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

François  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |francois.melchior@belgacom.
                   |                            |net

--- Comment #12 from François  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!

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #13 from Vitaliy Margolen  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.

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

--- Comment #14 from François  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.

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #15 from Alexandre Julliard  2013-05-17 04:30:16 CDT ---
*** Bug 33604 has been marked as a duplicate of this bug. ***

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

http://bugs.winehq.org/show_bug.cgi?id=28225

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|[e-mail]            |

[Bug 28225] Wine refuses to load native MSVCP90.dll, and won't even say why.

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=28225

Fabian Maurer  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #16 from Fabian Maurer  ---
*** Bug 42859 has been marked as a duplicate of this bug. ***