Tomcat76

@Kiki In your case, I suggest you use the latest test release because it slipstreams IE7 (into Windows XP). It's working fine here. Remove the StepByStep update because it's only useful if the main StepByStep program it applies to is installed first. HFSLIP only supports one "StepByStep" exe, by the way, so this update can't be included anyway. I had a quick look at the code that does the HFAAO folder and every "full" path appears to be quoted. I'll have to test this for real in a working folder with spaces to see what could be wrong.

Hi HachiRoku What is failing with mpeg2data.ax? Is it not copying over? Does Windows setup complain? Does dxdiag.exe complain when you run it? Also, I'm not sure I understand what your problem is with the XP loader files. They are not copied over into the new source? I'll need HFSLIP.LOG, and if possible also TXTSETUP.SIF from SOURCESS\I386. It is best that you put them together in a ZIP package.

@Kiki Answered in the other thread @S3pHiroTh Post installation, you can remove the HFSLIPWU.INF line from SYSOC.INF. That should remove the entry from the list in your screenshot. @Camarade_Tux In my testing, this doesn't work at T-13 nor from a CMD at first GUI logon. The only thing that worked was what's in NR's IE7 addon. @EmRoD Are you talking about LegitCheckControl.cab? What's COA?

@S3pHiroTh You have PROCESS_DNF3_DNF2=SEPARATE (the default). This is explained in the main post. Set it to YES if you don't want .NET 2.0 taken out of .NET 3.0. @Kiki Those are two different things. Setting PROCESS_DNF3_MSXML6 to NO tells SNM to not include MSXML6 in the outputted silent installer and to ignore any msxml6 installer you put in the SNM working directory. So whether you rename msxml6_x86.msi or not doesn't make a difference because it will be ignored anyway. If you want to include the latest MSXML6 binaries in DNF3.exe, simply leave PROCESS_DNF3_MSXML6 at its default setting (YES) and rename msxml6_x86.msi to msxml6.msi.

OK... I was under the impression that this was fixed with the latest shell32.dll update. Apparantly not. I'll put the QL fix back in. Meanwhile, you can get the icon back by running this command from Run: regsvr32 /s /i:U /n shell32.dll I don't know if it's necessary, but I usually do it like this: 1) disable Quick Launch 2) execute the above command 3) log off 4) log back in and enable Quick Launch

I don't know if it's coincidence or not, but my system became very unstable after installing RPL2K.DLL. I'd get an error message that explorer.exe has caused problems, and the shell restarted after I clicked OK. This happened opening random folders (just viewing them), very often. I deinstalled RPL2K.DLL about 7 hours ago and so far I didn't experience any crash. I haven't witnessed a shell restart for over two years on my computer (reinstalled a few times, of course, in those two years) so I'd exclude "bad system maintenance", but you never know, hehe... If it would help, I can install RPL2K.DLL again and provide you with some logs. I usually use Inspector IIXII but if you prefer something else let me know...

msxml6_x86.msi is supported by HFSLIP. It replaces msxml6-KB927977-xxx-x86.exe. Unfortunately you'll have to rebuild DNF3.exe (assuming you made it with my tool). The problem is that the MSXML6 resource file contained in the MSXML6 SP1 package is OLDER than the one for MSXML6 "SP0". The MSXML6 binaries inside DNF3.exe are copied over if the ones in SYSTEM32 are older or non-existent, so the XML6 resource file will get downgraded to SP0 by mistake. You'll have to rename msxml6_x86.msi to msxml6.msi for the .NET Maker (not necessary for HFSLIP). By the way... You can make it easier on you by setting PROCESS_DNF3_MSXML6 in the answer file for SNM to NO and only include MSXML6 with HFSLIP (or vice versa). You don't need to have those files twice.

@S3pHiroTh The pngfilt.dll problem should be fixed with 70220a. Concerning your other question... Wasn't this fixed? Try using merging option A, B or C again. New driver binaries are force-copied now...

@glentium IE7-KB928089 is replaced by IE7-KB928090. I want to bet money on it that this is the culprit: IE7-KB928090-WindowsXP-x86-enu.exe WindowsXP-KB928090-x86-ENU.exe IE7-KB929969-WindowsXP-x86-enu.exe WindowsXP-KB929969-x86-ENU.exe Don't include hotfixes for both IE6 and IE7. Use those for IE7 when slipstreaming IE7.

