How to customize uA Program Files directory?

[Cartoonite]

Not sure if this is the right place for this or not, or if it's something that's already been answered and I just couldn't find it. In either case, just slap my wrist and point me in the right direction and I will wander off, hanging my head in shame.

Almost every program I know of for Windows, by default, wants to install itself into the Program Files directory. I can't possibly be the only person who finds this annoying. I prefer to group my programs somewhat according to their function. Multimedia-related programs and codecs in one folder, peer2peer programs in another, and so on...

Since it seems not all silent install switches support some kind of path switch, I am looking for another way to accomplish this.

I know you can use the SET command in a batch file to change and/or create local variables that will be unset when the batch terminates, but I am unclear as to what exactly constitues the termination of the batch file. If I call a batch file from within another batch file using start /wait, and then use SET to change the ProgramFiles variable, will the variable be reset when the second batch ends and the first continues, or will it be passed through the batch files until all off the batches have ended?

I will use Winamp as an example. I currently install Winamp from start.cmd as follows:

ECHO.
ECHO Installing Winamp 5.0.7
ECHO Please wait...
start /wait msiexec /i %systemdrive%\Install\Applications\Winamp\Winamp.msi /qn ini=%systemdrive%\Install\Applications\Winamp\Winamp.ini

If I were to change this so that start.cmd called another file, such as:

ECHO.
ECHO Installing Winamp 5.0.7
ECHO Please wait...
start /wait %systemdrive%\Install\Applications\Winamp\Winamp.cmd

with Winamp.cmd being:

SET ProgramFiles=%systemdrive%\Multimedia
start /wait msiexec /i %systemdrive%\Install\Applications\Winamp\Winamp.msi /qn ini=%systemdrive%\Install\Applications\Winamp\Winamp.ini
EXIT

when Winamp.cmd closes, and start.cmd moves on to install the next program, will the ProgramFiles variable be reset to "%systemdrive%\Program Files" or will it keep the value set in Winamp.cmd?

Secondly, this is my first attempt at a uA CD, and I am using the [GuiRunOnce] and start.cmd method simply because I am far more familar with standard batch scricpts than I am with the commands required for RunOnceEx. I do, however plan to switch over before creating the final CD. If I do implement this system of temporarily renaming the ProgramFiles variable, is there anything I will need to be careful of when switching over to RunOnceEx?

Again, if this has been discussed before, please just point me towards it and I can go on my own from there. I did search, I just didn't find anything.

[prathapml]

My my my..... no need for slapping wrist, and such - we are all here to help each other. By now, you have been here long enough to know that flaming, criticizing, etc. aren't seen here at all! Just cheerfully ask for whatever you want.

Okay, now first of all, I will ask you which method of install you prefer.

1. Using the standard installer (downloaded one).

2. Using the winamp MSI re-packed by Alanoll.

About method 1:

Its simple. You can just use "/S" switch and then kill the winamp player when it starts up. But no fine control over the process (location to install, associations, etc.). I prefer this method because location, associations is all do-able through registry and file-moving later on.

About method 2:

This one requires you to use a lot of switches (for fine tuning). Its easier for new-comers to use. The downside being, you have to wait for alanoll to make the MSI whenever a new version comes out.

Now, since I see that you prefer the MSI, a piece of suggestion:

Do not name the MSI parameter file as "winamp.ini" - because the winamp configuration file is also having the same name. Name the parameter file as "WA507inst.ini" or something like that. Why?

Because, that way you can pre-configure winamp.

I mean.... configure your winamp to how you like it, from preferences (skins, double-size, ripping, whatever). Then go to "C:\ProgramFiles\winamp" and copy away winamp.ini (that is where your winamp settings are stored). So now you can keep all required files in one directory:

winamp507_pro.exe
WA507inst.ini
winamp.ini

And example of how you might like to use it below:

Winamp.msi /qn ini=WA507inst.ini
copy /Y winamp.ini "%ProgramFiles%\Winamp"

I hope I have put the above in understandable form....

Okay, now that history and mystery is done with, we come to the point of how to choose which folder to install to. Interestingly, this topic has been discussed about a week ago. Taking the winamp MSI as an example:

Winamp.msi INSTALLDIR="C:\Programs\Players\Winamp" /qn

So in the above command-line, you will see that we are using the INSTALLDIR property. It can either be specified in command-line, or in the case of winamp, add that to be one more of the properties that you have specified to be used, in WA507inst.ini.

