Tomcat76

Based on that info, it sounds to me you're using either IE6 on WinXP with SP2 or IE5.0. If it's the former, make sure you aren't blocking any scripts on those pages. I've verified the pages to work with: - IE6 (IE 5.5 should work but I can't check that) - Mozilla Seamonkey 1.0b - Mozilla Firefox 1.5 - Opera 9 Preview 1

Reload and try again. Does it still happen?

@TommyP: v1.1 is supposed to replace v1.0, but v2.0 is a "new technology". @hevnbnd: 1) I suspect "dotnet11sp1.exe" is RyanVM's installer. It includes the KB886903 update so you don't need it in your HF folder. 2) When including .NET 1.1, you no longer need the update for .NET 1.0. 3) Rename all files in the HFSVPK folder to a maximum of 8 characters.

Nope... Wasn't it. I'll check some more tomorrow...

I think I know. I'll be back.

Does that come from a log file?

Uh... Just thinking... Do you have MSICabExtract.exe inside the HFTOOLS folder?

That's strange. No... it shouldn't matter. The MSI and the EXE are handled by different sections of HFSLIP, and I was also using msxml4.exe (my installer) alongside msxml6.msi. The only thing I can think of is that you have to run HFSLIP with administrative rights.

They're different technologies. A coder would even have to "ask" for them specifically. "some.command" is handled by MSXML3. "some.command.msxml4" is handled by MSXML4. "some.command.msxml6" is handled by MSXML6. In 99% of cases, MSXML3 will do. I haven't come across a "real-world" script yet that requires MSXML4 or 6 (at least not knowingly). Only test scripts and examples...

Found it. HFSLIP has this line: DIR HF\*.EXE /A-D /OGN /B /ON >>ERROR_REPORT.TXT It outputs only the .exe files into ERROR_REPORT.TXT. To check if MSXML6 got integrated: See if msxml6.dll and msxml6r.dll reside in SOURCESS\I386. To check if UPHClean got copied: See if UPHClean.msi exists in SOURCESS\I386\SVCPACK.

I've been integrating MSXML6 for about two weeks now and never had an issue. Did you put it in the HF folder? I'll check out the UPH thing. I've been digging inside the HFSLIP script for the past couple of weeks and saw lines to do a silent install of it so I decided to add it to the list. I'll be back... Edit: Did you delete ERROR_REPORT.TXT before running HFSLIP again?

WinXP SP1: there used to be a bug a while ago but it should be fixed now.WinXP SP2: I noticed that too but I thought it was "normal". Should there be a background music there? I don't remember because it's been a while since I installed an unpatched WinXP SP2...

The WinXP page is done and there are a few minor improvements to the Win2K page. "Phew..." Hehehe...

You're welcome. It's now "official", and I'm currently working on the WinXP page. It's finished as far as SP2 is concerned but I want to have SP1 supported too before releasing it...

At this point, I mainly need results from the following people: - those with Windows Server 2003 - those who have problems with slipstreaming in general

So what's your middle name then? Script updated. I opted to delete "svcpack.inf" instead of "svcpack.in_". I'd say let's see how this goes first...

