Tomcat76

Don't know if this was fixed yet but I thought I'd mention it just in case I recently asked someone to give me his TXTSETUP.SIF file and noticed a misplacement of two files: msfeeds.mof and msfeedsbs.mof. nLite puts them in WINDOWS\system32\WBEM but they need to be placed in WINDOWS\WBEM. I know it sounds strange (especially since only those two files reside in there), but just check update.inf from the IE7 package. You'll see... Also, installing IE7 by hand, those files are placed in WINDOWS\WBEM.

Just a little heads up on how things are going with the IE7 implementation... Fixed/worked around: - iesetup.dll from the IE7 package is used, but it needs to be copied at a later time during Windows setup (doing it at T-13 now) - Internet Options dialog appears (yay!) Still to fix: - wininet.dll from IE7 can't be used and I don't know how to replace the IE6 version at a later point during Windows setup; it seems this file is in use from the moment there's a GUI - IE7 can't access the Internet and PING to Internet sites fails; however, Automatic Updates does work and both Opera and Firefox can browse the Internet without problem - the language bar appears on the Windows Taskbar Problem I didn't notice before: "Show desktop" is no longer there in the Quick Launch menu BTW... There's an error in nLite's IE7 implementation. I'm gonna notify them of this.

Closing in, but still a long way to go. The title is back, the tab bar is there, and it displays an error page when there's no Internet connection (it wouldn't do that before). Problems to tackle: - iesetup.dll still can't be used - wininet.dll *may* not be usable (need to check again because I deleted the IE7 version) - IE7 can't access the Internet and PING doesn't work, but Automatic Updates does work - Internet Options dialog won't appear "due to restrictions" which I didn't impose - the language bar appears on the Windows Taskbar

Thanks for that, Camarade Tux. I already noticed a few differences.

Yzöwl... ECHO>>ECHO>>... How embarassing... Please look for version 1.0.3. It's becoming customary to see a new final the day after, hehe. I hope I can now focus on IE7 and WMP11...

Does anyone have SYSOC.INF and TXTSETUP.SIF for an nLited XPSP2 with ONLY IE7 slipstreamed? Language doesn't matter...

Yzöwl: I've tested both of your suggestions and they work. They made it into the new final. Hopefully we can get to the bottom of your problem now

Ho, ho... I never said it was correct. Just thought that you were still speaking of the problem you're struggling with. I'll test your suggestion. If you scroll down a bit on the page I linked to you'll see that it's done both ways. I opted for the quotes because it's generally "safer" to use them in INF files (with some exceptions). But I'll test this out too.

Camarade Tux... Pressing the Alt key didn't help. Perhaps I need a hotfix to get the tab bar?

You've resurrected an old post. Both LegitCheckControl.cab and KB905474 are supported by HFSLIP.

Yzöwl... If the error still shows after removing MP10Setup.exe then it's less likely caused by the improved WMP slipstreaming. The only thing else that "passes" that code is wmfdist.exe and wmfdist95.exe. Concerning the RunOnceEx line... That line was there even before I started helping TommyP. It was never a problem and it certainly cannot be the reason for the problems you're having only now. The [sourceDisksNames] section was made just like it's done by others and I read this guide for it.

It SLIPSTREAMED it? You sure? I tried it again last night with HFSLIP and the two files I mentioned before (wininet.dll and iesetup.dll) still aren't accepted by Windows Setup. Other problems I noticed: - there's no title for the IE7 window (neither in its title bar nor in the taskbar button) - Internet connection is broken Incidentally... How do you "go Home" with IE7? And how do you get the "menu bar" (File, Edit, View,...)?

I did some tests with RC1 some time ago and there were a few files such as iesetup.exe and wininet.dll that caused trouble. I'm going to check it out again soon.

Yzöwl... Please extract MP10Setup.exe, open DRM10.inf and look at the [regwmp.dlls] section. Then tell me if I'm wrong. Maybe you misunderstood me. What I was saying is that it isn't the first time MS release a hotfix that contains a broken binary or a binary with a broken registration section. There's "webvw.dll" in localized versions of post-SP4 hotfixes for Win2K and also "inetcomm.dll" from the OE 5.5 cumulative for all languages. There could be more. @Super-Magician No, it isn't ready. I just left it in so you can get used to the new size

According to the DRM10.inf file from the WMP10 package, MFPLAT.dll needs to be registered. If you get a registration error for that file, one of the hotfixes you use probably contains a corrupt version. This wouldn't be the first time...

Can't be done. The biggest hurdle is that DOS can't parse sections of a file... like search for the header [Whatever] and output anything below it until the next header.

Got it going when pre-extracted in HF\WMP11, but it still needs a bit of work: the post-install wizard of Windows Setup is nuked. WMP11 is working, though

@Yzöwl In that case, please check that all files listed under the [RegDLL] and [sourceDisksFiles] sections in HFSLIPWU.INF are present on your install share as well as on the hard disk after installation. That's all that could cause HFSLIPWU.INF from being parsed entirely. @Super-Magician No, that isn't intentional. Probably your DOS date settings are different from mine. I'll change the code a bit.

I need the individual files from the WMP11 package. It's really a shame, because I thoroughly checked out the package, made notes, and finally got around to coding it into HFSLIP (161KB!) today. But this code is useless if the package can't be extracted from DOS. However, I think I'll allow people to extract it themselves into HF\WMP11. That way, HFSLIP can do something with it.

Bad news. WMP11 can't be done. MS made it so that you can't extract it from DOS. Gives a warning about an "invalid Win32 application". I've tried different Type1/2 switches, 7za.exe and EXTRACT.EXE (for the hell of it) and nothing works. I'm only able to extract it manually from Windows...

My point was that if the "dummy entries" aren't needed when TXTSETUP.OEM is used but they are when TXTSETUP.SIF is used, then there might still be an easy way out: put the SYS files which aren't supposed to be parsed by HFSLIP in the FIX folder. That way, HFSLIP doesn't add the unnecessary entry into the [sCSI.Load] section, and as a consequence you don't need to add dummy entries into STORAGE.INI.

Not yet. It's being worked on. This was discussed just recently...

Quite a delayed error report, then. HFSLIPWU.INF is executed somewhere around T-25~19 when SYSOC.INF calls it. That snippet you posted from it is added to the registry at that time. At about T-13, during an internal reboot, those entries are parsed by Windows.So don't you think it's strange that you only get an error message after first logon? You should've gotten one immediately... You use the "PROGRAMFILES" feature, right? Was everything copied to the hard disk?

Yzöwl... When do you get that first error? Is that while running HFSLIP or during installation of Windows? I suppose "root" is your rename of the "Administrator" account but I wonder why it's echoed in the DOS box in that way. The snippet you posted from HFSLIPWU.INF couldn't have directly caused an "installation error". That part does nothing more than adding entries into the registry, which need to be executed at the next (internal) reboot. As far as those hotfixes are concerned... First of all, I find it strange that you have all those entries in Add/Remove Programs. Do you use a custom version of that application? KB898461-- Do you have spcustom.ref, spmsg.ref, spuninst.ref, spupdsvc.ref, update.ref and updspapi.ref in your updated installation source? KB918899-- Can't see what could be the problem here at first glance. KB885836-- Seems that HFSLIPWU.INF didn't get parsed in its entirety, more specifically this line: HKLM,"SOFTWARE\Microsoft\Updates\Windows XP\SP3\KB885836","Type",0,"Update" Unless that line was only there to satisfy MBSA. I forgot...

They are