Tomcat76

Something about not being able to start the application because framedyn.dll couldn't be found. Reinstalling the application might fix the problem. dziubek... Can I see your TXTSETUP.SIF? It appears one of the variables in an addon package slipped through the filter.

He's using the correct hotfixes according to his ERROR_REPORT.TXT file. The problem doesn't lie with HFSLIP, but I also think there's nothing wrong with the hotfixes. MS would fix a problem like this...

Personally, I think there's nothing wrong with those hotfixes. KB897715 was released in June 2005 and KB823353 in June 2004. MS usually don't care about slipstreaming problems but you have a general installation problem which MS would've fixed by now if it's so obvious.

This is difficult. You are the first German to report a problem with the OE updates. I can't just remove DLLs if not all Germans are affected by it. You also mentioned having problems with inetcomm.dll. Combine that with msoe.dll and you get the KB897715 hotfix (only those two files are updated by it). When you did the "completely manual" install, did you use the same IE6 setup file as the one you used to get the CABs for HFSLIP? If so, I wanna check something. I did it myself with the German IE6SP1 and I got these: BRANDING.CAB (8 252 bytes) IEW2K_1.CAB (1 861 786 bytes) IEW2K_2.CAB (1 719 135 bytes) IEW2K_3.CAB (1 883 001 bytes) IEW2K_4.CAB (2 143 524 bytes) MAILNEWS.CAB (1 975 897 bytes) OEEXCEP.CAB (20 116 bytes) SCRIPTDE.CAB (822 707 bytes) WAB.CAB (606 147 bytes) Are these sizes identical?

Just to be sure: did you include SP2 in the HFSPACK folder? That might be a good idea to test. Slipstream SP2 and the supported hotfixes into it using HFSLIP and then install it through VM. If this works, your disks are custom made by the manufacturer you bought your computer(s) from and can't be used. For now, I'd recommend using A, B or C to exclude any problems with SPX.CAB. I use B myself but it's up to you.Do remove those additional files as Super-Magician says. You need to get a working base first. No, it doesn't. I'll add it in the next update...

So there are no problems using Livestate if you don't include Package Installer? For the winnt.exe method... Open DOSNET.INF in Notepad and find the last instance of [Files]. Create a blank line below it and type this in it: d1,disk1 Do you still get 81 copy errors then?

I see now that msoe.dll is not being registered so the fix won't matter. If it *would* be registered, it might have worked. Do you have the same problem on a "normal" (non-HFSLIPped) installation?

This file is for Windows XP SP1: Q828026.exe These files are not supported (never tested): DECCHECKSetup.EXE WinColorSetup.exe WindowsDesktopSearch-kb911993-x86-ENU.exe ADMFiles_WindowsXPSP2.msi CalcPlus.msi ClearIECache.msi MsgFilt.msi RAWViewer.msi TimeZoneSetup.msi UFDSetupWizard.msi These are not needed for a default install (and are untested): KB832414_MSXML4.0_x86.exe msxml4msms.exe But I don't think removing these will fix the problem. Are you using a clean source now (fresh CD copy)? I don't think HFSLIP does anything to mess with the stuff that happens at T-9. Do you have an error report in the WINDOWS folder that contains more information? There should be several setup*.log and setup*.txt files there. BTW... I edited your previous post and mentioned the reason at the end (below your name).

This is isn't the Firefox or Opera forums... I think that's what it is... As far as I'm concerned, you can't really compare HFSLIP to Norton Ghost. For starters, an HFSLIP share is ready BEFORE installation and a Ghost image AFTERWARDS... HFSLIP creates the base... the Windows CD. Norton Ghost makes a copy of a hard drive (in this case containing a Windows installation). That's two completely different things. The only "relation" between the two is that you can make an image of an HFSLIPped install.

OK. Try test version 60404a. It should work around the problem with msoe.dll. If you *still* get into problems, the newer msoe.dll is damaged completely but I doubt that's the case.

OK. I just wanted to be sure you weren't just swapping DLLs. One more thing before I release a new test version... Do you have "kb897715-oe6sp1-20050503.210336.cat" in SOURCESS\I386\SVCPACK? Does it still exist on your installation CD?

That's good to know but do you still get errors after you install the full updates manually (ie, run the two executables)?

When you exclude that update when running HFSLIP and install it manually afterwards....- do you get error messages starting Outlook Express? - does msoe.dll then have the version that's inside KB897715 (6.0.2800.1506) or is it an older version? This can be fixed by HFSLIP but I need to know the answer to the above two questions.

I take the descriptions from the MS Security Bulletins if available. I guess I could change this one to "Vulnerability in Windows Messenger" as the update for the standalone WMP9 has recently been replaced and nobody is integrating MSN Messenger 6.x. It is a PNG vulnerability affecting three applications but only one is of relevance now... Just to be sure that we're on the same level about "DOS-based installs"... I mean: boot with an MS floppy with CD support and then type something like F:\I386\winnt.exe to start the CD.

Actually, in the 60317 version, you'd get the ISO created twice if both cdimage.exe and mkisofs.exe exist in the HFTOOLS folder. I changed that so it would only use cdimage.exe in that case (60331) but I had a talk with TommyP and we came to the conclusion that it's better to use mkisofs.exe. It shouldn't really matter... Why would one place both applications in the HFTOOLS folder anyway? Haha... The power of HFSLIP? Make sure all files in the SOURCE folder are not set to read-only before (and after) integrating the service pack.

I'd actually prefer something in 8:3 format. HFSLIP_LOG.TXT surpasses that... The "File not found" errors are to be avoided. They are there because HFSLIP copies/deletes/renames files but doesn't always check if they exist first. It's a split decision between seeing errors fly by and having a script that's 10 times bigger. About the only section I've "cleaned up" recently in that regard is the part that does MSXML but I only did it because I found a much better way of processing the MSXML files which resulted in a much more compact section.

It's really sounding as if your IE package is corrupt or not updated. Did you download the installer from Microsoft and then update it per the instructions on FDV's site?

Not really. The only difference is that you're specifying a time stamp but you can do it with HFSLIP too by adding -txx/xx/xxxx,xx:xx:xx to the list of switches for CDIMAGE in the ISOconf.txt file.

It is now. 60403c. Out of curiosity... If any of you would replace expand.exe through HFSLIP (so Windows gets installed with another version), where would you put it? In the FIX folder or in HFEXPERT\APPREPLACEMENT?

What if the version inside SOURCESS is renamed to report.txt or something?

Try the latest test release. It uses the full path to expand.exe. There are two locations HFSLIP check in: %WINDIR%\SYSTEM32 and the HFSLIP folder. The latter gets preference. So if the version in SYSTEM32 is not the original MS version, place a copy of the MS version in the HFSLIP folder.

poed-- Try the latest test release (60403a), include DirectX9 and Package Installer, and see how far you get with a DOS-based install. I made some changes toward compatibility with winnt.exe.

HFSLIP doesn't use extract.exe; only expand.exe. I had a quick look at the entire script and it seems to me you can get away with placing the "correct" version of expand.exe in the HFSLIP folder (for now) except for the integration of msxmlcab.exe. Checking for the file size is out of the question. On a Dutch XP system, for example, the file is 16,896 bytes large. Where can I get this cygwin version?

Good thread. I'm definitely into this. BTW... It's nice to be the first voter. Then I get to see "Should have had an interface like Windows 2000" at 100% for this one time...

New test release for Server 2K3 SP1...