harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Windows 64-bit can't work on Windows 2003
Date Tue, 07 Sep 2010 19:10:44 GMT
Thanks for the explanation Garrett.  I have some further
questions/comments below.

On 07/Sep/2010 16: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").  

So when Regis wrote:
  "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"

that implies our build script did not package the same version of DLL as
the linker found and linked against, right?

> VC++ looks at the most recent version of the C++
> libraries on the developer's system, and embeds that version in with
> the executable.

Hmm, Regis says the manifest called for 8.0.50608.0 but the version we
shipped was 8.00.50727.42 -- implying the version we packaged *was* a
more recent version found on the developer's system.

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

And therein lies the problem I suspect.

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

We are putting the crt's into the package at the moment.  I agree
carrying around our own copy is not what we 'really really' want but...

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

...this option requires we have a more prominent readme or equivalent
that says "You need to run this installer before our code will work",
which also is not what we 'really really' want either.

On balance I think I'd prefer to take the crt with me.  If we remove the
Manifests then I assume we lose some important benefits too though.

Regards,
Tim

> 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