HFSLIP 2.0 in the works

[Tomcat76]

Here's a pre-alpha release of HFSLIP 2.0. Use at your own risk.

Suggestion: run it in a blank folder so the subfolders are created, read the changelog, populate the folders as necessary and run it again.

If you used a pre-alpha of HFSLIP 2.0 older than 80507a on Windows Server 2003 and you had it slipstream the DX9 extras, please check in the custom "DX9plus" cab package in the HF folder that there are no microsoft*.dll files in it. If there are, delete the cab package.

Main package:

hfslip-2.0.0pa_80630a.zip

Extras for HFCABS (download directly into HFCABS):

wbemoc.cab (required fix for problem with XPSP3; please remove previous HFSLIP32_POST_WBEMOC fix from HFTOOLS)

ieaccess.cab (a clean version of an updated ieaccess.inf for IE7 and IE8; to be used with HFSLIP 2.0 80515b or higher)

Plugins for HFTOOLS (extract into HFTOOLS):

HFSLIP32_PRE_WSearch40_v1.zip (Windows Search 4.0 plugin for HFSLIP 2.0 80608a or newer; put exe for XP or Srv2K3 in HF)

HFSLIP32_PRE_SWFlash9_v1.zip (SWFlash 9.0.124.0 plugin for HFSLIP 2.0)

HFSLIP32_PRE_TZ4_v2.zip (time zone plugin without tzchange.exe for HFSLIP 2.0)

HFSLIP32_PRE_TZ4_tzchange_v2.zip (time zone plugin with tzchange.exe for HFSLIP 2.0; XPSP2, XPSP3 & 2K3SP2)

Known issues:

- on Windows 2000, the DX9 redist is extracted every time; this is because HFSLIP doesn't yet create a custom cab package for the DX9 core for that OS