[Attachments removed] This script slipstreams the service pack into a Windows source that's located in HFSLIP's SOURCE folder. Instructions: 1) Put the CD source in HFSLIP's SOURCE folder 2) Create a folder called HFSPACK inside the HFSLIP folder and put your service pack file in it 3) Place one of the attached scripts in the HFSLIP folder and run it 4) Have patience The difference between spslipA-060126-1.cmd and spslipB-060126-1.cmd is that "spslipB" blocks the slipstreaming process if the source has already been patched. *** spslipA *** Service packs supported: - SP4 for Win2K - SP1a for WinXP - SP1 for WinXP - SP2 for WinXP - SP1 for Win2K3 You can have both SP1 and SP2 for WinXP in there, but only SP2 will be processed in that case. Slipstreaming SP1, SP2 or SP3 for Win2K into any version of Win2K is not possible. WinXP can be patched from Windows 2000. *** spslipB *** This one is supposed to become the final version. The following table explains which service packs are supported for which OS version. SOURCE HFSPACK -------------------------------- Win2K Gold SP4 Win2K SP1 SP4 Win2K SP2 SP4 Win2K SP3 SP4 Win2K SP4 No SP supported WinXP Gold SP2, SP1a or SP1 WinXP SP1 SP2 WinXP SP1a SP2 WinXP SP2 No SP supported Win2K3 Gold SP1 Win2K3 SP1 No SP supported The service pack versions are sorted by preference. If more than one service pack is included in the HFSPACK folder, the one with the highest preference for the OS version in the SOURCE folder is used and the others are ignored. For now, this only applies to "WinXP Gold". WinXP can be patched from Windows 2000. The following are not possible: - slipstreaming SP1, SP2 or SP3 for Win2K into any version of Win2K - slipstreaming SP1a for WinXP into a WinXP SP1 source *** Technical details for spslipB *** Stage 0 If the HFSPACK folder exists and there's at least one file in it, Stage 1 is called. Stage 1a Check if individual hotfixes have been integrated into the source before. If that's the case, display an error and EXIT immediately after the user clicked a key. Stage 1b Check if the source still needs to be patched. If not, display a message and stop the slipstreaming process. If the source DOES need to be patched, proceed with Stage 2. Stage 2 Check if the service pack in the HFSPACK folder is accepted for the OS in the SOURCE folder. If it isn't, display an error and stop the slipstreaming process. If the service pack IS accepted, proceed with Stage 3. Stage 3 Patch the source. In spslipA, Stage 1 is skipped (Stage 0 calls Stage 2). Revision 1: Changed the name of the SP folder and the script is now deleting "svcpack.inf" if it detects it. Use the new file with the description above. Revision 060126-1: distinguish between XPSP1 and XPSP1a to fix a "collision"; created second version preventing unneeded SP slipstreaming Revision 060126-2: removed an unneeded PAUSE command that was used for testing; solved issue leaving behind "svcpack.log" in the HFSLIP folder Revision 060126-3: unbloated the scripts a teenie little bit; no functionality changes from rev. 060126-2 Revision 060127-1: added more "validity checks" (see "technical details")

Good catch. The underlying script is doing what it's supposed to do, but I forgot to include the line that displays that file altogether. I'll fix that asap. Both. The guy concentrates on critical hotfixes, whereas my list includes optional hotfixes too.

I'm working on extending the usability of my hotfix lists. Some people have asked for TXT files listing the contents of various folders, but I thought it would be too much hassle given there are so many options with HFSLIP. The solution I'm working on now should be far easier. Read the last paragraph in the Notes section at the top and continue from there.... http://tomcat76.open-theweb.net/pages/winup/_win2kdyn.html

(Edited) The problems you speak of are among the "bugfixes". Please try out the January 22 release.

The hotfix would be processed before msxmlcab.exe even if you rename the files because the latter is not a hotfix. The :msxml section is processed after the hotfixes. HFSLIP will have to be modded so it only retains msxml4.dll from the hotfix, and the :msxml section should either be called before the hotfixes or be altered to check for the existence of the newer msxml4.dll in the working folder. However, international users are still not covered because there's only an English version available of msxmlcab.exe. They need msxml.msi instead. At this point, HFSLIP embeds the SDK when you include msxml.msi. You can change that script section to install only the "viewer", but then what about the people who actually want to have the SDK? TommyP would have to add an additional page at the beginning of HFSLIP asking you what you want to do... "Press A for viewer, B for SDK, or C for both." Can you imagine? On the other hand, you have to run the script in this thread only once and it's easier to maintain one file.

I've updated the entire description. I hope everything is crystal clear now.

Sorry if I came across like that. I'm accepting all comments, but if I think something is going to make things "worse", I'll say what I think...

Uh, no. msxmlcab.exe contains an older version of msxml4.dll. The whole point is to get you the most recent file. It's not forbidden to leave it in, but then you'll end up with the old version again because "msxml4.exe" is processed before "msxmlcab.exe".

Would you mind posting it again? I no longer have an unaltered version. That's a bit exaggerated. My script renamed the msi's for other languages to "msxml.msi" but left the English version alone since it's already called "msxml.msi". Your script (as well as my current version) doesn't exclude the English version; it renames "msxml.msi" to "msxml.msi" too. It's debatable which solution is the "least bloated". No. The resulting file is the same.