tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1029423 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
Date Mon, 01 Nov 2010 10:58:40 GMT
On 01/11/2010 06:43, Konstantin Kolinko wrote:
> 2010/11/1 Mark Thomas <>:
>> On 31/10/2010 13:13, 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
>>>    +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]
> 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]

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message