@Mim0

Thanks for the update.

Are you planning to make these changes suggested here ?

Edited June 24, 201214 yr by dziubek

Are you planning to make these changes suggested here ?

not really. should I?

I'd like to suggest changing this line in HFSLIP's script:

SET SW1=/quiet /norestart

to

SET SW1=/q /n /z

...

Yes I think it could be a good idea to use your switches. But I suggest to define (overwrite) them in the HFANSWER.INI. What do you think?

I do not know;) I suspect that the use of these switches will result in more compatibility with other installers...

/q /n /z

is exactly the same as

/quiet /norestart /nobackup

It's just the "/nobackup" option that is being added

Edited June 24, 201214 yr by tomasz86

Hi!

Regarding this:

Thx to CEoCEo for the hint regarding HFSLIP and CWDIllegalInDllSearch

The new CWDIllegalInDllSearch will give a warning when found a problematic value of CWDIllegalInDllSearch in the registry. Also I added a hint in the update-list (table 6) to HFSLIP regarding this registry-value.

Mim0! May i suggest you to change WindowsXP-KB2264107-x86.reg to this? :

---------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]

"CWDIllegalInDllSearch"=dword:00000002

---------

I have three reasons for this!

1) M$ Groove 2007 (its installed with Office 2007 typical-install) gets mad with "CWDIllegalInDllSearch"=dword:FFFFFFFF

Every time i start IE8, it starts with "Error loading C:\Program Files\Microsoft Office\Office 12\GrooveUtil.DLL"!

But when "CWDIllegalInDllSearch"=dword:00000002, there is no problem!

2) TYPE1 hotfixes can not extract itself when "CWDIllegalInDllSearch"=dword:FFFFFFFF, error message is "file is corrupt", and HFSLIP can not slipstream MANY hotfixes this way! (as CEoCEo said also)

(this whole problem took me many-many hours to discover, that "CWDIllegalInDllSearch"=dword:FFFFFFFF is the reason HFSLIP can't slipstream!!! -Yes, i've read JUST NOW the hint on your page regarding this)

But again, when "CWDIllegalInDllSearch"=dword:00000002, there is no problem!

3) "CWDIllegalInDllSearch"=dword:00000002 is enough protection for hijacking DLLs with remote locations!

If hijacking with local files, its too late anyways...

Regards,

Fenyo

...

Mim0! May i suggest you to change WindowsXP-KB2264107-x86.reg to this? :

...

"CWDIllegalInDllSearch"=dword:00000002

....

Thx for this statement. I also thought often sometmes about this. On one hand, everyone can modify this or can leave this file, but on the other hand, 2 is really enough.

Other opinions?

Edited June 25, 201214 yr by Mim0

On one hand, everyone can modify this or can leave this file,

Yeah, but i think most of the people just download the files and run HFSLIP, especially if they're just updating.

And next time they wonder why HFSLIP does not slipstream updates...

Just as i did.

You could save many research-hours for people by setting the file on your page to dword:00000002.

On one hand, everyone can modify this or can leave this file,

Yeah, but i think most of the people just download the files and run HFSLIP, especially if they're just updating.

And next time they wonder why HFSLIP does not slipstream updates...

Just as i did.

You could save many research-hours for people by setting the file on your page to dword:00000002.

hi,

my WINDOWSXP-KB2264107-X86.REG file is in SVCPACK folder. if I just edit this file and make iso, is it OK? I just don't understand what the slipstream process with this update? Should I run hfslip again to slipstream updates?

hi,

my WINDOWSXP-KB2264107-X86.REG file is in SVCPACK folder. if I just edit this file and make iso, is it OK? I just don't understand what the slipstream process with this update? Should I run hfslip again to slipstream updates?

Yes, it's OK! You don't have to re-run HFSLIP just for this.

But don't forget to edit this file in HFSVCPACK folder also, if you don't want to edit it again after every run of HFSLIP.

hi,

my WINDOWSXP-KB2264107-X86.REG file is in SVCPACK folder. if I just edit this file and make iso, is it OK? I just don't understand what the slipstream process with this update? Should I run hfslip again to slipstream updates?