- HFCLEANUP is broken (this folder is not blocked, so rename it if you're using it for reducer files)

- Windows XP MCE 2005 is broken

- MPlayer.exe (WMP9), wmfdist.exe, wmfdist95.exe and KB891122 are not processed

- old HFSLIP_PRE* and HFSLIP_POST* plugins don't work; they need to be upgraded to support the new HFSLIP code

- *.EXT files are ignored; they will be replaced by plugins

IEACCESS.INF with IE7 and IE8:

To avoid potential issues, HFSLIP 2.0 will now always write an updated ieaccess.inf file in ANSI. In addition to this, for languages where a certain string in this file contains special characters, that string is rewritten in English so you will at least get a readable text.

ieaccess.inf is the installation file that Windows calls when you want to add or remove access to Internet Explorer when in the Add/Remove Windows Components dialog. The string that may contain special characters in certain languages concerns the tip you see when you highlight "Internet Explorer" in that dialog, so it's not really an issue. But if you prefer to have it clean, please use the ieaccess.cab package; if present in the HFCABS folder, HFSLIP 2.0 will use it instead of modifying ieaccess.inf by itself.

New "DX9CORE=FULL" setting in HFANSWER.INI:

On Server 2003, this tells HFSLIP that you want the DX9 core to be updated; if this variable is not set (or not present), only the DX9 extras are processed.

On Windows XP, this variable has no effect.

On Windows 2000, this has no effect yet.

New "UserFolder=" setting in HFANSWER.INI:

HFSLIP 2.0 places all HFSVCPACK, HFSVCPACK_SW1, HFFIRSTLOGON, HFFIRSTLOGON_SW1 and HFEXPERT\AUTOIT files except HFSVCPACK\*.cmd and HFSVCPACK_SW1\*.exe files into a folder in the root of the new source. By default, this new folder in the root of the new source is named $HFSLIP but you can change that with the UserFolder variable in HFANSWER.INI. For example: UserFolder=MyFiles. Any spaces are stripped out automatically (eg, "My Files" becomes MyFiles).

Changes marked in this color are changes relative to the HFSLIP 2.0 test releases, not HFSLIP 1.x. They will be removed overtime to avoid confusion.

Changes 80630a:

- fixed a problem with the way CMD files in HFSVCPACK are handled

Changes 80620a:

- testing workaround for copy error with napprov.mof (and napschem.mof) in network-based installs

- new source language detection method based on mfc42*.dl_

Changes 80612a:

- cumulative ActiveX KillBits are force-added by HFSLIP so it isn't needed to include the current hotfixes (KB948881 or KB950760); to override this behavior, specify NoKillBits=YES in HFANSWER.INI

- [2K3] GdiDetectionTool registry hack is no longer added (because it isn't needed)

Changes 80611a:

- added support for KB951376 for Windows XP (Windows Update wants to see bthport.sys in system32\drivers but it's not installed by Windows setup by default)

- added support for new XAPOFX binary in June 2008 DirectX9 Redist

- added support for Windows Installer 4.5 for XPSP2, XPSP3 and 2K3SP2 (requires recent 7za.exe in HFTOOLS)

- handling of Windows Installer 4.5 now requires 7za.exe in HFTOOLS no matter what the host OS is to bypass corrupt localized CAT files

Changes 80608a:

- allowed "%ProgramFiles%\Windows Desktop Search" as destination folder at T-28 for plugins

- blocking WindowsSearch*.exe updates so they aren't processed automatically

- names of new binaries slipstreamed by HFSLIP are shown in HFSLIP.LOG (this replaces the old getnewfiles plugin)

Changes 80605a:

- testing solution provided by Acheron to delete the temporary HFSLIP folder used during Windows setup

Changes 80520a:

- every extra file (HFSVCPACK, etc.) is no longer copied to hard disk first, but installed directly from the source (thanks to 7yler)

Changes 80519a:

- the "INSTALLRC" variable is no longer ignored, but its value should now be "YES" if you want the Recovery Console installed at T-13 (INSTALLRC=YES)

Changes 80515a:

- [iE7/IE8] an updated ieaccess.inf is now always written in ANSI instead of in Unicode to avoid potential issues with other programs (see "IEACCESS.INF with IE7 and IE8" above)

Changes 80507a:

- got rid of HFSLPGUI.INF (was used for post-logon installs)

- qmgr.dll from the BITS update needs to be in both the system32 and the system32\BITS folder; instead of duplicating the file, it is now just copied from system32 to system32\BITS at T-13

- [Win2K] added support for sp4supporttools.exe if placed in HF (needed to work around the mess with netdiag.exe)

- [Win2K] mqrperf.dll is not slipstreamed for Professional (eg, KB937894)

- [Win2K] if MDAC 2.8 SP1 is slipstreamed, only MDAC281*.exe updates are handled; otherwise, only MDAC253*.exe updates are handled

- [Win2K] if IE6 is slipstreamed, updates for IE5 and OE5 are blocked; otherwise, updates for IE6 and OE6 are blocked

Changes 80501a:

- HFEXPERT\AUTOIT files are placed in the SOURCESS\<UserFolder> folder like SVCPACK and 1st logon installs

Changes 80430a:

- added support for new XAudio2*.dll binary in March 2008 DirectX9 redist

- custom cab packages are created in the HF folder for the DX9 core and the DX9 extras (if applicable) which will be used instead the next time HFSLIP is run; if a newer redist is included, only the updates are processed and a new cab package is created for the DX9 extras

- introducing "DX9CORE=FULL" setting in HFANSWER.INI (see above for details)

Changes 80428a:

- removed support for XP SP1, 2K3 Gold and 2K3 SP1; an HFSLIP version specifically meant for XP SP1 will be released later

- removed support for Windows Media Player 10

- removed support for IE7 SVCPACK and GUILOGON modes

- removed support for HF\BASIC; put these files in HF

- KB898461 (Package Installer) and KB898543 (WMP11 slipstreaming fix) are only processed if the OS is XP SP2; they must be in the HF folder, not in HF\NOREG

- enhanced slipstreaming of WMP11 into Windows XP

- fixed (and allowed) slipstreaming of IE7 into Windows Server 2003

- introducing slipstreaming of IE8 beta 1 into both Windows XP and Windows Server 2003 (IE8 is slow to start the first time)

- slipstreaming WMP11 for WinXP into Server 2003 is possible, but Microsoft Update will be much slower and won't display any updates that might exist for it; also, updates for WMP11 cannot be manually installed on Server 2003 (you'll have to make a new source and install Windows again each time)

- new binaries collected from updates are slipstreamed faster into the new source

- the HFSLIP folder path can now safely contain spaces; the short path name (8.3 standard) is used wherever necessary

- in AUTORUN mode, it is no longer necessary to seperately set the COMPMEM and MULTICAB variables; just set DRIVERCOMP as usual

- HFGUIRUNONCE folder is now named HFFIRSTLOGON

- introducing new HFFIRSTLOGON_SW1 folder for Type 1 hotfixes and *.MSI files that need to be installed at first GUI logon

- HFSVCPACK_SW2, HFFIRSTLOGON and HFFIRSTLOGON_SW1 folders are not created automatically

- introducing new folder in the root of the SOURCESS folder for most SVCPACK and 1st logon installs

Edited June 30, 2008 by Tomcat76

[tain]

Some neat changes in the 2.0 series, Tomcat76. Thanks for all your hard work!

[Tomalak]

Hello Tomcat76,

First of all: thanks for your continuing support, development and all the effort put into hfslip! It's really appreciated!

Found the time today to test the new hfslip version (2.0.0pa_80508a), together with a Windows XP Professional SP3 (integrating the service pack was done before, not by hfslip). It worked almost perfect, except two minor issues I experienced - and these may not even be related to hfslip at all:

1) After the installation, Windows Update (and the MBSA) complained about a missing patch, KB941569 (MS07-068). I don't understand that because according to Microsoft's own list of fixes included in SP3 (KB946480) this patch should be already in there. Maybe this is a result of integrating WMP11?

2) During the textmode phase of the setup, the copy routine gave a message like "tweakui.exe copied erroneously" (or similar, was a German message for me). I included 'tweakui.exe' in HFEXPERT\WIN\system32, together with a reg file 'tweakui.reg' in HFSVCPACK - this has always worked with hfslip 1.x in combination with SP2. The strange thing is that the file was not skipped - it was present in Windows later on, and I could use it as expected, no problems. Just this strange error at installation time that I simply had to ignore...

