Changing Program Files Path

[KerguelanAvon]

Hello there,

I'm trying to put together a slipstreamed installation disc, and have reached the point of customising the unattend.txt answer file.

I see that there are options for changing the location of Program Files, Common Program Files and Documents & Settings folders in the unattended guide, and I wonder if I could use these in a multi-boot environment?

What I hope to do is have a few different XP installations using the first 3 primary partitions on each of 2 hard drives (not necessarily all of them, but I can envisage using 3 or 4 out of the 6 that should be available), and use the BootMagic component of Partition Magic 8 to select which one is started each time (and automatically hiding the rest of them), but I don't want to have to put an installation of all the applications that would be common to most of the installations into each of those primary partitions, which would use up valuable disk space.

It seems to me to be much neater to have the applications installed to the first logical partition on the drive (which we'll call the D Drive), and have each of the XP installations point to that D Drive for their Program Files and Common Program Files folders, (effectively sharing a common source) but I'm not sure if this is likely to cause me problems later on.

For example, the most radical example I can think of (in terms of how often it would update) is NIS 2005. Would I be able to install it to each primary partition in turn (but sending the Program Files to the D Drive) or would I have to install it to one partition (again sending the program Files to D Drive), and then mirror that partition to the others instead? Would this also apply to other 'system' applications like Roxio or Diskeeper etc?

Furthermore, if I was able to get NIS2005 installed on multiple XP partitions with the Program Files on Drive D, would running LiveUpdate on any of those partitions, automatially keep all the partitions up to date, or is it more likely to cause problems if (for example) some of the partitions aren't used as often as other ones and get left with out of date components that will always get installed to the system drive. Or for that matter, out of date registry keys, for example?

Should I instead limit myself to having only using the D drive for my Program Files folder, for those applications which are more 'user' based? Things like Office 2000, Get Right, Opera, Roboform, etc.

Avon

[sHaDYvB]

Hiii

i will offer my little expreince on that issue , and hope it helps u ..

first of all if u r able to install the program itself like NIS or any other protection application , then u can update it on one system and have all systems updates as well ,, that is becauz updates are files phyical files not registry enteries ,

but about the program itself , there is two probabilities for a program to store it's configuration : either in the registry , or in configuration files like ini files or such ,,

in the first probability ( the registry ) , i think u must install the application on each system ( in the same dir ) just to store registry based settings and configurations , ( or just back registry values up and install them on each system ) , that depends ..

but , for the second probalbility ( the files ) , i think it is very hard to have the same copy of the application running with all systems , especially sophisticated ones that store information about system and user ..

thinking of something like that , if u can achieve that , u can point the whole programfiles dir for all systems to one folder ( using winnt.sif ) , and change only things that r not compatible with this way ,,,

howeva , i think ur question needs a little clearification ..

i hope i said something right

[KerguelanAvon]

Having a shared "programs files" folder was something that I'd done manually before with some success.

I had set up 2 primary partiitions on one hard drive, each with a seperate installation of Windows XP, and another two on a second Disk, one with Windows 98 and the other with a third WinXP installation that I used for testing things. I would then use the Active Partition Hiding function of the BootMagic component of PowerQuest's PartitionMagic to have only one of these four primary partitions active and visible at any one time.

What I did in the past was to allow some installations to go into the normal Program Files folder on the currently active systems partition, but changing the installation path for some things (like Office 2000) to go into the D drive (Shared Applications), which was the first logical partition on the main drive. It still meant repeating the installation on each of the system partitions on which I wanted to run the software that was being installed to the Shared Applications Drive, but by having all the application files on the D drive, all three versions of Windows XP referred to the same set of files, so there were not three sets of files taking up precious hard drive space.

What I originally hoped to do was use the WinNT.SIF file to make ALL the Programs Files and Common Programs files go to the D Drive on each WinXP install, so that I could have 3 or 4 smaller WinXP partitions, and one medium sized Shared Applications partition, instead of having 3 or 4 larger Win XP partitions with all their applications self contained.

However, I have been thinking about this a bit more, and although I can't see why it wouldn't work in the shorter term, (ignorance is bliss) I can forsee a scenario in which it will cause me more problems in the longer term.

If it turns out to be stable in the longer term, what happens when I come upgrade some of the shared applications? This is the opposite scenario I postulated in my opening post to this thread, where I was concerned about how NIS would handle updates on some installations being behind others because they didn't get used as often. While it might be possible for something like NIS (which updates on a rolling basis) to look at where it expects virus definitions and firewall rules to be stored, and just go with whatever it finds there, most other applications will probably want to un-install a previous version before applying the upgrade. My concern now is that something like upgrading from Roxio EMC7 to EMC8 will make significant changes to the file structure from the previous version, which would cause any attempt to use that application on either of the other two partitions to fail.

My first reaction to this was that I could just apply the upgrade to each system partition in turn as was done with the original installation of the application, but if the old version of the program has already been uninstalled on another system partition, the second attempt at the uninstall is probably going to fail, because it can't finds the files it needs to delete before installing the new ones. Then I realised that the un-install of any application shared between multiple system partitions in this way would also fail on the second and third partitions, making it more likely that I'd mess up my system, and have to start again from scratch.

Overall, my conclusion is that the space saving benefits of sharing the application space is not worth the problems it would cause further down the line, even if it worked in the first place. So unless someone else has tried this and has tips of how to get it to work, details of which applications can and cannot be shared successfully in this way, or can offer any advise, I think I'll leave this idea alone for the moment.

After all, it is my first attempt at slipstreaming an install disk, so maybe I shouldn't run before I can walk.