The INSTALLDIR property is a standard one usable with most well-made MSI-based installers (including MS-Office). Note that this property has one limitation which (according to me) is very damaging - You absolutely have to specify full paths (can't use %SystemDrive% and similar variables).

So lets say you coded your batch-files/switches to install winamp to some location on C: or D: drive. Then, one day you decide to install from your uA CD to your F: drive instead (because you don't want to disturb C: or D:) - but what does your dis-obedient winamp installer do? It goes and installs in C: partition! (because you specified INSTALLDIR) Whereas you expected all apps to install in F:\ instead! Now, when I'm telling this, it doesn't seem like such a big deal, but this sort of unpredictable/non-uniform actions is a major problem (as you'll see in office environments). The aim should always be to standardise everything, and get everything on your disk to behave in exactly the same way, no matter how much the environment differs, across a thousand PCs. So we're back to square one - you'd rather let the installer install to where it wants. But still, if you just want to have something done "fast and easy" - using the INSTALLDIR property of MSI (i.e., the Windows Installer) is the way to go.

For Install-Shield/WISE/Inno/Nullsoft install-packages, the process is not quite as simple as for the MSI ones, but we'll leave those for another day, as of now. And doing the "SET PROGRAMFILES" thingie is really a round-about way, best avoided.

Onwards to your RunOnceEX plans, I'd recommend don't bother with it. In its time (a year ago) - the RunOnceEX method with its graphical looks, indeed sounded like a god-send. But now, I'd say its not worth the effort you put in, to move from simple batch-files to RunOnceEX at all. Rather, stick with your .CMDs, and when you feel you have a grip on the basic things that you want your CD to do, move to XPlode/WIHU/WPI (or some such sort of tools). Those tools make RunOnceEX feel like a dog-send. RunOnceEX has none of the good-looks nor selectable install, nor complex operations, nor ease-of-use that the other tools will give you.

Just one suggestion to you, though:

Its frightening to see large amounts of text and take time to read it without knowing whether you would be able to help the person or not. So we'd take the easy way out, and skip reading that post. So if you'd like replies to your questions, I'd suggest that you give EXACTLY ONE-LINE summary in simple words, of what you'd like to know - at the end or beginning of your post (and *THEN* whatever else details you feel is necessary to help us to get you what is desired). For example, in this topic, you could have set out at the conclusion:

SUMMARY:

How can I change the location to which my install occurs?

This is *NOT* a slap on the wrist, just a friendly pointer, to ways in which you can make your post attract more answers.

Have fun!

[Cartoonite]

Wow. I wouldn't have thought it possible, but I think your post actually out-does mine for length. Maybe we should rename this thread to "How much text can we fit into the default 10 posts/page without talking nonsense?"

Thank you for taking the time to give me such a detailed reply. I did see the thread pertaining to the Winamp MSI, but I don't think that was until afterwards. Either way, Winamp was simply the program I picked as an example. The solution proposed was meant to apply to any and all programs, regardless of whether or not they posess their own re-direction switches.

Nice to know about winamp.ini. I will certainly be adding this to my uA tweaks.

Lastly, I'd gotten the impression that many of those post-install options were essentially extensions of RunOnceEx. I guess I was mistaken. Oh well. I can and will research them more once I have the uA itself working the way it is supposed to. One step at a time, and all that.

Thanks again for taking the time to help me out. It really is appreciated.

[Alanoll]

The INSTALLDIR property is a standard one usable with most well-made MSI-based installers (including MS-Office). Note that this property has one limitation which (according to me) is very damaging - You absolutely have to specify full paths (can't use %SystemDrive% and similar variables).

So lets say you coded your batch-files/switches to install winamp to some location on C: or D: drive. Then, one day you decide to install from your uA CD to your F: drive instead (because you don't want to disturb C: or D:) - but what does your dis-obedient winamp installer do? It goes and installs in C: partition! (because you specified INSTALLDIR) Whereas you expected all apps to install in F:\ instead! Now, when I'm telling this, it doesn't seem like such a big deal, but this sort of unpredictable/non-uniform actions is a major problem (as you'll see in office environments). The aim should always be to standardise everything, and get everything on your disk to behave in exactly the same way, no matter how much the environment differs, across a thousand PCs. So we're back to square one - you'd rather let the installer install to where it wants. But still, if you just want to have something done "fast and easy" - using the INSTALLDIR property of MSI (i.e., the Windows Installer) is the way to go.

This has NOT been my experience. Of course, I conduct my test via cmdlines. What this is at runtime, it translates %systemdrive% to it's value before executing the command. However, if you were to use the INI method for the MSI, try using a Windows Installer Property, [ProgramFiles] for example or something along those lines. I'm not sure if it work, but the way I have the MSI setup is that reads in the entire line as a string, and then processes it in it's internal processes.

Lastly, I'd gotten the impression that many of those post-install options were essentially extensions of RunOnceEx. I guess I was mistaken. Oh well. I can and will research them more once I have the uA itself working the way it is supposed to. One step at a time, and all that.

I wouldn't call them (WIHU,XPLODE and the likes) that run at "First Startup" to be extensions of RunOnceEX. WPI compiles as RunOnceEX script at runtime then imports, then executes. For teh most part, I use RunOnceEX to call WIHU/XPLODE simply because I have all my applications running from CD and as such, [GUIRunOnce] is useless to me, as NOTHING is copied over besides the Windows Install files, so RunOnceEX is a good way to accomplish this,especially using INFs (I like INFs more then BATCH).

nor ease-of-use that the other tools will give you.

Novices find RunOnceEX easier then others, since they don't need to learn the new syntax of INI files or Javascript or the like....

The downside being, you have to wait for alanoll to make the MSI whenever a new version comes out.

Speaking of which...

I'm planning on after the next update to the MSI, to upload the InstallShield file that make it, so all anyone has to do, is find the correct files, and recompile then upload somewhere to share. Sure, it won't be controlled, but it will reduce the time, as with the last MSI I got kinda busy and had to keep putting it off (and I tend to get off topic of things I'm doing).