harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: Windows 64-bit can't work on Windows 2003
Date Wed, 08 Sep 2010 02:53:16 GMT
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:


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 

> 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, "", 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.regis@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,

View raw message