I'm not using Windows 2000 but Windows XP. I've attached the log of hfslip.

P.s. The log doesn't show what files are in HFGUIRUNONCE. Maybe is better to implement that it show them.

Do you have iexpress.exe in your Windows's SYSTEM32 folder?

This is mentioned in the changelog.

Editing HFSLIP.CMD isn't necessary if you enter the path when prompted. But this is only required if anything is going to be installed by HFSLIP.CMD.

@S3pHiroTh...

Ok

@Tomcat76...

Tomcat - Check and double-check. I do have iexpress.exe in my system32 directory.

Has anybody successfully ran the test release to install IE7?

@Super-Magician...
LOL... I saw that... Don't worry...

@kenlau...
Well yeah... Me...

I'm about to run it now. Will check and see...

If I were you I'd wait until it's released...

Actually, I meant to run the test release for kenlau to see if the IE7 part works. I guess I can wait a little longer for the new one. Thanks.

Edit: ...which I guess has just arrived in the last second.

Out.

Thanks for that and 70203b as well.

I think there's a bug. I tested 70203a in a VM. The first time I ran it my power got interrupted while it was installing, so that may be a factor. However, it occurred during GUI-mode setup, not txtmode copy. After I restarted setup, I got a bunch of error boxes saying the HFSLPxxx.INF files were missing from C:\WINDOWS\HFSLIP.

I then reverted back to a snapshot of a clean VM. Right before T-13, I got another Advanced INF Install message, but this time HFSLPGUI.INF was missing.

A bit problematic, don't you think? I didn't change a single thing in my folder structure from my last successful run except to introduce rootsupd.exe and the Feb 2007 update for DirectX, readd IE7, and update KB905474. I can still post my HFSLIP.LOG file if you want, but I don't think it will help much.

I guess 70203b os not 100% ready yet, because the download link is not working.

I got hfslip-70202b to work now.. , although I install with the network disable.

http://users.telenet.be/tc76/hfslip/test/hfslip-70203a.zip

Simply replace the latest character "b" with an "a".

Sorry, guys. I forgot to upload it. It should be there now...

Could you change hfslip files adding in HFSLPGUI.CMD to alphabetical order ( like it in SVCPACK.INF is ), but not in type order like it's now?:



I would like to make it this way:

@TC

Hmm... I was wondering while there was differences in style between hfcleanup and the other parts of the script.

Anyway, this exaple simply demonstrates how the script in hfcleanup takes at least the dots in every search string as wildcard characters, and that it does possibly filter out more lines than it should.

The following change is suggested here, and the similiar places:



I would even suggest changes troughout the script, to clarify up these things:
- if wildcard searches are needed, use RegEx with /R switch
- else use /L or /C: switches to make sure no wildcard searches occur.

If anyone in doubt here is what I'm talking about:
ECHO Filtering TXTSETUP.SIF ... this might take a few seconds

Everyone who have ever run hfcleanup knows this line well. And it's true it really takes 10-20 second to process txtsetup. It's because it takes lot more processing power to make a wildcard search than a literal! After applying the /L switch hfcleanup filters txtsetup.sif like a flash. So I suggest removing that comment too

EDIT: I haven't tested the differences in results... it depends on the exact searching pattern, and the strings searched for, but at least the possibility is there to be determining

Nice find dude. I think this may help some of those pesty files that accidentally get erased once in a while! Only the txtsetup, dosnet and the drvindex files should be processed like this. The other hfcleanup type files should continue using the existing filtering method (i.e. without the /L switch). It will need to get tested first though. Ouch!

@dziubek

It's possible but it might slow down the HFSLIP process. I'll think about it.

At this point I'm more interested in comments on the "alternate input folders" feature. At the current rate of interest it won't make it into the final...

@TP

Hohoho Some test would be appropriate to see how many things were filtered by it. In the gfinder.zip I added some strings manually but mostly arbitary to see how big the difference can be, but I'm just curious what are the results in the "real life".

I had an issue when I run hfcleanup, that hfslipwu.inf doesn't processed during install, so none of the runonce entries where added, so WINDOWS\HFSLIP folder had all the infs unprocessed and undeleted. This for example has not occured last time with /L, but i did not run all the removers (ZZZZs mostly. Then I tried another with all, but that install stopped. maybe because ZZZ_Englishonly, which I accidentally left in, despite the fact in WINNT.SIF I enabled Hungarian)

@TC



It obfuscates the code too much, makes it f* hard to maintain or read, take that in account too.

If that were the case that would be my problem but I think it's not the case so it's not a problem

Bug report with hfslip-70203b. In hfslip.cmd in svcpack, there is bad commandline
START/WAIT rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 ....

Version hfslip-1.2.2 does not have this problem. The correct commandline is:
rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 ....

@tommyp, could that have something to do with the bug I reported on page 71, which seems to have gone unnoticed?

I don't think those are the same INF files. The INF files I was talking about are the ones in the svcpack folder. These are launched via hfslip.cmd, also in svcpack. All of my hfslip###.inf files are working correctly. Open your hfslipwu.inf and see if something looks like this:


