I am not sure if this has been discussed before, but I don't see it in recent threads anyway.

Just wondering if HFSLIP can automatically support integrating, not slipstreaming, some hotfixes via SVCPACK.INF method using /quiet /norestart [/nobackup]
Doing so would enable us to integrate hotfixes that are not currently supported by HFSLIP but can be integrated via SVCPACK.INF.
Presently, I put two hotfixes in SVCPACK_SW, namely WindowsXP-KB923800-x86-ENU.exe and WindowsXP-KB935448-x86-ENU.exe. KB923800 isn't handled yet by HFSLIP, I believe, and KB935448 although seems to be sliptreamed properly with all concerned files being updated, I still receive complains from WU as I explained in this thread. Of course, SVCPACK.INF method works with those hotfixes.
But, of course, after putting those hotfixes in SVCPACK_SW, I still have to edit svcpack.inf manually to change the switches from /Q:A /R:N to /quiet /norestart [/nobackup]. I know it's not that of a big deal, but it would certainly save me a few steps and time, since I use the CD/DVD burning feature of HFSLIP. And now, since I still have to edit svcpack.inf after initial run by HFSLIP, I have to run HFSLIP again to make ISO and burn.
What if we have and additional folder, say HF_SW, for hotfixes to be integrated into svcpack.inf using the appropriate switches? And maybe IE7 can also be place there if a user prefers it to be installed via SVCPACK. Also, this feature can useful for new hotfixes that might not be supported by HFSLIP at the moment but can be integrated via svcpack.inf, at least, temporarily until HFSLIP can support handle/slipstream such hotfixes.

you'll have to repack those hotfixes in the form of switchless silent installers in order for them to work via HFSVCPACK. It does work that way, I currently have KB907265 installing that way (it's not supported by HFSLIP for direct integration)

@johndoe74: I know about repacking installers, or in this case, hotfixes, into switchless silent installers. I know that you could virtually install anything through switchless installers in svcpack.inf as long as the installer does not require an administrator account.
what I was talking about here is automatic support in HFSLIP. It was done (automatic support) with updates that have /Q:A /R:N switches so why not with hotfixes with /quiet /norestart switches?
switchless installers need constant maintenance as they need to be updated whenever newer versions of those installers come out.

i suggested exactly this sort of thing to the tc and tp, didn't get a reply tho, maybe they're quietly workin on it or maybe they just plain ignored it

Ignore what?

It's already done in internal builds. I think this is useful because there are more Type 1 hotfixes than there are Type 2 hotfixes. In fact, I haven't seen anyone put a Type 2 hotfix in HFSVCPACK_SW in a long time. It used to be there for stuff like the WMP6 codecs but HFSLIP has long been capable of slipstreaming those files if placed in HF. The reason I let MSI be placed in HFSVCPACK_SW is so the folder wouldn't appear to be dead to most users.

The proposed folder names are HFSVCPACK_SW1 (for Type 1 hotfixes and MSI files) and HFSVCPACK_SW2 (for Type 2 hotfixes). The only thing I'm not sure of is whether the second folder should be created automatically or only if there are executables in the original HFSVCPACK_SW (files are copied from HFSVCPACK_SW into the new folders based on their extension and then HFSVCPACK_SW is removed).

well i did suggest here that maybe you could modify the code such that if hfslip were to detect an unsopported hotfix in HF that it automatically create a switchless silent installer so the hotfix does end up installed one way or the other (there really aren't too many of those unsupported HF floating about so it should hopefully not take up a lot of time/resources/effort of the part of you guys)

You can try the latest test release if you like. It uses HFSVCPACK_SW1 and HFSVCPACK_SW2 instead of HFSVCPACK_SW.

For KB923800, you have two options:
1) place it in HFSVCPACK_SW1
2) create a folder called _EXTERNAL in your HFSLIP working folder, move KB923800 into _EXTERNAL, and extract HFSLIP_PRE_KB923800.zip (version #3) into HFTOOLS

The second will have it slipstreamed into the source. Do NOT put KB923800 in HF!

Thanks, Tomcat.. will play on this asap.

EDIT:
Worked without hiccups!

hi! would there be a topic dedicated to HFs that need to be placed in the aforementioned folders or could it be specified in the HF lists around? ... most of the HFs i have are Type 1 ... thanks!

It's mentioned in the changelog

only the hotfixes NOT supported by hfslip are required to be put in HFSVCPACK_SW1 OR HFSVCPACK_SW2 (depending on the type of the hotfix and what installation switches it accepts). The rest of the supported hotfixes are supposed to go in HF as usual

hi johndoe! pardon me for asking ... but how do i repackage HF like 907265? kindly guide me on this one ... you see, after reading that it could already be supported, i tried putting it back to HF & result was this in HFSLIP.log: ... prompt came up during installation showing switches ... thanks in afavance!

Kiki...

With the current test release and upcoming version 1.5.0...

- executables which are supported by HFSLIP and msxml*.msi go in HF (just like before)
- Type 1 hotfixes which are not supported by HFSLIP and MSI files except msxml*.msi go in HFSVCPACK_SW1
- Type 2 hotfixes which are not supported by HFSLIP go in HFSVCPACK_SW2

kiki you don't need to repack it anymore with the latest builds of hfslip. what you're doing wrong is putting it in the SW2 folder. that folder is only for the hotfixes that use /Q:A /R:N switches for silent install without reboot. if you put it in SW1 (for hotfixes that use /quiet /norestart switches to install), it'll work just fine!

thanks johndoe what i did initially was let HFSLIP take care of it by placing it in HF ... as a result, it was placed in SW2 dir instead of SW1 ... i'll do just that then manually ...

The test releases never moved files from HF into HFSVCPACK_SW2... ::confused::

They do automatically move executables from an existing HFSVCPACK_SW folder into HFSVCPACK_SW2. Both folders are for Type 2 hotfixes (as far as executables are concerned) so that shouldn't be an issue.

hi tc! tried it twice with HFSLIP Version - 1.4.5+ build 70525a & that's exactly what happened ...

I searched the entire 70525a and the latest internal build for instances of "HFSVCPACK_SW2". The only line I could find which copies files into HFSVCPACK_SW2 is for executables coming from a still-existing HFSVCPACK_SW folder.

There is still one other possibility. You use the "alternate input folder" feature and the HFSVCPACK_SW folder in that alternate location contained Type 1 hotfixes.

Other than that, it's just impossible...

TC, thanks for the changes and revised instructions for 923800, will test this a.m.