Yes, it's OK! You don't have to re-run HFSLIP just for this.

But don't forget to edit this file in HFSVCPACK folder also, if you don't want to edit it again after every run of HFSLIP.

I understand, thanks for your information.

I've found the culprit.

...

IF EXIST SOURCE\I386\SVCPACK\setupusp.exe ECHO>>WORK\SVCMAIN.TXT SETUPUSP.EXE /q /n /z

...

Are there other SP's in use that do have "spsetup.exe"? If so, maybe having both lines, rather than editing the line, would be a better solution? That way all the bases would be covered yet not cause you any problems with SP5.2. Or was it just a typo that is just now coming to light?

...

I have added the line from tomasz86. But I didn't removed the old line for compatibility to whatever

In the change log of HFSLIP I found this:

...

DEC 27, 2007 ~ FEB 23, 2008 -

...

Hardcoded handling of SVCPACK\spsetup.exe from USP5.

...

So I don't think that this was a typo from tommy. I didn't found anything regarding this entry of the changelog here in this forum. But after a quick search I found this:

...

2008/02/24

...

Complete changelog for HFSLIP 1.7.4

...

[uSP5] when choosing merging options A, B or C, HFSLIP now correctly updates DRIVER.CAB; if USP5 was slipstreamed beforehand, make sure cdromsp5.tst is present in the root of the SOURCE folder

[uSP5] handling of SVCPACK\spsetup.exe is now hardcoded; this fixes a problem when USP5 was slipstreamed beforehand (which in turn caused an error message about a missing SVCPACK.INF file to appear)

[uSP5] HFSLIP now also displays the option to remove CAT files when USP5 was slipstreamed beforehand

[uSP5] changed the way a source updated with USP5 is represented in HFSLIP.LOG

...

upload follows asap!

Edited July 3, 201214 yr by Mim0

Thanks, Mim0.

By the way, this option to remove catalog files when USP 5.1 is slipstreamed is very wrong. USP 5.1 neither disables nor breaks SFC. It's only during the installation that a hacked syssetup.dll is being used but after that it's replaced with the original one. At the end there are no hacked files in the system after the installation is finished which means that (unless you do disable SFC) there is no reason to delete the CAT files!

Edited July 3, 201214 yr by tomasz86

Update for Windows XP and Windows Server 2003 (KB2728973)

new type of roots cert (revoke) installer rvkroots.exe

more information in this thread

Edited July 10, 201214 yr by dziubek

July,10 2012 WinXPSp3 Update List;

KB2719985 msxml3.dll (8.100.1053.0 - 2012/06/05) Msxml6.dll (6.20.2501.0 - 2012/05/06)

replace

2079403 msxml3.dll (8.100.1052.0 - 14.06.2010)

954459 Msxml6.dll (6.20.1099.0 - 10.09.2008)

973687 msxml3.dll (8.100.1051.0 - 31/07/2009) Msxml6.dll (6.20.1103.0 - 31/07/2009)

KB2721691 msxml4.dll (4.30.2114.0 - 2012/06/25) Msxml4r.dll (4.30.2100.0 - 2012/06/25)

replace

KB973685 msxml4.dll (4.30.2107.0 - 20.07.2009) Msxml4r.dll (4.30.2100.0 - 20.07.2009)

KB2718523 Win32k.sys (5.1.2600.6244 - 13/06/2012)

replace

2709162 Win32k.sys (5.1.2600.6228 - 2012/05/15)

KB2655992 schannel.dll (5.1.2600.6239 - 2012/06/04)

KB2691442 shell32.dll (6.0.2900.6242 - 2012/08/06)

KB2698365 msado15.dll (2.81.3014.0 - 2012/05/28)

And

http://download.microsoft.com/download/4/A/A/4AA524C6-239D-47FF-860B-5B397199CBF8/Windows-KB890830-V4.10.exe

Edited July 12, 201214 yr by rulman

Thank you rulman. There's also a new IE Cumulative Update though, and the one for MDAC installs many more files from QFE.