You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2010/11/01 03:18:06 UTC
Re: svn commit: r1029423 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
On 31/10/2010 13:13, kkolinko@apache.org wrote:
> Modified: tomcat/tc6.0.x/trunk/STATUS.txt
> URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1029423&r1=1029422&r2=1029423&view=diff
> ==============================================================================
> --- 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1029423 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 11/1/2010 5:58 AM, Mark Thomas wrote:
> On 01/11/2010 06:43, Konstantin Kolinko wrote:
>> 2010/11/1 Mark Thomas <ma...@apache.org>:
>>> On 31/10/2010 13:13, kkolinko@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 of this lives in apr_thread_proc.c for win32 in apr. Will be happy
to offer pointers when I arrive.
>> 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.
I wouldn't, some people will pre-stage things on a 32 bit machine to prepare
for mass copy to 64 bits. Odd edge case but one to consider.
>> 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.
Hmmm, I believe every now-current version does have some minimum level of both
vbscript, wsh script and .net.
There is a way to do this in C that is pretty straightforward. The choice
could easily be propagated to the microsoft system installer (MSI), but you
do get into the scenario where both JVMs are installed on a machine.
Fortunately these are not side by side as on solaris and similar.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1029423 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/11/1 Mark Thomas <ma...@apache.org>:
> On 01/11/2010 06:43, Konstantin Kolinko wrote:
>>
>> 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.
>
2010/11/1 William A. Rowe Jr. <wr...@rowe-clan.net>:
>
> I wouldn't, some people will pre-stage things on a 32 bit machine to prepare
> for mass copy to 64 bits. Odd edge case but one to consider.
Installing something that they cannot run? I would not consider that.
Anyway, 1) it never worked before, 2) one can use a zip distributive
>> 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.
>
I think it boils down to reading a PE header.
The Wikipedia article has links to the specifications.
http://en.wikipedia.org/wiki/Portable_Executable
I can summarize them as the following:
1. Jump to offset 0x3c and read there the location of PE header.
2. Jump to the specified location. The header starts with 4 bytes
'P''E'\0\0' (50 45 00 00)
3. The next word of two bytes gives the machine type. It is
0x014c (4C 01) for Intel i386
0x8664 (64 86) for AMD 64
0x0200 for Intel Itanium
>> 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
>
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1029423 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
Posted by Mark Thomas <ma...@apache.org>.
On 01/11/2010 06:43, Konstantin Kolinko wrote:
> 2010/11/1 Mark Thomas <ma...@apache.org>:
>> On 31/10/2010 13:13, kkolinko@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1029423 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/11/1 Mark Thomas <ma...@apache.org>:
> On 31/10/2010 13:13, kkolinko@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.
2. If the JRE is installed to its default location, there are
different locations for 32 bit and 64 bit programs.
3. I found the following:
[1] http://msdn.microsoft.com/en-us/library/ms973190.aspx
mentions System.Reflection.Module.GetPEKind
Searching for "GetPEKind" gives some more pointers
[2] http://www.geekpedia.com/Thread27309_How-Do-I-Tell-If-A-DLL-Is-X86-X64-Or-AnyCpu.html
[3] http://stackoverflow.com/questions/480696/how-to-find-if-native-dll-is-compiled-as-x64-or-x86
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
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org