harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Serack <garre...@microsoft.com>
Subject RE: Windows 64-bit can't work on Windows 2003
Date Wed, 08 Sep 2010 14:09:34 GMT
Howdy,

GS > With the manifest in place, it will *not* try to load the DLLs from the local directory
(this is done to prohibit tampering of shared libraries).

Regis >But [1] says the searching sequence for the private assembly is:
Regis >
Regis >    1. Side-by-side searches the WinSxS folder.
Regis >    2. \\<appdir>\<assemblyname>.DLL
Regis >    3. \\<appdir>\<assemblyname>.manifest
Regis >    4. \\<appdir>\<assemblyname>\<assemblyname>.DLL
Regis >    5. \\<appdir>\<assemblyname>\<assemblyname>.manifest
Regis >

So, just to be clear, the <assemblyname> is not the same as the DLL name.
== This is where WinSxS gets *really* complicated. == 

With WinSxS, an "Assembly" is a collection of *one or more* files specified by a manifest.

The <assemblyname>  is often == to a DLL name, but there is no requirement for this
to be true.

the <assemblyname> in this case is "Microsoft.VC80.CRT".
    
When WinSxS looks for local (private) assemblies, it's looking for either:
    a DLL called "Microsoft.VC80.CRT.DLL" with a manifest resource or 
    an XML manifest file called "Microsoft.VC80.CRT.manifest"
that tells WinSxS about the files (dlls) in the manifest.

The assembly manifest (not to be confused with the application manifest) describes the contents
of the assembly. 
In the case of the VC runtime, the manifest actually contains three DLL files:
    msvcr80.dll    
    msvcp80.dll
    msvcm80.dll

Regis >And I also found that manifest for redist CRT [2] has following lines:
Regis >
Regis >     <assemblyIdentity
Regis >         type="win32"
Regis >         name="Microsoft.VC80.CRT"
Regis >         version="8.0.50608.0"
Regis >         processorArchitecture="amd64"
Regis >         publicKeyToken="1fc8b3b9a1e18e3b"
Regis >     />
Regis >
Regis >but the version of msvcr80.dll in that folder is 8.0.50727.42
Regis >
Regis >[1] http://msdn.microsoft.com/en-us/library/aa374224%28VS.85%29.aspx
Regis >
Regis >[2] "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\redist\amd64\Microsoft.VC80.CRT\Microsoft.VC80.CRT.manifest"
Regis >

To be clear, just because you have version 8.0.50727.42 installed, does not mean that the

binding policy redirecting 8.0.50608.0 to that newer version is installed.

** In My Opinion ** this should be the norm, but the VC++ team thought otherwise at the time.

To check if you have the Binding Policy installed, there will be a a file 
somewhere deep inside the c:\Windows\WinSxS folder with a name like

    "amd64_policy.8.0.microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.42_none_1492cce54f6d20f0.manifest"

On Win2k3/XP the naming is different than on Vista and beyond, so I can't tell off the top
of my head.
It should have "amd64" , "policy" , "8.0" , "microsoft.vc80.crt" in the filename.

If you have that file (which I suspect you don't) it would redirect requests for "8.0.50608.0"
to "8.0.50727.42".

To get the Binding Policy, I believe the EXE installer of the 8.0.50727.42 needs to be installed.

GS >
GS > Now, the publisher of the library can issue updates to the library and 
GS > redirect binding at runtime. This is done with what's called a "Binding Policy" in
a "Publisher Configuration File". (Essentially, this policy tells the OS to redirect requests
from a version range to a different version).  Now, the tricky part is, depending on how the
newer version of the library got installed, the policy may or may not have been included.
When the VC++ libraries are installed as part of a merge module (.msm) in an MSI installer,
they don't redirect old versions of the library to the new one (the idea being that you don't
neccesarily want old apps pointing to the new runtime[1]).  I believe if the VC++ redistributable
(by installer [2]) is installed, it does install the new Binding Policy.
GS >
GS > By removing the Manifest, the OS just looks in the local directory for the libraries--this
is not what you really really want--you'd need to include the VC++ runtimes in the application
directory with the redistribution of Harmony itself.
GS >
Regis > Does it mean if we include the VC++ runtimes in Harmony local directory and expected
it is used at runtime, we have to removing the manifest?

The *proper* way to include the runtimes in your local directory would be to place the manifest
there (as <appdir>\Microsoft.VC80.CRT.manifest) and the files alongside it.

The *easy* way is to remove the assembly reference from your exe's manifest. 

Garrett
Mime
View raw message