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 Tue, 07 Sep 2010 15:17:35 GMT
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).

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.

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.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.

Mime
View raw message