all of that was supposed to be one line

The [ROROE] section is fine. Everything is as it's supposed to be there.

@TommyP

I did that intentionally because I noticed that the CMD file that runs at first GUI logon (HFSLPGUI.CMD) would quit too soon if I didn't use START/WAIT for every line. I assumed that the same problem might occur with HFSLIP.CMD at T-13. Does this break installation of INF files?

Another thing...

The syntax
rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 filename.inf
seems to produce an error message at first GUI logon. I'm forced to do it like this:
rundll32.exe advpack.dll,LaunchINFSection filename.inf,DefaultInstall
Shouldn't it be done like this in HFSLIP.CMD as well?

TC - The hfslip.cmd inf processing doesn't work in the test release, but it works fine in the latest final. In the beta, the INF doesn't process, the only thing I get is an error window (and an INF that doesn't process).

I never really understood why sometimes it's setupapi and sometimes advpack. But, if it ain't broke.....

In my second test using 70203b, I've just encountered the same problem denoted above.

Click to view attachment

Is it the same problem? I don't think TommyP uses HFSLPGUI.INF.

BTW... You are the second person for whom the GUI stuff runs at T-13. I don't get it... This NEVER happened to me.

I'm aware of some problems and they'll be fixed.

I'll see if 70202b creates the same problem.

Hope the new version is better...

Same exact error message with 70205a.

Sorry, I can't test out the fix. I'm out of town for a week.

@Super-Magician
1) Do you have any files in HFGUIRUNONCE?
2) Is HFSLPGUI.INF present in SOURCESS\I386?
3) Do you see any references to HFSLPGUI.INF in SOURCESS\I386\TXTSETUP.SIF?
4) Is "1200 = HFSLPGUI" defined in SOURCESS\I386\TXTSETUP.SIF?

I just finished a test with a fully updated XPSP2 source including .NET1/2/3, Adobe Reader 8.0, JRE 6.0, four addons (Sidebar, FGCBA Handler, VistaUAP and VAIOXP-b2) and some dummy INF and CMD files... Works as intended...

(1) Yes; a previous version worked with these files.
(2) Yes.
(3) Yes, once.
(4) Yes.

Everything seems to be OK, except for that one error. When I take a look inside C:\WINDOWS\HFSLPGUI, I discover that there's only four files (see my HFSLIP.LOG file below), none of which are HFSLPGUI.INF.

Click to view attachment
P.S. The driver files should not affect it in anyway because I have not changed them since my last successful run a few days ago.

You should be seeing four files, but it should be these:
HFGUI1.EXE
HFGUI2.EXE
HFSLPGUI.CMD
HFSLPGUI.INF

Perhaps if I understood their intended purpose...

Hi Tomcat I've a question for you, you have written this:



This means that, if I use Windows XP SP2, I should remove the old variable INCWMPCSKIN and replace it with the new INCALLSKINS?
Or INCALLSKINS has an highest priority than INCWMPCSKIN?

It has a higher priority: if you set both to "1" then only INCALLSKINS will be taken into account since there's no need to copy the Classic skin twice.

Just note that all HFSLIP does is copy them over into the skins folder. Whether or not they are compatible with WMP 9, 10 or 11 is something else.

This feature is mainly for people who don't have a lot of disk space but wish to create different outputs. Instead of creating --say-- five HFSLIP working folders each containing a copy of the CD source, you can now have five working folders with only one containing the CD source. The FDVFILES, HF, HFCABS, HFCLEANUP and HFTOOLS folders are also cumulative (they only exist in the "main" working folder alongside the source). FIX, HFEXPERT, HFSVCPACK, HFSVCPACK_SW and HFGUIRUNONCE can exist in both the main working dir as well as in any alternate working folder you create.

Bad timing means I will not have time to test this until next week, but that said I like the concept and it would be of great use. I am currently maintaining 7 different builds buy making copies of all the HF supporting folders and copying them into a HF main folder to make the build, basically a manual process of similar to what you are attempting to automate. In a nutshell, good idea I like it.

@Tomcat76

I still have no idea what's going on with my installation. I get four files in HFSLPGUI, but they aren't the ones you say should be there. This is what I see.

HFGUI1.EXE
HFGUI2.EXE
IE7_INST.EXE
PSHELL.EXE

Something is not right. I just ran 70202b again, which worked before. Now I get the same error.

What's wrong?

Super-Magician...

You can test something for me but I'd first like to see the TXTSETUP.SIF and DOSNET.INF files from SOURCESS\I386. I need to make sure everything's alright there.

Sure, no problem.

Click to view attachment

OK... I see the problem. Good idea to ask you for the TXTSETUP.SIF file...

70207a, at your service... Sir!

Thanks. I will test it tomorrow.

@TC

I would like to ask a big favor. Would you make me a "personalized" version of 1.2.2 with additional comments for "IF EXIST filname" blocks at the following places:

:HFBLOAT
:POSTHFX
the INFCREATORS
and SVCPACK

It would be a great help to know what those processings are exactly.