No, I don't have a problem with that. Go ahead.

I was going to add a bit about control panel entries to my previous posts, but they are all buried in this thread. I'll do it anyway and hope that TC doesn't mind too much

YourCPL


Folder2MyPC

Does anyone have any idea why whenever I try to use any build of 1.7.4, I get weird non-hidden desktop.ini files in my start menu and all subfolders within the start menu? Building an updated SOURCESS folder with v1.7.3 does not produce this problem. If you need me to rebuild with v1.7.4rc2 and send off the HFSLIP logs, just ask.

I'm using HFSLIP without problems and many thanx to all of you still improving this very useful "slipstreamer".
Anyway I can't figure out some things:
1. why is showing Roots Update in MS Update even the newest rootsupd.exe (12/13/2007) is in HF folder? is there somethenig else I miss to configure?
2. why WindowsXP-KB925877 (RDC MUI update) can't successfuly integrate? Just because it is MUI?
3. why Windows Live messenger 8.1 isn't installed even in HF folder and Msnexplr=On is set in Components (just the old version 4)?

Thanx for any answer. BTW I'm doing a standard (so nothing special) Windows XP Sp2 English slipstream.

FYI Also find out that there is a new MUAuth.cab, guess replace the old one in HFCABS folder

1. I don't have this problem on a test install I did yesterday, so it seems like you miss something. Have a look at Tomcat76's hotfix list and such to correct it.
2. I don't have KB925877 in my HF folder. I can't check at current if it's replaced or something, but since it's not in my HF folder, I'm positive that you won't find it in Tomcat76's update lists either.
3. MSN Explorer is not the same as Windows Live Messenger (used to be called MSN Messenger). If you want to include Windows Live Messenger, you'll have to create a switchless, silent installer package for it and place it in your HFSVCPACK folder. There is a short tutorial on here somewhere on how to create your own Windows Live Messenger package.

Dawid...

In general, the answer is that HFSLIP was made primarily to "satisfy" Windows Update as far as components are concerned that are part of Windows (with a few exceptions such as WMP9 for Win2K). Adding other hotfixes and programs MAY work, but there's no guarantee; HFSLIP assumes certain standards with regard to the internal composition of hotfixes and the destination of files that aren't present in the Windows source, so if there are any that need special treatment (renaming of files, non-standard locations, etc.) they won't be slipstreamed correctly.

1) If you're using the roots update from 12/13/2007, either the file you have is corrupt or something went wrong during its installation at T-13. See my hotfix list for Windows XP and remove anything that isn't listed. If this works, you can start to experiment with other hotfixes.

2) KB925877 contains many files that need special treatment. This hotfix isn't covered by HFSLIP because it doesn't show up on Windows Update. I could create an HFSLIP plugin for it if I have some time to spare, but why aren't you just using WINDOWSXP-KB925876-X86-RUS.EXE?

3) MSN/Live Messenger isn't part of Windows. If you want this handled by HFSLIP, you can extract MsnMsgs.msi from the exe and place it in HFSVCPACK_SW1.

Thanx Tomcat76 for the answer.