Please find the corresponding log file attached. I have no idea where these two issues come from: the new hfslip version, the new SP3, or something completely different... Thanks!

Kind regards,

Tomalak

HFSLIP.zip

[Tomcat76]

1) After the installation, Windows Update (and the MBSA) complained about a missing patch, KB941569 (MS07-068). I don't understand that because according to Microsoft's own list of fixes included in SP3 (KB946480) this patch should be already in there. Maybe this is a result of integrating WMP11?

KB941569 is sort of a cumulative update in that it contains different versions of the same binaries. SP3 obviously doesn't contain the WMP11 versions.

2) During the textmode phase of the setup, the copy routine gave a message like "tweakui.exe copied erroneously" (or similar, was a German message for me). I included 'tweakui.exe' in HFEXPERT\WIN\system32, together with a reg file 'tweakui.reg' in HFSVCPACK - this has always worked with hfslip 1.x in combination with SP2. The strange thing is that the file was not skipped - it was present in Windows later on, and I could use it as expected, no problems. Just this strange error at installation time that I simply had to ignore...

I don't know. It could be that the file isn't 100% compatible with SP3, or that modifype needs to be run on it. Do you have the same problem when updating XPSP3 using HFSLIP 1.7.6rc7?

[Tomalak]

KB941569 is sort of a cumulative update in that it contains different versions of the same binaries. SP3 obviously doesn't contain the WMP11 versions.

Yep, my bad, haven't seen that. I will include it in my next test install.

Any idea when you will find the time to update the patch list on your homepage for SP3 as it is final now? I figured out most of the necessary updates myself (and, well, reading other lists ), but these obviously didn't catch KB941569 yet. WU/MU and MBSA are satisfied now (with all the patches included in the logfile I posted), but I'm not sure whether I still miss something. What about the updates for MSXML2 (KB887606) and MSXML4 (KB941833) - are they still necessary? I could only find references to MSXML3 in the changelog (= list of included patches, KB946480) for SP3...

I don't know. It could be that the file isn't 100% compatible with SP3, or that modifype needs to be run on it. Do you have the same problem when updating XPSP3 using HFSLIP 1.7.6rc7?

Tested all combinations today: hfslip 1.7.6 (rc7) and hfslip 2.0 (pa8), with SP2 and SP3. The error always occurs, it's apparently not connected to SP3 or hfslip at all - I'm pretty sure it was not there during my last installation, but this took place some months ago, perhaps I changed something else in the meantime...

Anyway, as this is only a minor annoyance and not a real problem - as explained everything works after the Windows setup is finished - it's not necessary to analyze this further, as long as no one else experiences the problem, and in a more serious way.

Thanks a lot!

Tomalak

[Acheron]

Will HFSLIP 2.0 still support the feature to install the Recovery Console for Windows XP? I tried this under XP SP2 using HFSLIP 1.7.6 but during setup I get some prompts (connecting to check for updates )

