Tomcat76

Alrighty... 60328c is gonna be the final for tomorrow unless someone finds a problem that doesn't exist in 60317. It's about time, I'd say...

HFSLIP doesn't use the -o switch, but I do. I never had a problem with it. -h -n -m -o works great for me.

I don't know if you're interested, but I got a page going with updates for Win2K3. The link is in my signature. There are direct download links to all hotfixes (English version) except those which are WGA protected.

Does anyone use HFSLIP's built-in ISO creator? If you do, please give 60328a (or higher) a test run. I need to know if everything's OK with: - CDIMAGE - MKISOFS - CDIMAGE + ISOconf.txt with customized settings - MKISOFS + ISOconf.txt with customized settings I'm gonna try to test as much as I can myself but if there are no positive responses this update won't make it into the upcoming final. Thanks...

If the SOURCE was already patched, then HFSLIP will ignore the Service Pack in the HFSPACK folder. In the case of Win2K3, HFSLIP searches for an SP CAB file in the SOURCE\I386 folder to determine whether a source is patched or not.

danod-- Have you moved the Service Pack into the intended folder? See my previous post...

ThunderM... You're the first to report this problem and we haven't experienced it yet. I did what I could. I happen to own a German copy of Windows XP but not of Windows 2000 so I can't diagnose this completely myself. A new test release is in the works. It already ignores msxml3.dll and msxml3r.dll from WUA if the Update Rollup exists; this is OK since the version numbers are identical. I'm looking into the danim.dll issue now. It would help if you gave me the following: - version number and file size of danim.dll on the new installation (system32 folder) - the latest HFSLIPWU.INF file (SOURCESS\I386)

That's good news. I think we're heading for a new final then.

KB889101 is the Service Pack. If you want it slipstreamed, please create a subfolder inside your HFSLIP folder called HFSPACK and place it in there.

Come back either way. I wanna know how it goes...

Do you mind removing dotnet from the HF folder to test? After that, run HFSLIP again and then open TXTSETUP.SIF in a text editor to see if you still get any "install.res.xxxx.dll = 1,,,,,,,2,0,0" lines. They should be all the way at the bottom (if they're still there). Edit: I just checked and those files are part of .NET 2.0. HFSLIP doesn't support slipstreaming of .NET.

danod-- I'm gonna need your ERROR_REPORT.TXT file. There's some weird stuff in that TXTSETUP.SIF file. (BTW: you got a typo in the URL)

That's new to me. I never tested 2K without scripten.exe so I never knew it really was mandatory. I'll update the hotfix page then.

If the files are in the SOURCESS folder but they don't end up in the WINNT\HFSLIP folder during installation, it can only mean they aren't copied over. Can I have a look at the TXTSETUP.SIF file from the SOURCESS folder?

He's using his own script to mod some files later on. One file that's being edited is DOSNET.INF. He rem'd out that line but he's still getting a messed up DOSNET.INF. If "empty folders" is an issue, I uploaded 60327b which ignores empty CODECS, APPREPLACEMENT and HIVES folders in HFEXPERT. As far as I can see, HFEXPERT\WIN doesn't need special treatment anymore so I'm leaving it alone for now.

You can let HFSLIP take care of slipstreaming WMP10 since you're running an English version. There's an English WMP10 addon you can download over at the RyanVM forums. It goes in the HFAAO folder. I never tried it myself but there's nothing in the configuration file that HFSLIP can't handle. Note: it contains wmcsetup.exe plus a couple of hotfixes so you can remove these from your HF folder.

Pontus-- Please try the new "special" test release. There are two versions in one package. Please follow the instructions (right below the download link) and report back. Thanks.

You said: "I made a bootable cd and installed my build manually with winnt.exe" I wanted to know if you still got the error when booting off the CD (ie, no floppy or winnt.exe involved) Just to be sure: the copy error during Windows installation is one for SPX.CAB? Do you install Livestate after Windows installation completes or is it integrated on the CD?

I knew that... I was smiling...

A few comments... WindowsMedia10-KB911565-x86-ENU.exe WMP10 is not in your HF folder so you might have problems including this update. I'll leave that up to you. WindowsXP-KB885626-v2-x86-enu.exe This is not needed for a slipstreamed SP2 install. Are you having problems when you don't include it? WindowsXP-KB893066-v2-x86-ENU.exe WindowsXP-KB894391-x86-ENU.exe Both of these are replaced by newer hotfixes, KB913446 and KB902400 to be exact. See if you still get problems after (re)moving those hotfixes. I'd like to have a look at your winnt.sif file if that's OK. Remove the key if it's specified. Do you remember what the BSOD said? Any reference to a file? Edit: One more thing... Can I have a DRVINDEX.INF file from the SOURCESS folder created with 60207b (non merged) and the DRVINDEX.INF from the SOURCESS created with a newer version (non merged)?

With the new test release?

OK. I updated the test release...

@Kramy I don't see the difference between your :GETBOOTBIN and the current :GETBOOTBIN section (apart from that extra line with your name). What should be changed? I have a better solution for the whole thing which also allows boot.bin to be used with CDIMAGE.EXE should people prefer that (boot.img is still accepted). Try test release 60326c...

To be honest, I used to get that "insert disk error" once in a while but that was a couple of weeks ago. I haven't experienced that anymore recently. I don't know if TommyP made some changes to that section which stopped the error from showing. I never touched that part myself because I don't use it. I make ISOs with my own script.

HFSLIP doesn't do anything "special" with vgx.dll. In fact, it doesn't do anything with that file at all. I don't use nLite (don't like programs of which I don't have full control) but maybe someone else that uses HFSLIP with nLite can shed some light on this. I find it strange that noone ever came across this before. But then again... You do call it an "odd configuration", so maybe you should first explain what you're doing.