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