On 01/11/2010 06:43, Konstantin Kolinko wrote: > 2010/11/1 Mark Thomas <ma...@apache.org>: >> On 31/10/2010 13:13, kkoli...@apache.org wrote: >>> Modified: tomcat/tc6.0.x/trunk/STATUS.txt >>> --- tomcat/tc6.0.x/trunk/STATUS.txt (original) >>> +++ tomcat/tc6.0.x/trunk/STATUS.txt Sun Oct 31 17:13:51 2010 >>> @@ -230,12 +230,14 @@ PATCHES PROPOSED TO BACKPORT: >>> Allow 32-bit and 64-bit JDKs to be selected on 64-bit platforms >>> http://svn.apache.org/viewvc?rev=1027504&view=rev >>> +1: markt, mturk >>> - -1: >>> + -1: kkolinko: The function checkJava spawns a .bat file >>> + (ExecWait '"$R0.bat"'). It is visible as a flickering black window >>> + when I go from JRE selection page to the next page in TC7 installer. >>> kkolinko: merging r1027504 does not perform cleanly >> >> The not merging cleanly I can fix when I get a moment. The briefly >> displayed command window is trickier. I don't know if it can be hidden. >> I certainly see it happen reasonably frequently when I install all sorts >> of Windows software. At the moment, I view it as a necessary evil for >> being able to support installing to 32-bit JVMs on 64-bit platforms. >> >> If Garrett (the MS open source guy) is at ApacheCon I'll try and pester >> him to see if there is a better way (e.g. looking for a magic number in >> a .exe or .dll). If anyone has any better ideas please speak up. >> > > Some thoughts: > > 1. We do not need this check at all on a 32-bit OS.
Yep. Should be possible to avoid this check on a 32-bit OS. > 2. If the JRE is installed to its default location, there are > different locations for 32 bit and 64 bit programs. True, but not something we can depend on. We can't even be sure that the 64-bit JVM hasn't been installed to the default 32-bit location. > 3. I found the following: > [1] http://msdn.microsoft.com/en-us/library/ms973190.aspx > mentions System.Reflection.Module.GetPEKind That requires .NET and not every machine has installed the .NET runtime. I don't want to make having .NET a pre-requisite for a correctly operating installer. > 4. We can write a Java class and execute it with javaw.exe > System.getProperty("os.arch"); > [4] > http://stackoverflow.com/questions/807263/how-do-i-detect-which-kind-of-jre-is-installed-32bit-vs-64bit That could work. I quite like the look of the ExeDetect code. *If* we can get that working in NSIS then we can avoid starting up another process. Something else for me to work on at ApacheCon :) Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
