Tomcat76

2K3 SP1's NETFX.CAB contains the same binaries so it should be supported. I updated the changelog.

I haven't verified that yet. HFSLIP assumes all binaries exist inside SOURCE\I386\NETFX.CAB except mscorees.dll, which is the case for 2K3 SP2.

Thanks. It should be fixed in HFSLIP 1.6.1.The problem was that if the hotfix is placed in the HF folder, the registry wasn't updated. At least this is supposed to be added: HKLM,"SOFTWARE\Microsoft\PreInstall","Path",0x20000,"%SYSTEMROOT%\system32\PreInstall" (0x20000 is REG_EXPAND_SZ) And you didn't have this time zone problem with HFSLIP 1.5.0?

A fully silent operation isn't possible at the moment but I'll see if I can implement it as an option (I'd like to keep a progress bar as the default so people know where it's at).

1.6.0, dudes

That can only mean you aren't using the latest version of SNM.CMD. Can you please download the latest version? For you, the file name should start with "XPSEPSCLANGPACK-x86-pt-PT-langpack"; whatever comes after that is your choice. That hotfix updates files of Windows. HFSLIP supports it and I'm sure nLite does too.

Do you see the message "Processing netfx30-kb932471-x86.exe..." in the SNM box?

Seems to work without a glitch. I'll release an RC later.

SNM didn't have to be updated for these. Patches for .NET 1.1 and .NET 2.0 were supported since the beginning.

No, it isn't supported. You can try experimental release 70710aa-exp if you like. I'm about to test it.

The script was updated again to remove the Add/Remove Programs entry for KB928366 but both hotfixes were technically supported by previous versions of SNM.

You are the first to report there's a problem with it. Can you post more details in the other thread?

It's supported now but I'm not 100% satisfied with how it's done. Though I doubt there's a better way. Read here.

@CyberWarrior: You're welcome It's supported now, but it's kinda ugly. This is a hotfix for Windows Presentation Foundation but there's no way of knowing that up front since it's not reflected in the file name. Silent .NET Maker is currently silently attempting to apply any NetFX30-KB*.exe hotfix to both the .NET 3.0 wrapper and the Windows Presentation Foundation packages... and that's the ugly bit.Also, the script is now making an administrative install for Windows Presentation Foundation. This is necessary so the hotfix(es) can be slipstreamed into it. The downside is that the resulting DNF30.exe package will be larger and may fail to be created on some systems if the compression ratio isn't lowered.

That's normal. Existing identifiers are not removed. CDROMSP3.TST is not wrong; it was created when SP3 was slipstreamed into the source.If CDROMSP4.TST doesn't exist after letting HFSLIP handle the Service Pack, the Service Pack was not slipstreamed. You can also check this by looking for SP4.CAT inside SOURCE\I386. Are you actually letting HFSLIP continue after you get the warning message? Slipstreaming occurs after the warning message. There is still another possibility: you don't have SOURCE\I386\PRODSPEC.INI or it contains wrong information. This file is used by HFSLIP to determine the OS version.

Du hast gesagt die Datei heisst W2K-SP.exe. W2KSP4_DE.EXE ist gut. Wenn die Originalinstallationsverzeichnis (SOURCE) schon SP4 enthält, dann ist W2KSP4_DE.EXE nicht mehr in HF benötigt. Eigentlich darfst du W2KSP4_DE.EXE ruhig lassen weil HFSLIP erst nachguckt ob SP4 noch nicht angewendet war. Das versteh ich nicht. Erst sagst du "CDROMSP4.TST" war hinzugefügt nachdem du SP4 manuell integriert hast, und dann sagst du diese Datei war nicht hinzugefügt. Also gibt's "CDROMSP4.TST" oder nicht? Du hast die Wahl. Solange es "cdrom_nt.5" in das SOURCE-Verzeichnis gibt sollen sich keine Probleme vortun während der Installation (nachher).

It is considered unclean by HFSLIP 1.5.0 and basically it is; an original source doesn't have this. Remove SOURCE\I386\SVCPACK.

Die deutsche Originalversion kannst du hier bekommen.

It's most likely caused by mp09setup.exe. Is that the original from Microsoft? HFSLIP expects wmburn.exe inside it, otherwise PidGen.dll won't be renamed, consequently overwriting PIDGEN.DLL in your new source.

The updated Roots Update installer is for WinXP -- not for Win2K.

By the way... The name is HFSLIP (HotFix SLIPstreamer)... That is the problem. As I said, its name should start with "w2ksp4".

That is not a good idea. You'll get IE6 hotfixes as well as obsolete updates like that.

This might imply that the delayed file renames are not taking place. Can you ZIP HFSLIP.CMD from SOURCESS\I386\SVCPACK and SVCPACK.INF from SOURCESS\I386?

The main source of the problem is most surely this: IE7-KB929969-WindowsXP-x86-enu.exe WindowsXP-KB929969-x86-ENU.exe I've checked your entire list and it seems to me you haven't taken care of it much. If any obsolete hotfixes required workarounds they may fail now as workarounds are gradually removed from HFSLIP. Superseded: WindowsXP-KB885835-x86-ENU.exe WindowsXP-KB890046-x86-ENU.exe WindowsXP-KB894391-x86-ENU.exe WindowsXP-KB896424-x86-ENU.exe WindowsXP-KB900930-x86-ENU.exe WindowsXP-KB911567-x86-ENU.exe WindowsXP-KB912919-x86-ENU.exe WindowsXP-KB920214-x86-ENU.exe WindowsXP-KB921398-x86-ENU.exe WindowsXP-KB922616-x86-ENU.exe WindowsXP-KB928388-x86-ENU.exe I would also add security update WindowsXP-KB918439-x86-ENU.exe (as warned by HFNETCHK).

HFSLIP 1.5.0 only warns about an unclean source if it was patched with HFSLIP or with nLite before. HFSLIP can't work with such a source. The fact that cdromsp4.tst is not in your SOURCE folder after running HFSLIP can only mean that the SP4 installer wasn't found. Make sure it has the original name (w2ksp4*.exe) and that it is located in the correct folder (HF).