On 2010-09-07 23:17, Garrett Serack wrote:
Howdy,
I can help out a bit here.
What you are seeing is the Windows Side-by-side technology at work here...
Unfortunately, the VC team didn't really use WinSxS the way they should, so
little issues like this tend to crop up all over the place.
Visual C++ automatically embeds information in the manifest that tells Windows which
version of the C++ libraries to link against (an individual version of these libraries
together are referred to as an "assembly"). VC++ looks at the most recent
version of the C++ libraries on the developer's system, and embeds that version in with
the executable. When the executable runs, it looks for that version (installed correctly
in the WinSxS system) and loads the DLLs from there.
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).
But [1] says the searching sequence for the private assembly is:
1. Side-by-side searches the WinSxS folder.
2. \\<appdir>\<assemblyname>.DLL
3. \\<appdir>\<assemblyname>.manifest
4. \\<appdir>\<assemblyname>\<assemblyname>.DLL
5. \\<appdir>\<assemblyname>\<assemblyname>.manifest
And I also found that manifest for redist CRT [2] has following lines:
<assemblyIdentity
type="win32"
name="Microsoft.VC80.CRT"
version="8.0.50608.0"
processorArchitecture="amd64"
publicKeyToken="1fc8b3b9a1e18e3b"
/>
but the version of msvcr80.dll in that folder is 8.0.50727.42
[1] http://msdn.microsoft.com/en-us/library/aa374224%28VS.85%29.aspx
[2] "C:\Program Files (x86)\Microsoft Visual Studio
8\VC\redist\amd64\Microsoft.VC80.CRT\Microsoft.VC80.CRT.manifest"
Now, the publisher of the library can issue updates to the library and 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.
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.
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 best bet, is to install the correct version of the VC Redist (links below)
on the target machine--this should enable the application to run correctly.
The .ZIP file should either include the VC++ redist that you need, or have a
readme.txt file that explicitly states which VC++ runtime to install and where
to get it.
The (somewhat) good news is that VC team has moved away from using WinSxS for VC++
2010 for their redistributables. The sad part is that they should have just fixed
their problem with WinSxS instead of not supporting it... but either way, it should
work better for VC++ 2010 than it did for 2005& 2008.
---
Note:
VC 2005 == VC8
VC 2008 == VC9
VC 2010 == VC10
[1] - I personally believe this is a critical mistake in VC++ ... IMO, the latest
binary-compatible version of the C++ runtime library should always be redirected to.
(This is a fundamental cornerstone of the CoApp project I'm working on...
http://coapp.org ) Personally, I believe that the VC++ redist should have always
included the binding policy to forward to the later version, and VC++ should have created
the manifest to specify the minimum compatable version (like, "8.0.0.0", and
have the binding policy forward everything to the latest installed version).
[2] - VC Redistributables:
x86:
VC 2005:
http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
VC 2005 SP1:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200B2FD9-AE1A-4A14-984D-389C36F85647&displayLang=en
VC 2008:
http://www.microsoft.com/downloads/details.aspx?familyid=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en
VC 2008 SP1:
http://www.microsoft.com/downloads/en/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en
VC 2010:
http://www.microsoft.com/downloads/details.aspx?familyid=A7B7A05E-6DE6-4D3A-A423-37BF0912DB84&displaylang=en
X64:
VC 2005:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=90548130-4468-4BBC-9673-D6ACABD5D13B&displayLang=en
VC 2005 SP1:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=EB4EBE2D-33C0-4A47-9DD4-B9A6D7BD44DA&displayLang=en
VC 2008:
http://www.microsoft.com/downloads/details.aspx?familyid=BD2A6171-E2D6-4230-B809-9A8D7548C1B6&displaylang=en
VC 2008 SP1:
http://www.microsoft.com/downloads/en/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en
VC 2010:
http://www.microsoft.com/downloads/details.aspx?familyid=BD512D9E-43C8-4655-81BF-9350143D5867&displaylang=en
Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I make the software you use better on
Windows.
-----Original Message-----
From: Regis [mailto:xu.re...@gmail.com]
Sent: Monday, September 06, 2010 12:26 AM
To: dev@harmony.apache.org
Subject: Windows 64-bit can't work on Windows 2003
I downloaded M14 build from
http://apache.freelamp.com//harmony/milestones/5.0/M14/apache-harmony-5.0-jre-r946978-windows-x86_64-snapshot.zip
unzip it on Windows server 2003 sp2 64 bit, and run java:
C:\regis\harmony-5.0-jre-946978\bin>.\java.exe
The system cannot execute the specified program.
But it works well on Windows 2008.
I googled and it seems the error is caused by can't find Visual C++ libraries.
The dependencies is defined by manifest file which is embedded in dll/exe. So I
checked manifest file in java.exe, CRT version is 8.0.50608.0, but CRT dlls
shipped with our build is 8.00.50727.42, is the difference cause this issue?
I have tried *not* to embed manifest file into dll/exe files (remove 'mt'
command from build script, and also remove all *.manifest files), and the build
without manifest files could work on Windows 2003, so I guess there must be
something wrong with manifest files, but they are generated by linker
automatically, I can't understand why they can't work. Does anyone have any
ideas?
--
Best Regards,
Regis.
--
Best Regards,
Regis.