Just an FYI for everyone: HFSLIP 1.3.1 contains this fix in case you don't like working with a test release.

That seems to have done the trick, at least for folder views and Quick Launch. But the big buttons in the taskbar still have those toothy edges on icons. I'll give the programname.exe.32bitimgl a try but I suppose it wasn't your intention to have it applied to so many programs (Opera, Firefox, Quicktime Settings,...)

Not much success here either. There were no changes to be noticed in the Administrator account. In the Power User account, I got black, toothy edges on quite a few icons. I followed the directions a few posts above but to no avail. Looks like nVidia is a real show stopper, hehe...

Can you give test version 70219a a shot? It fixes the problems for me.

I can't confirm any of this. I just did a test with all hotfixes (including MDAC 2.8 SP1 and KB927779 for MDAC 2.8 SP1) and with the following in HFSVCPACK: 2K.REG AR800.exe (Adobe Reader 8.0) DNF11.exe (.NET 1.1) DNF20.exe (.NET 2.0) jre600.exe (Sun Java Runtime 1.6.0) Everything installed as intended and Windows Update shows 0 updates. I also did a test with some INF files in HFSVCPACK. There are problems with those, but they didn't break the installation of other components. Make sure the KB927779 hotfix you have is not corrupted. It should have a size of 1,872,168 bytes.

I'll do some extensive testing with Windows 2000 myself but it'll have to wait until tomorrow. I'm way too tired now...

The changes you have made resemble what HFSLIP 1.2.2 would've done so if it worked before it should've worked now too. Are you sure you didn't change anything in the INF files? I can see two other potential reasons but they would've caused INF installations to have failed ever since that feature was introduced...

The current HFSLIP test release already slipstreams IE7. Thanks anyway...

The only difference between 1.2.2 and 1.3.0 is that the INF file names including their path are quoted in the installation command. If you know how to rebuild the ISO manually, then edit HFSLIP.CMD to remove the quotes in the lines that install your INF files. I hope the quotes are not the problem...

Uh... They should all be supported with HFSLIP 1.3.0. If the only requirement is .NET 1.1 then place them in HFSVCPACK_SW (along with a silent .NET 1.1 installer in HFSVCPACK). Otherwise, place them in HFGUIRUNONCE (with a silent .NET 1.1 installer in HFSVCPACK or in HFGUIRUNONCE; if in HFGUIRUNONCE, rename the files if necessary so that .NET 1.1 is installed before your MSIs -- they are handled alphabetically).

Are all your HFSVCPACK files present in SOURCESS\I386\SVCPACK? If so, can you ZIP HFSLIP.CMD from the same folder and attach it here?

@Yzöwl It looks like it's possible after all. Looking at setuperr.log, I noticed 5 IE7 files (and later another one) had caused problems. I decided to use the same technique on them as on iesetup.dll and that seems to fix every problem I experienced, ie: thumbnails and User Accounts graphics. Enjoy this release

Sorry; I keep forgetting to reply to this.It has been dropped a while ago as you noticed. I'll work on it some more but the first versions will only install the MCE hotfixes at T-13 or at GUIRunOnce.

Not that I can remember. IE7 slipstreaming was simply dropped since HFSLIP 1.2.0 (December 7) because of all the problems. With that release and those that came afterwards, the IE7 executable is copied into the source and installed at T-13 or at GUIRunOnce (depending on what the user specifies in HFANSWER.INI), and the latest final adds support for IE7 hotfixes by slipstreaming them into the IE7 executable. When slipstreaming IE7 into the Windows source, the missing entry in iesetup.dll is still causing an error message to pop up during Windows setup, yes; I noticed that too yesterday during the test (I made a new version of HFSLIP based on the current final that slipstreams IE7 again). I will continue testing but I don't intend to unleash an HFSLIP version that slipstreams IE7 until at least the thumbnail issue can be fixed.

Yes; thanks. I updated the title but not the line below.

I don't know if RunOnceEx problems were fixed because I never had them, but I can confirm the Quick Launch problem was fixed. The other issues, however, still remain: * broken icons in Control Panel > User Accounts * broken thumbnail view in folders It looks like the non-public hotfix didn't make it into the new shell32 update...