[Tomcat76]

Remove 5er_WMPLyricsPlugin_Addon.7z (asks to put "WMPLyric.dl_" in TXTSETUP.SIF and DOSNET.INF instead of "WMPLyric.dll").

There is something wrong with the Foxit addon you're using. Get this one instead.

[Kiki Burgh]

hi TC! both addons actually worked in previous test rels ... have used the pdf reader already ... prior to this run, both actually were installed with no problem ... could there be other culprits?

[Sgt_Strider]

Tomcat76, on Mar 6 2007, 02:51 AM, said:

Sgt_Strider, on Mar 6 2007, 05:43 AM, said:

If what you say is true, then how come in th add/remove screen, there is a HF program installed? So HFSLIP does not resort to any hacking method to integrate/slipstream the hotfixes?

If you are referring to the HFSLIP entry... You could consider it a confirmation that HFSLIP was used to update your CD. If you used a recent version of HFSLIP, you can easily remove it by clicking the Change/Remove button.

Sgt_Strider, on Mar 6 2007, 05:50 AM, said:

Also is modifyPE.exe mandatory now? With previous versions, I didn't have to add that program, but now I do or I'll get an error.

ModifyPE.exe is mandatory in some situations:
- when integrating IE7 (not slipstreaming) [this is actually not the case for Windows XP in the current final; I should rectify that]
- when slipstreaming Office Update engine (OPUC4.CAB)
- when one or more of these HFEXPERT folders are used: CODECS, APPREPLACEMENT and WIN

Thanks to you and Kiki for the reply. Is it possible that you can add this as a feature into the next version to stop that entry from being added into the add/remove program?

Tom, I know you said that it won't be practical for you to add SATA/RAID driver support, but is there any possibility that you can reconsider? Like add support for only the most popular models or at least the Intel SATA driver?

[S3pHiroTh]

Sgt_Strider, on Mar 8 2007, 05:30 AM, said:

Thanks to you and Kiki for the reply. Is it possible that you can add this as a feature into the next version to stop that entry from being added into the add/remove program?

Simply create a reg file and add this into it:

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\HFSLIPTotalSlipstream]

Run this reg file at T-13, at first boot or after, it's the same.

[Tomcat76]

Kiki Burgh, on Mar 7 2007, 11:29 PM, said:

hi TC! both addons actually worked in previous test rels ... have used the pdf reader already ... prior to this run, both actually were installed with no problem ... could there be other culprits?

I don't see any other just by looking at your files. The only thing I can suggest at this point is that you do a test run without addons, and only the hotfixes that are on my dynamic list.

Sgt_Strider, on Mar 8 2007, 05:30 AM, said:

Is it possible that you can add this as a feature into the next version to stop that entry from being added into the add/remove program?

The entry in Add/Remove Programs is one way to verify if things went OK. Not creating that entry removes that check.

[Sgt_Strider]

S3pHiroTh, on Mar 8 2007, 12:08 AM, said:

Sgt_Strider, on Mar 8 2007, 05:30 AM, said:

Thanks to you and Kiki for the reply. Is it possible that you can add this as a feature into the next version to stop that entry from being added into the add/remove program?

Simply create a reg file and add this into it:

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\HFSLIPTotalSlipstream]

Run this reg file at T-13, at first boot or after, it's the same.

Do I put that file in HFGUIRUNONCE?

[Tomcat76]

HFGUIRUNONCE or HFSVCPACK. Doesn't matter...

[Sgt_Strider]

Tomcat76, on Mar 11 2007, 01:33 AM, said:

HFGUIRUNONCE or HFSVCPACK. Doesn't matter...

I placed my registry tweak file in HFGUIRUNONCE and the settings doesn't appear to have applied. Maybe it's the way the entries are entered cause even if I include it with my main registry tweak file in HFSVCPACK, it still doesn't apply.

[Tomcat76]

Removing "HFSLIPTotalSlipstream" didn't work or did other registry tweaks fail as well?

[Gedrean]

Hey, question here. I've used HFSLIP to make my 2KPro source put together and it seems to have done so quite nicely.

I have set it up for multiboot, and in fact it seems to be going swimmingly, but I set a number of apps into the HFSVCPACK folder, and I want to find out if I can locate those files in another directory and have both this source and another source install those apps without having two copies. This is the same sort of thing I intend to be doing later with BTS Driverpacks, but I've figured that out already I think... How can I do this with the files of HFSVCPACK?

[Tomcat76]

Well... That could be difficult.
You can achieve that by setting the same multiboot path twice but you need to make sure that files with identical names really are identical too. Also, when the second SOURCESS folder is made, you should move some files from the second SVCPACK folder into the first (or the other way around, depending on which way you want to go), but not all. The easiest way to find out which files should REMAIN in the folder they are in is checking SVCPACK.INF; the CATs as well as all files that are installed from the [SetupHotfixesToRun] section should remain in the folder they exist in.

[Gedrean]

Tomcat76, on Mar 16 2007, 02:58 PM, said:

Well... That could be difficult.
You can achieve that by setting the same multiboot path twice but you need to make sure that files with identical names really are identical too. Also, when the second SOURCESS folder is made, you should move some files from the second SVCPACK folder into the first (or the other way around, depending on which way you want to go), but not all. The easiest way to find out which files should REMAIN in the folder they are in is checking SVCPACK.INF; the CATs as well as all files that are installed from the [SetupHotfixesToRun] section should remain in the folder they exist in.

Really? There's no way to just go into svcpack.inf and rename the ones I put into hfsvcpack to have them in like a directory in the root of the disc?

EDIT: I found hfslip.cmd, could I just modify that to add a variable to point at the folder in the root, like the OEM folder that the driver pack'll be in?