1. well, I doublechecked rootsupd.exe (292952 bytes) so I'm sure it isn't corrupt. Guess there will be problem with another hotfixes I'm using (see attached listing), because I'm installing Windows XP SP2 with Slovak MUI ('cause there is no Slovak localized version )
2. KB925877 shows up on Windows Update just in case of installing MUI and it's really ironic, that there is no WINDOWSXP-KB925876-X86-SKY.EXE (slovak just czech - WINDOWSXP-KB925876-X86-CSY.EXE), but it IS showing on Windows Update Maybe the same problem is with IE7MUI-x86-enu.exe
3. I think that MSN/Live Messenger IS part of Windows (see file MSNMSGS.MS_ on Windows osurce CD), but of course I can put MsnMsgs.msi in HFSVCPACK_SW1 folder. I was just wondering, if in i386 is the same file (MSNMSGS.MS_ after HFSLIP with Install_Messenger.exe placed in HF folder, it's just bigger), setup will install a newer version...

BTW arte there some new components on Windows Update, because it's requiring something to install?

Windows comes with "Windows Messenger", the one you said you were seeing (version 4.7).

If KB925877 is showing on Windows Update then you have an MUI installed. That's not supported by HFSLIP because none of use have it. This is the reason why MUI updates aren't supported.

Windows Update works fine here. As I said, something is going wrong at T-13 for you (files are not registered or INF files are not executed).

I'll need the full HFSLIP.LOG file (zipped) to know more...

Thanx Tomcat76 for your support.
I've just finished a few test with the final 1.7.4 version and discovered that the problem with roots update is gone. Also I don't know, what exactly Windows Update requiered in my previous installs, because in the last test there was no need of updating compenents. Well, sorry for bothering, seems like everything is OK now. Hypotheticly is there a possibility, that something is not processed as expected on a slower PC (like Thinkcentre E50 9216)?

Guess I forget, that MUIs aren't supported by HFSLIP.

And about MSN/Live Messenger I was just curious and little bit confused (mostly by MSNMSGS.MS_ file), but I found out, that file MMSSETUP.CAB is important in "installing" MSN/Live Messenger, so putting Install_Messenger.exe in HF folder is just useless, but perfectly processed by HFSLIP

Do you still have problems with Windows Update?

Hello Tomcat76.

I have a nice and small sugestion.

Add in folder HFGUIRUNONCE and HFSVCPACK, parser to apply EXE files in MODIFYPE existent on HFTOOLS.

On various upgrade on HFGUIRUNONCE and HFSVCPACK with my made silent install packs, is necessary apply manually modifype one by one.

It's better if hsfslip auto modifype on copy files from these folders to SOURCESS.

HFSLIP 1.7.5 No Support XP SP3 RTM v5.1.2600.5512 ~

It's being worked on. I slipstreamed it by hand, and THEN ran HFSLIP on my source folder with IE7 updates only. There seems to be some wacky problems, though. Just sit tight, Tomcat will fix the issues and release a new HFSLIP.

Hi Tomcat,

Can you add the fix for the Terminal Services Administrator Tools shortcuts (caused by the new mstsc.exe binary), like you did for HFSLIP64.

Thanks
7yler

Try RC2.

Still no luck with that .mof file missing error with RC3...

Hi TommyP

Because I am slipstreaming XP with service pack 3 for my friend, I used the latest test version... hfslip-1.7.6rc5.cmd

I noticed that there is no mention (on the very first display page of HFSLIP) of slipstreaming Windows XP service pack 3 but rather, only of XP service pack 2... just wanted to point that out to you.

Windows XP SP3 / WMP11 / IE7

Source files were copied from a Windows XP Corporate CD that was previously slipstreamed with SP2.

hfslip-1.7.6rc5.zip was unzipped to C:\HFSLIP

Ran the batch file to create the appropriate directories.

Copied the following 2 files to C:\HFSLIP\HF

1) IE7-WindowsXP-x86-enu.exe
2) WindowsXP-KB936929-SP3-x86-ENU.exe

Extracted the following file using Winzip to C:\HFSLIP\HF\WMP11\

1) wmp11-windowsxp-x86-enu.exe

Copied the source files from my XP CD mentioned above to C:\HFSLIP\SOURCE

Ran the batch file again, followed the prompts, and ended up with a SOURCESS folder.

Used CDIMAGE to create an ISO

Installed on Virtual PC 2007 for testing.

Found the install to go flawlessly.

Windows XP shows SP3 and IE7 and WMP11 both run without any problems.

Just wanted to pass along this information!

Thanks,
mechtn

Thanks for the heads up, mechtn.

