[izpack-devel] Finding Default InstallationDirectory forProgramsunder Windows

[Markus Schlegel]

Hi Klaus
 
I think you missunderstood me a little bit. I do not claim about the code " that it is badly designed" or something similar.
I program in Java since 1996, so I know the issues that where there in the early stages of java (and some of them are still there :-(
 
To introduce myself:
- I work at Pulinco (www.pulinco.com) near Bern in Switzerland.
- I've studied Computer Sciences in the "Biel School of Engineering" from 1995 until 2000
- I work on a Product called "TopEase XBench" since 2001
- We used InstallAnywhere until now and are looking for an alternative Installer since the Future of InstallAnywhere is very unclear (merger of zerog with InstallShield, no support for Windows Vista yet)
 
Anyway, when you talk about Java1.1.8, I read in the docs, that I should compile IzPack with a Target JDK of 1.4 .
But what is the minimum Java Version that izPack is meant to run on? Do I have to compile for 1.2 (or even older) class compatibility? This is useful information, if I have to send you patches as you know.
 
What would be interesting is, if someone (maybe I ?) has to cleanup the code or the documentation for that "TargetFactory.getDefaultInstallPath" and/or "TargetPanel.dir" which ?
 
Markus

________________________________

Von: izpack-devel-bounces at lists.berlios.de im Auftrag von Bartz, Klaus
Gesendet: Di 28.11.2006 12:27
An: izpack-devel at lists.berlios.de
Betreff: Re: [izpack-devel] Finding Default InstallationDirectory forProgramsunder Windows


Hi Markus,
in the meantime I agree with you that IzPack should also find the right default path
for applications on boxes with WindowsXP.
Last time we have discussed a little bit about the best way. 
I am waiting for a WSH script from you until yet...But I agree with you, that a simple environment
variable usage will be more robust, if the setting is common. I agree also, that it should have 
the old behavior as fallback. It should be no problem to check the existent of the variable,
check the existent of the given path and so on. 
You sad, you will create a patch for InstallerBase. Nice, I will wait now for this.
You know patch as diff -u or as patch file.
To the other points of your email I can see only less because the code was not written by me.
May be it is quite adventurous or the usage was very uncommon, but I think the developer has 
thougth something about it. You know, the code is a little bit older.  Do you ever worked 
with Java 1.1.8 on Windows 95?
 
As I sad, I am waiting for your patch (that with the environment variable)
 
Cheers
 
Klaus
 
 

	-----Original Message-----
	From: izpack-devel-bounces at lists.berlios.de [mailto:izpack-devel-bounces at lists.berlios.de]On Behalf Of Markus Schlegel
	Sent: Tuesday, November 28, 2006 11:33 AM
	To: izpack-devel at berlios.de
	Subject: [izpack-devel] Finding Default InstallationDirectory for Programsunder Windows
	
	
	Hi
	I already posted this issue on the User mailinglist.
	 
	The current official Release (3.9.0) does not read out the ProgramFiles Folder from Windows. Instead it is read from a Properties file according to the current Language on the system.
	 
	On International Installations of Windows with LanguagePack != English, this fails always. Outside English-spoken countries, the international Version of WindowsXP is the Quasi-Standard for Companywide Installations of Windows.
	 
	On such Systems, the Programfiles Folder is "Program Files" per default, no matter which languagepack is installed (so you have a german system with "C:\Program Files" as the Programs folder.
	 
	I made a patch now, which tries to read the Environmentvariable "ProgramFiles" in the class "InstallerBase". If it fails or is not defined, it falls back to the current implementation, which is sufficient for older (pre W2K) systems (even if it is quite adventurous to derive the drive letter from the user's home path). I took the Environmentvariable instead of the Registry Key because reading out the registry Key requires further classes and components.
	 
	What is left as a todo is the fact, that there is a Class called "TargetFactory" with a Method "getDefaultInstallPath" which is in fact never called. The Documentation states, that one can define a default installationdirectory using the resource "TargetPanel.dir". Due to the Fact, that "TargetFactory.getDefaultInstallPath" is never called, the setting of TargetPath.dir has never an effect!
	 
	What should be the desired Functionality? Should the Value from "TargetPanel.dir" overwrite the System default if defined? Is this feature ever used (its very uncommon to do this when packaging the installer)?
	 
	Regards
	Markus Schlegel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 10078 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/izpack-devel/attachments/20061128/5ce6cee5/attachment.bin