This is my first go with XP. I've done a number of 2K installs, and did a perfect 2003 HFSLIP install about a month ago - perfect! (although there wasn't much to slip).

I used 1.50 for this XP install, and got flagged on a lack of a clean source. I always do some OEM TEXTMODE driver work prior to running HFSLIP. When I got the warning, I blew right through it - thinking it might have detected the my OEM work.

But since I never got this warning before, I considered that it came from HFSLIP detecting the SP2 inclusive source. My log indicates, WARNING - Previously Patched Source Detected.

The "virgin" XPSP2 (Pro) source disk is a full retail version - the kind you would have bought at a store before Vista came out.

So I ran HFSLIP again with a new/clean SOURCE (I copied the entire disk). But this time, I didn't do any preliminary OEM TEXTMODE work. The warning popped up again, so HFSLIP was indeed flagging the SP2 in the retail source disk.

I understand the safety measure of the flag, but is this something to be concerned about? IOW, do you have to have a true "gold" disk not to get flagged? Is the flag meaningless?

I have heard of a SP2b series of disks that have a coupla other fixes added in can you post a pic or list of the dirs in your I386 folder?

Sure.

This is probably overkill, but here is a WinMerge report.

I can go deeper.

The ASMS contains the following folders: 1, 10, 1000, 2, 5100, 52, 60, 6000, 70, and 7000

The COMPDATA folder contains mostly HTML and TXT doc.

The DRW folder contains a 1033 folder and a couple files.

The LANG, SVCPACK, SYSTEM32, WIN9XMIG, WIN9XUPG, and WINNTUPG folders all look like the usual stuff.

I named the 7z folder the label of the disk.

My XP SP2 disks don't have a svcpack folder in them pre-modification.

What is in there?

The newer SP2 disks install a non-public IE6 update from SVCPACK. The existence of the SVCPACK folder causes HFSLIP to trigger the warning.

The reason I haven't come up with a solution for that yet is because, if that update is not installed (which happens after running HFSLIP) and you don't include the latest cumulative update for IE6, you get tons of errors reported in setuperr.log. So I don't want to simply ignore the existence of the SVCPACK folder as a whole. Instead, the warning message needs to be different.

The latest test release removes SOURCE\I386\SVCPACK if the source is considered "clean" otherwise. This is reflected in HFSLIP.LOG but it says "INFO" instead of "WARNING" to shush the paranoid

(SOURCE\I386\SVCPACK is not removed if the source was patched with USP5)

shush the paranoid...



Thanks, TC.

Kel., nice pickup.

TC, again, thanks for addressing this issue. That non-public HF (KB911164) hasn't exactly received rave reviews on the net, to the extent there is any info on it.

I guess you could have guessed that I would stay in paranoid mode. If I understand what you're doing in the beta build, you are coding HFSLIP to "simply" remove the entire SVCPACK (and KB911164) from the SOURCE to produce a KB911164-less SOURCESS installation.

I'm going to wait for your final build. But, could you simply remove the SVCPACK folder from the SOURCE folder prior to running HFSLIP (1.5.0 or whatever build), or would setup throw a fit (looking for SVCPACK and than stupid file)?

I know MS doesn't create software with the 3rd party slipstreaming community in mind, but this one is a real "head scratcher".

I'm slipstreaming the latest IE6 cumulative updates - an up-to-date, conservative, file set based on your 06/12/07 dynamic page. Thanks again.

Edit:

I finally bumped into this on a Russian message board. About halfway down, a poster explained on 11/22/06:

There's more to KB911164 than just the ActiveX fix. If you remove it but don't slipstream the latest cumulative update, setuperr.log will be riddled with errors for certain binaries. Basically, Windows setup doesn't accept its own files (those in I386). Go figure.

Letting HFSLIP remove the SVCPACK folder or doing it manually is the same thing. You only need to make sure you update IE (latest cumulative IE6 or slipstream IE7). When including IE7 but not slipstreaming it (ie, first GUI logon or SVCPACK methods), it's better to also include the cumulative IE6 update to avoid the errors in setuperr.log.

Just wondering...how new is that? I've never seen that label before on an XP SP2 disc.

TC, thanks. That's what I thought - that if you included the latest cumulative IE6 update there'd be no problem.

Supe, I bought it just recently on eBay. It was an open box at the right price. The seller indicated that she had recently purchased it at a local store for an app she thought she needed it for, but then realized that her old OS could handle the app. She said it was never used, much less activated. I want get it up quickly to be sure.

I've never used XP as my OS before, so I have nothing to compare it to. But based on all the posts here ("b disk"), it looks like it's pretty new, and the seller's story seems to jive so far. If I was at work, I'd look at the source date stamps.

Edit:

Super, all files within all folders are date stamped 02/28/06.

Tomcat76, the "Gold" source disk contains the following SVCPACK items:

1. SVCPACK (folder)
2. SVCPACK.DL_
3. SVCPACK.INF

Will the test build remove all 3 items (or, if I do it manually using 1.5.0, should I remove all 3)?

The removal of the SVCPACK folder is understood, and the INF calls on the KB911164.exe. I'm just not sure about removing the SVCPACK.DL_ (or how it might mess with HFSLIP or the install).

Thanks

Well... Here's what happens with SVCPACK.INF/SVCPACK.IN_...

1) Whatever is in your SOURCE folder is copied over to SOURCESS; this includes SVCPACK.INF/SVCPACK.IN_
2) When the SVCPACK items are processed, any SVCPACK.IN* files in the SOURCESS folder are deleted and a new one is created

This has been the case for a long time.
So basically, you can leave SVCPACK.INF or SVCPACK.IN_ alone.

The SVCPACK folder should be deleted manually if using the latest final. This isn't the case anymore with the current test release.

HFSLIP doesn't mess with SVCPACK.DL_. I wouldn't touch that file.