This post has been edited by Gedrean: 16 March 2007 - 01:48 PM

[Sgt_Strider]

Tomcat76, on Mar 16 2007, 04:00 AM, said:

Removing "HFSLIPTotalSlipstream" didn't work or did other registry tweaks fail as well?

I'm talking about the registry tweaks. Only the DPI and screensaver tweak did not work. Do you know why?

[Tomcat76]

Gedrean, on Mar 16 2007, 08:43 PM, said:

There's no way to just go into svcpack.inf and rename the ones I put into hfsvcpack to have them in like a directory in the root of the disc?

To my knowledge, you can't use paths in SVCPACK.INF. I have never experimented with that.

Gedrean, on Mar 16 2007, 08:43 PM, said:

EDIT: I found hfslip.cmd, could I just modify that to add a variable to point at the folder in the root, like the OEM folder that the driver pack'll be in?

That would actually be cleaner. Change the %HFSLIP% variable so it points to your custom directory and then move all files that are installed from %HFSLIP% by HFSLIP.CMD into that folder. But it's more manual work.

Sgt_Strider, on Mar 17 2007, 04:56 AM, said:

I'm talking about the registry tweaks. Only the DPI and screensaver tweak did not work. Do you know why?

I have never used those so I can't really say what's causing the failure. Here are some possibilities:

1) You need a reboot for the changes to take effect

2) There's a mini post-install (titled "Windows Update") taking place when you first log on after Windows setup has completed. Some of the things you inject into the registry may be overwritten by that.

[Gedrean]

Tomcat76, on Mar 17 2007, 08:31 AM, said:

Gedrean, on Mar 16 2007, 08:43 PM, said:

There's no way to just go into svcpack.inf and rename the ones I put into hfsvcpack to have them in like a directory in the root of the disc?

To my knowledge, you can't use paths in SVCPACK.INF. I have never experimented with that.

Gedrean, on Mar 16 2007, 08:43 PM, said:

EDIT: I found hfslip.cmd, could I just modify that to add a variable to point at the folder in the root, like the OEM folder that the driver pack'll be in?

That would actually be cleaner. Change the %HFSLIP% variable so it points to your custom directory and then move all files that are installed from %HFSLIP% by HFSLIP.CMD into that folder. But it's more manual work.

Yeah it is very lovely that it seems HFS places its calls into a cmd rather than in svcpack (in fact none of my SSI's were in svcpack) so that they can be manipulated easier. It's a little manual work, but at this rate what I've done is added a slightly different variable (HFSLIP2) and just stuck a 2 into the names of the files that weren't moved (very few of them) and did some swapping around. It'll make creating a multiboot CD much easier. Thanks Tomcat76!

[Sgt_Strider]

Tomcat76, on Mar 17 2007, 05:31 AM, said:

Gedrean, on Mar 16 2007, 08:43 PM, said:

There's no way to just go into svcpack.inf and rename the ones I put into hfsvcpack to have them in like a directory in the root of the disc?

To my knowledge, you can't use paths in SVCPACK.INF. I have never experimented with that.

Gedrean, on Mar 16 2007, 08:43 PM, said:

EDIT: I found hfslip.cmd, could I just modify that to add a variable to point at the folder in the root, like the OEM folder that the driver pack'll be in?

That would actually be cleaner. Change the %HFSLIP% variable so it points to your custom directory and then move all files that are installed from %HFSLIP% by HFSLIP.CMD into that folder. But it's more manual work.

Sgt_Strider, on Mar 17 2007, 04:56 AM, said:

I'm talking about the registry tweaks. Only the DPI and screensaver tweak did not work. Do you know why?

I have never used those so I can't really say what's causing the failure. Here are some possibilities:

1) You need a reboot for the changes to take effect

2) There's a mini post-install (titled "Windows Update") taking place when you first log on after Windows setup has completed. Some of the things you inject into the registry may be overwritten by that.

How do I ensure that doesn't happen? Restarting the computer will not do anything.

[jimmsta]

Building with a clean XP SP2 source, with all the latest patches in the HF directory, and IE7's installer in there as well, I seem to have issues - first off, Wininet.dll is not functioning properly - I have to install IE7 on top of itself in order to use IE at all. Secondly, the themes service is not starting, and third, if I integrate WGA, or Windows Update, all the controls are screwed up, unregistered, and will not register properly.

I've tried over and over again, but still run into these problems.
I've tried different sources of XP, with the same results.

I also sometimes end up with a bunch of desktop.ini files in the start menu, desktop, and startup menu.

I'll be testing the latest test release, to see if any of these wacky bugs could have been caused by something in the script. There's also a chance that I have some update that should not be included, or may have been superceeded.

Any Ideas?

[the_guy]

Post your hfslip.log file (located in the root of your CD).

the_guy

[Super-Magician]

@jimmsta, have you tried restarting after IE7 installation is completed? Try reading through http://www.hfslip.org, and as the_guy said, please post your HFSLIP.LOG file.

You see a bunch of desktop.ini files because for some reason a setting in Folder Options is unchecked (Folder Options -> View -> Hide protected operating system files).

[Tomcat76]

@jimmsta
To me, that sounds like the issues that existed with the betas, RCs and the first final release (and maybe even the second) of IE7. Be sure to use the latest final release; Microsoft have silently re-released it a few times. Also, I hope you read the instructions on hfslip.org; you need at least the latest cumulative update and the latest shell32.dll hotfix.

Sgt_Strider, on Mar 18 2007, 07:01 AM, said:

How do I ensure that doesn't happen? Restarting the computer will not do anything.

If rebooting didn't do it, it may be the other problem. Unfortunately I think there's no way around that (at least not a clean one).