I'll post some screens later. I just post it here since I assume HFSLIP 1.x won't get updated anymore.

Edited May 17, 2008 by Acheron

[Tomcat76]

HFSLIP 2.0 is still a very long way to go, so 1.x is still being updated.

HFSLIP 1.x has the Recovery Console installed from a CMD file at T-13. The method only works for CD-based installs because I never found a way to poll for UNC paths simultaneously. It also requires the user to enter a multiboot path (if applicable) at the beginning of the HFSLIP run. Since I have eliminated all other needs for the multiboot path in HFSLIP 2.0, I decided to drop this feature in HFSLIP 2.0 until a better solution is found -- one which works for network-based installs too. If need be, I'll have it copy all files that are necessary to install the Recovery Console to hard disk (into the temporary %WINDIR%\HFSLIP folder) but then I first need to find out which files are needed.

If you have any issues with how the Recovery Console is being installed with HFSLIP 1.x, please start a new thread.

[7yler]

For the Recovery Console you could try this

@ECHO OFF

:: **** Install Windows Recovery Console

FOR /F "tokens=3" %%I IN ('REG QUERY HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup /v SourcePath') DO SET SourcePath=%%I

"%SourcePath%i386\WINNT32.EXE" /cmdcons /unattend

Then your not dependant on a path.

You need to make sure i386\WINNTUPG exists, and contains the following 4 files:

CFGMGR32.DLL

NETMAP.INF

NETUPGRD.DLL

SETUPAPI.DLL

It should work at T-13 but havn't tested.

[Tomcat76]

I'll be dxxxxx...

Do you happen to know whether "SourcePath" really is the PATH to the installation source, or that it's just the drive letter in every circumstance?

I'm asking this because in the case of a multiboot CD with D:\PRO\i386 and D:\ADV\i386 the path to the source would strictly speaking be "D:\PRO" or "D:\ADV" and not "D:\".

[7yler]

Corrent, "SourcePath" is the full path to installation source.

I've been using Mutliboot and it does point to the folder not the root. So for D:\PRO\i386 or D:\ADV\i386, "SourcePath" would be D:\PRO or D:\ADV.

At work we use Network installs and "SourcePath" points to the UNC Path.

Here's another Script I use if i what to copy SourceFile to the local drive.

@ECHO OFF

:: **** Copy, Compress and Set Install Files to %WinDir%

FOR /F "tokens=3" %%I IN ('REG QUERY HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup /v SourcePath') DO SET SourcePath=%%I

MD                                            "%WinDir%\i386"
COMPACT /C /F /I /Q                          "%WinDir%\i386"
XCOPY   /V /E /I /Q /H /Y "%SourcePath%i386" "%WinDir%\i386"

REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup" /F /T REG_SZ /V SourcePath            /D %WinDir%\
REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup" /F /T REG_SZ /V ServicePackSourcePath /D %WinDir%\

[Tomcat76]

Thanks for this. It's a really valuable tip, so you got yourself a spot in the hall of fame...

Every additional file is now installed directly from the source, except when it's determined at T-13 that there are spaces in the path to the source, in which case silent executables from HFSVCPACK and HFFIRSTLOGON are first copied to the hard disk and installed from there. This is because of a limitation with the START command; it appears it can't handle quotes if they follow it immediately.

[7yler]

Thanks for this. It's a really valuable tip, so you got yourself a spot in the hall of fame...

Glad to be able to help in some small way.

I've gained a lot from looking at the HFSLIP scripts, with alot more still to learn. So very happy that i can contribute something.

This is because of a limitation with the START command; it appears it can't handle quotes if they follow it immediately.

I've had problems with START in the past were the following happerns:

START /WAIT "%~dp0SETUP.EXE" <-- does not work correctly

START "Install" /WAIT "%~dp0SETUP.EXE" <-- Works fine

Is it possible that START "%~dp0SETUP.EXE" is seeing "%~dp0SETUP.EXE" as the "title"

Therefore START "HFSLIP" "%~dp0SETUP.EXE" may work ...

Keep up the great work.

[Tomcat76]

Heh... And start /? would've given me the same answer. That'll teach me...

Standalone executables are now installed like this: START/WAIT "" "%SRCPATH%<Userfolder>\filename.exe"

Seems to work just fine. Thanks again...

[Martin H]

Just wanted to say thank you so much TC, for incorporating that 'install directly from source' feature

It's very much appreciated, mate

CU, Martin.

[Tomcat76]

You should really thank 7yler for this...