BTW... You are not required to extract the WMP11 executable (except when your host OS is Windows 2000 *and* it's the English WMP11 update), but it's still OK because HFSLIP doesn't have to extract the WMP11 executable anymore which will speed up the HFSLIP run.

Hi out there,
just want to happily confirm rc5 is working great for me.

Did it to a fresh german XP SP3 source.
Added this to HF
-IE7-WindowsXP-KB947864-x86-DEU.exe
-IE7-WindowsXP-x86-deu.exe
-rootsupd16.exe
-WindowsXP-KB941569-x86-DEU.exe
-wmp11-windowsxp-x86-DE-DE.exe

Everything seems to work ok
Windows Update is quiet except for MRT
setuperr.log is clean

I didn't add the WUA/WGA stuff, I thought it might be already integrated, but no. So I still have to check with that.

thanks alot
ente

HFSLIP replaces old versions while integrating IE7 to SP3 source.

browseui.dll
ieencode.dll
jscript.dll
shdocvw.dll
shlwapi.dll
vbscript.dll

These are not related IE7. Most of them version 6. Comes from IE6 with little update.
SP3 containes higher version of script file. IE7 replace older.
In fact original setup does not touch these files. Skip them because source files are higher version.



html.iec
I dont know which one is better.
10.0.5730.13 comes with IE7 EDIT: In more informations look likes 6.0.5730.13
2007.10.31.2 comes with SP3.



PS:
SP3+WU+IE7+WMP11+rootsupd+MRT works perfect

Hi Tomcat76!

hfslip-1.7.6rc5 bug ...

Terms of test:

WinXP Pro Italian image with SP3 (VL) RTM

HF folder with ...
IE 7.0.5730.13
IE7-WindowsXP-KB947864-x86-ITA.exe

Windows Update KB947864 update requires that apparently is present in the image. While trying the on-line update is reported error code 0x8007F0F1 (Files from the package are incompatible with files on your system.).

In addition to this, is prevented the installation of the package "PDFFactory Pro" with a critical error not declared that abortion is the installation process.

After uninstalling and reinstalling IE7 is possible to install KB947864 and therefore also "PDFFactory Pro" ... ideas about it?

Thank you!

Can you ZIP and attach your HFSLIP.LOG file?

Are you letting HFSLIP slipstream IE7 or create a new IE7_INST.EXE package?

New IE7_INST.EXE package.

If there is an alternative method, you can explain to me?

In the package RAR or ZIP logs I included HFANSWER.INI for greater clarity.

Thank you!

Click to view attachment Click to view attachment

Uh, yes... The default one: slipstream. This is done by not specifying IE7SVCPACK or IE7GUILOGON in HFANSWER.INI. But leave that for now.

Is everything OK if you remove any IE7 updates from the HF folder?

What the RC of HFSLIP 1.7.6 is doing with IE7 updates on XP SP3 isn't really favorable as eryen pointed out above. We're five days away from the next Patch Tuesday so I will just let the final HFSLIP 1.7.6 handle IE7 updates as usual.

Sorry, I go to bed ... I try to wake up ...

1/2 OK...

Without the merger of IE7 update the installation is clean, but it's impossible the manual update of KB947864: install error - "File of the package not compatible with files in the system.".

This means that ie7_inst. exe is poorly constructed?

Now I try after delete of all MP11 update (probably unnecessary) and, after HFANSWER.INI modify, I will try with the slipstream, although I imagine by messages in tread, that everything will be fine... in case you will let you know in short time.

bye

Click to view attachment

@Tomcat

IE7 upgraded for problem with SP3..? (hash is the same...) Now I test with new (?) version...

It's the same version. The executable's size is the same, the time stamp is the same, and all files within have the same date.

The problem with IE7_INST.EXE was that the SP2 binaries weren't force-copied. HFSLIP 1.7.6rc5 only did that when IE7 was slipstreamed. This problem should be fixed in 1.7.6rc6.

Uhm... Make that rc7. There was a tiny bug in rc6...

That's what happens when you work on HFSLIP 2.0 at the same time, heheh...

@Tomcat

I confirm ... all ok!
Now the installation is clean and the system is properly updated.
Today try the slipstream of IE7 and if everything is ok I will use the tacit consent ...
Again thanks for all the good work, and best wishes for the future!

Hello all, i got the latest version of hfslip(rc7), but he don't split my messenger.msi.

I put the messenger.msi file in HFSVCPACK_SW1 folder.

My Windows have SP3 (final version) and i got this version in MSDN home page.

Somebody have this problem too?

Sorry for my terrible english!

I integrated SP3 with nLite and next I remove components, disable services e integrate addons.
All run fine in my Vmware, compiled autoit scrips too.
I used hfslip-1.7.6rc7 to integrate few hotfixes and cabs, install in Vmware and autoit scripst fail to exectute.
One error is "framedyn.dll not found" and the other is "-1 - variable can be object".
The final result is theme not applied and other "replaced" programs not installed.

What are the problem with autoit scripts found for you?

0d

Click to view attachment
Click to view attachment

HFSLIP should always be run on a clean source.

If you wan't to use HFSLIP together with nLite, then you'll have to use HFSLIP first.

Please redo on a clean source and report back if problems persists...

@Ehdu
It appears that messenger.msi can't be installed at T-13. Someone else already noticed that.

@0d14r3
From what you're saying, it is unclear to me if you used a clean source for HFSLIP or not. As Martin H points out, you should first run HFSLIP on a clean source.
If you used HFSLIP first and then nLite, then the problem might be that you don't know what the HFSLIP_POST_getnewfiles_v3.cmd plugin is for. If this plugin is in the HFTOOLS folder, a file named NEWBIN.TXT is created when HFSLIP has finished. This file contains the file names that you should enter in nLite's Keep box. I can't see any trace of the files that were slipstreamed by HFSLIP in the [KeepFiles] section of nLite's LAST SESSION.INI log you provided.

1 - SOURCE= WINXP SP2
2 - nLite SOURCE integrating SP3
3 - SOURCE=WINXP SP3
4 - copy SOURCE to OS
5 - nLite OS with addon+remove components+disables services = ISO_OS
6 - Install ISO_OS in Vmware = all ok, include addon with compiled autoit scripts
7 - Delete OS

NOW WITH HFSLIP
1 - HFSLIP SOURCE (3) with few hotfixes and cab files (using hfslip-1.7.6rc7)
2 - SOURCESS is created
3 - copy SOURCESS to OS
4 - nLite OS with addon+remove components+disables services = ISO_OS
5 - Install ISO_OS in Vmware = framedyn.dll error, addon with compiled autoit scripts= error, many addons not installed
6 - Delete OS

More clear my frieds?

This sequence I ever use with SP2 and hfslip-1.7.5 without errors . I try with SP3 and back to report.
`
EDIT: hfslip-1.7.5 works fine, no errors, all installed.

0d

I make the same error in my last XP version

I got a clean XP copies with SP3 (generated by MSDN)
I used HFSLIP to integrate WMP11, IE7, DirectX and Flash, and generating the NEWBIN.TXT
In Nlite i removed Windows Messenger, NetMeeting and MSN Explorer. And used the NEWBIN.TXT.

When completed the installation occurred the same error, "framedyn.dll not found" and the other is "-1 - variable can be object".

Look the result of wbemoc.inf, before nlite and after:

Does everything work if you replace WBEMOC.IN_ created by nLite with the file that HFSLIP made?

I want to see if this solves the problem.

WBEMOC.INF is partial corrupt made by HFSLIP.
That is an UNICODE file but not contain FF FE binary string at the begining of file.

I just realize that while testing WMP11 Slipstreamer.

Your nLite'd Wbemoc.inf is totally corrupted.
Double UNICODE converted. Or something like that...

String look like UNICODE but new line stings still ANSI.
Maybe other files are corrupt like this.
With that file WinXP will not install correct.

I also noticed the nLite'd file is in ANSI and that it's broken.

As far as the one modified by HFSLIP is concerned... If the original wbemoc.inf is in UNICODE, HFSLIP will use FIND.EXE to remove the instances of napclientprov.mof and napclientschema.mof from that file (because FINDSTR.EXE can only be used for ANSI files). There's no other option. I'm in the process of creating an HFSLIP plugin that includes edited wbemoc.inf files for both Professional and Home, and for all languages, but that's still going to take some time.

Either way, the resulting file is in UNICODE and Windows installs fine if you don't use nLite after that, so I don't understand why nLite has a problem with it. Is it that "FF FE binary string"? Does the lack of it prompt nLite to treat is as an ANSI file? Whatever it is, I don't have another option right now.

If u look at files with HEX Editor. UNICODE files has that FF FE string at the begining to define this is an Unicode file.

WBEMOC.IN_ is partially corrupted.

Best and easiest way is.
copy /b unicode.header+wbemoc.inf


Attached unicode.header containes FF FE unicode definer.
Wbemoc.inf becomes real unicode file.


Also.
I created a CD.
Rootsupd, 905474 and WUA slipstremed with HFSLIP.
WMP11 slipstreamed with WMP11Slipstreamer by booggy (las version modifies wbemoc to. After hflisp can not read this file. )
IE7 with nLite.
Messneger, DrWatson, MSN Explorer removed.

There is no error, with it.
wbemoc is not corrupted. (nLite didnot touced it atleast)
wbemoc made by HFSLIP works on that system.


In past i saw that framedyn error too.
I was using a personal inf files, included all my setting. (More then nLite)
In last 2 mounth, if i include that inf file i see that error.

There is an tweak corrupt my installation. I dont kow which. I dont have enoght time to check all of them, one by one.

Yes, i changing the file and worked perfectly.

Just completed my VMWare test installation of Windows SP3.

I use RC7 to slipstream SP3, and then rest of the updates. Attached the log file.

Just to report back, Windows install perfectly, and no high priority updates after running Microsoft Update.

However, when initially running Microsoft Update, it requested to install the activeX components, and then restart the PC before I continue running MU. It looks like the MUAuth.cab did not take, either because the slipstreaming process failed or Microsoft has a new version. I am not sure which, but MU does appear on my start-up menu, so I suspect it is the later.

The 2nd weird thing is that if I leave out KB905474 during slipstreaming, windows will download KB892130 and try to install it before allowing me to continue with MU. It keeps failing to install KB892130, which is why I go re-do HFSlip with KB905474, since I cannot find KB892130 for download.

Finally, when I start WMP11, it will ask to run WGA as part of the first initialization. This did not happen on my previous pre-sp3 HFSlip slipstreams.

None of the above are big problems, but I hope it helps in getting the next version of HFSlip ready.

Thanks.

I'm doubting as to what really the best solution is: "unicode.header+wbemoc.inf" or just custom made wbemoc.inf files in a plugin package.

HFSLIP edits wbemoc.inf to avoid the error message for "napclientprov.mof". You see that error because wbemoc.inf wants to copy napclientprov.mof (and napclientschema.mof) from the CD, but it doesn't exist in the source with that name. MS have renamed it to napprov.mo_, and not even in a clean way: they compressed napclientprov.mof to napclientprov.mo_, then renamed napclientprov.mo_ to napprov.mo_ (instead of first renaming and then compressing). So they probably intended to have it on the CD with a long file name originally. But the guys who did TXTSETUP.SIF/LAYOUT.INF decided to rename it but didn't notify the people who did wbemoc.inf. --- It's always nice to come up with theories...

The best way to work around the problem would be to change this:
napclientprov.mof
napclientschema.mof

...into this:
napclientprov.mof,napprov.mof
napclientschema.mof,napschem.mof

But that's not something HFSLIP can do, so it just removes the lines. This is not really a problem because the files are also copied via TXTSETUP.SIF (wbemoc.inf just does double work), but it's not as clean.

So using "unicode.header+wbemoc.inf" is much easier for me, but it's pushing the use of the unclean method. For the end user it shouldn't be that much of a difference in that both scenarios would require an additional package to be downloaded.

@kenlau

You don't have WindowsUpdateAgent30-x86.exe in the HF folder. It's one of the requirements for Microsoft Update.

KB892130 is LegitCheckControl.cab.

I don't know about running WGA for the WMP11 initialization. I never had it. Is your LegitCheckControl.cab up-to-date (20-Mar-2008)?

nLite does not switch ansi/unicode, it detects the file encoding. Maybe you are saving file so weird that it messes up encoding detection, anyway let me know on the PM if you find something for sure.

Hi Nuhi

I'm using the only way there is with FIND.EXE while keeping it Unicode.

But it doesn't really matter anymore. I found a minor problem with this method affecting some languages so I'm gonna steer away from it.

Thanks for dropping by.


To the others...

I'll be releasing a final version of HFSLIP 1.7.6 shortly (probably tomorrow) which will contain all the changes mentioned in the changelog except the fix for wbemoc.inf, but will only post it here in the Test Releases thread. An external plugin package should be ready by tomorrow too so this combination can be tested extensively (including with nLite). If everything's alright with the plugin package, I'll make the final HFSLIP 1.7.6 public.

Thanks TC,

I would have thought M$ will update Update Agent with SP3, but I guess not. M$ giveth, M$ taketh away.

Anyway, I am retrying again, and will post if anything strange turn up.

The HFTOOLS plugin to fix wbemoc.inf is now available from the main post in this thread.

I released another RC because I pushed in a change for Chinese (Hong Kong).

If all works well with this set up (with and without nLite), then a final version of HFSLIP 1.7.6 will be released tomorrow.