[Killgore]

Hi!

Very useful program. It would be nice if it allowed putting source and destination directory as command line parameters (could be 1st and 2nd parameter). Now there is too much hassle with renaming directories if you have multiple Windows discs. And this way it could be scriptable.
And maybe in the future you could implement only updating Windows with new patches instead of applying them all each time you have new update? It could be possible with some flag files with the patch number in destination directory or maybe one hfsslip.lst file in the same directory?

Thank you for your great work

[Super-Magician]

I'm not sure why you would need to rename the source and destination directories, but Tomcat would probably be able to implement something of that sort in HFANSWER.INI.

However, this goes back to the %XPAND% issue we had a few months ago. He would need to change every instance of SOURCE (and possibly SOURCESS) to a variable (although this is easy enough to do, it's just unnecessary bloat in the script).

Regarding your second suggestion, in my opinion it isn't too hard to just run HFSLIP again every time, is it? Again, I think implementing something for this becomes too much bloat.

Please remember my opinions do not necessarily reflect those of the authors [TommyP and Tomcat76]. Wait for their final word.

[Killgore]

Super-Magician, on Aug 18 2006, 11:59 PM, said:

I'm not sure why you would need to rename the source and destination directories, but Tomcat would probably be able to implement something of that sort in HFANSWER.INI.

It's simple: I have multiple Windows discs (Home, Pro, Eval etc.) in multiple directories and I'd like to update each of them. When input directory is hard-coded into script I have to change name of each input directory to SOURCE before update and after update rename it back to some sensible name. I have to rename output directory also, so I can update another copy of Windows. It’s not very user friendly.

Super-Magician, on Aug 18 2006, 11:59 PM, said:

However, this goes back to the %XPAND% issue we had a few months ago. He would need to change every instance of SOURCE (and possibly SOURCESS) to a variable (although this is easy enough to do, it's just unnecessary bloat in the script).

Well it's only two "replace all" commands in text editor. In fact I can do it myself, but I’ll have to do it after each update of HFSLIP. And what kind of bloat are you talking about?

[Super-Magician]

It's not as simple as just replacing all instances of SOURCE and SOURCESS. Tomcat needs to add additional commands.

The bloat I'm talking about is this:

A few months ago, Tomcat introduced support for a custom location of EXPAND.EXE. He then replaced all instances of EXPAND or EXPAND.EXE in the script with the variable %XPAND%. However, TommyP, the author, objected to this as it unnecessarily increased the script's size and this feature was removed.

You are the only such user (as far as I can tell) who has requested such a feature. If additional users support it, Tomcat may add it.

[Tomcat76]

I don't see how two "replace all" commands can deal with it. HFSLIP would still have to check what's in those folders, and I presume also *do* something with all of them.

Personally, I don't see the point of it. I also have several versions of Windows but they are in their own folder (eg, hfslip2ken, hfslipxpsp2en, hfslipxpsp1en, hfslipxpnl...). The HFSLIP CMD file resides in each of those.

[Super-Magician]

If you have enough hard disk space, Killgore, you should just make more than one HFSLIP folder.

[Killgore]

Tomcat76, on Aug 21 2006, 02:19 AM, said:

I don't see how two "replace all" commands can deal with it. HFSLIP would still have to check what's in those folders, and I presume also *do* something with all of them.

I only meant that it's enough to replace all appearances of SOURCE with e.g. %SOURCE%.

Tomcat76, on Aug 21 2006, 02:19 AM, said:

Personally, I don't see the point of it. I also have several versions of Windows but they are in their own folder (eg, hfslip2ken, hfslipxpsp2en, hfslipxpsp1en, hfslipxpnl...). The HFSLIP CMD file resides in each of those.

OK, but this way you also have to keep copies of all patches in each of these directories in the respective HF directory. When all these windows versions are in the same language and have the same service pack number (and that’s my case) it’s unnecessary waste of space, because all these patches are the same.

[tommyp]

Can you copy the HF folder to the "other" HFSLIP folder? Hard drive space is cheap, less then 50 cents a gig. My 2k HF folder is 100 meg, XP's HF folder is less than 100 meg. Add 'em both up and you get far less than 50 cents.

[Killgore]

tommyp, on Aug 21 2006, 11:36 PM, said:

Can you copy the HF folder to the "other" HFSLIP folder? Hard drive space is cheap, less then 50 cents a gig. My 2k HF folder is 100 meg, XP's HF folder is less than 100 meg. Add 'em both up and you get far less than 50 cents.

Yes, I can copy patches after each update to each of these folders, modify HFSLIP ini files not once but a few times each time I want to change some settings. I could even apply each of these patches manually after installation of Windows. I only think that when it's possible to automate some tedious tasks it's better to have them automated then not. That's why I started using your tool among other things. And that's why I proposed these changes - it's simply easier for me to maintain one HFSLIP directory structure then four of these. I think that potentially many people can take advantage of this change, especially those that use many Windows versions in the same language. Of course there are many that won't, but in my opinion it's always better to have a choice.
But I don't want to force anyone into doing anything. As I said, I can modify script for myself. I only proposed some solution which, I think, makes this tool a little more flexible.

[troy]

Killgore,

FWIW, I agree with you 100%. I too would like to see something to make it easier to maintain multiple sources. In my case (as indicated in another thread), I need both Home and Pro, SP2 only, but I need OEM, Retail, Upgrade, and possibly others for an all-in-1 CD. The only files to be taken into consideration, are the SETUPP.INI and TXTSETUP.SIF, and after editing 6 of them, I often find myself going back to double and even triple check to make sure I got all of them.

[Killgore]

troy, on Aug 24 2006, 12:43 AM, said:

Killgore,

FWIW, I agree with you 100%. I too would like to see something to make it easier to maintain multiple sources. In my case (as indicated in another thread), I need both Home and Pro, SP2 only, but I need OEM, Retail, Upgrade, and possibly others for an all-in-1 CD. The only files to be taken into consideration, are the SETUPP.INI and TXTSETUP.SIF, and after editing 6 of them, I often find myself going back to double and even triple check to make sure I got all of them.

I don't know what kind of editing you do to these files and if it's in some way related to HFSLIP? For managing multiboot CD I recommend PowerPacker. What I proposed is more centralized management for HFSLIP files (hotfixes, ini) through parametrization of the script so you could update all your Windows copies from one place.

If you always make the same changes to all these files maybe you could script them too with e.g. fedit?

[whitehorses]

@Killgore
I do exactly how tommyp said. So what?! You don't even have that much duplicate entries as 100 megs: only the ones used by multiple sources have to be redundant (around 20 Mb) This way it's well organised enough, I think. If that 20 Mb still too much, use hardlinks