Possible peculiarity relating to driver integration

[Inki]

First of all, my appreciation for this project.

Using HFSLIP with Windows 2000 SP4 and USP 5.1, I have noticed a peculiarity, which I am at a loss to figure out. I have noticed it with several HFSLIP versions including the latest, but I am certain that it has not always been there.

No problems arise if I use option D for driver compression. However, if I select option A, the windows installation process is unable to find the following files: faxdrv.dll, hid.dll, mf.sys, parallel.sys, parport.sys, sonydcam.sys, and mouclass.sys. (At one point I even thought that this might be a CD read/write error as I don't use a virtual setup, but I think that I have ruled that out by trying different media and noting that the problem files are always the same and I can manually find them.)

In both cases these files are found inside SP4.CAB, which is identical whether I select A or D. (Still, it is different from the original SP4 disk, and I quess it is modified by USP5.1.)

I wonder if this somehow relates to the fact that my original source disk is SP4, and could it be that under option A the installation process somehow misses looking into SP4.CAB when SPX.CAB is not there?

[Super-Magician]

If you select option A, HFSLIP should merge DRIVER.CAB and SP4.CAB into a new and recompressed DRIVER.CAB with some updated binaries from your hotfixes. In that case, SP4.CAB should no longer exist in your SOURCESS folder after running HFSLIP, which leads me to think that something went wrong at the point in the process.

Can you attach your HFSLIP.LOG file?

[Inki]

Certainly, here you are.

Just a few comments concerning the list of fixes in case you wonder: It does contain a few old and obscure hotfixes, some of which have been renamed for the benefit of HFSLIP. It is a work in process in the sense I have yet to re-examine the need for all those old fixes, and to otherwise update the structure to reflect the latest changes in HFSLIP, such as not requiring separate DX9 cabs.

One thing which strikes me, is that HFSLIP.LOG mentions SP5. This may be OK depending on what is meant by it, but strictly speaking USP5.1 is still only SP4 with updates. Not at all knowing how HFSLIP really works, I could maybe foolishly speculate that SP4.CAB is not integrated into DRIVER.CAB because HFSLIP expects to find the non-existing SP5.CAB?

UPDATED:

You probably know this, but just to be on the safe side I could further clarify, that although USP5.1 does not replace SP4.CAB with SP5.CAB, it does create CDROMSP5.TST, which contains the version number of the USP. It does not remove CDROMSP4.TST, and both .TST files exist.

And by the way, I tested to make certain that removing everything but W2KSP51.EXE from the HF-folder does not change the outcome concerning SP4.CAB.

While I am at it, I could also point out another feature of HFSLIP which has existed as far as I can tell: When I use HFSLIP to slipstream USP5.1, I am offered the option of removing unnecessary .CAT files, which is nice. However, if I allow USP5.1 to slipstream itself into the source before using HFSLIP, I am not offered this same option. Actually, right after asking about making a multiboot CD, HFSLIP went directly to work, and during that transition there may have very briefly flashed on the screen some kind of warning or comment concerning finding something with SVCPACK or something similar in its name.

UPDATE 2:

I experimented by making a copy of SP4.CAB (as modified by USP5.1) and placing it in SOURCE\I386 with the new name SP5.CAB (I also included an equally renamed copy of SP4.CAT just to be sure). After that, I ran HFSLIP with option A for driver compression (in my normal configuration, having HFSLIP slipstream the USP).

Indeed, during the processing I could observe SP5.CAB being extracted. Finally, in this case neither SP4.CAB or SP5.CAB was no longer present in the output by HFSLIP, and the individual driver files mentioned in the first post could now be found in DRIVER.CAB.

HFSLIPLOG.ZIP

Edited January 14, 2008 by Inki

[Tomcat76]

Any problem/suggestion mentioned here should be fixed/included in the hfslip-1.7.4beta_80116a test release.

Thanks

[Inki]

Thank you very much for the new test version, which I thought came up pretty fast. I noted that you were able to generate four change log items from this thread. After a brief test run it appears to me that everything has been perfectly addressed!

The one and only, essentially cosmetic thing, which I noticed, and almost hesitate to mention, but I thought that you might like to know, is a small difference in HFSLIP.LOG content:

USP5.1 slipstreamed by HFSLIP produces:

OS in SOURCESS - Windows 2000 Professional SP4 English [service Pack Slipstreamed by HFSLIP]

USP5.1 slipstreamed beforehand produces:

OS in SOURCESS - Windows 2000 Professional SP4 (USP5.x) English

I greatly appreciate your continued support for the USP.

[Tomcat76]

That happened because HFSLIP was checking for the existence of cdromsp5.tst in the SOURCE folder when generating that line into HFSLIP.LOG, which would fail if a source backup was made because the backup is replaced before HFSLIP.LOG is created.

There's an updated version which searches for cdromsp5.tst in the SOURCESS folder.