Tomcat76

HFSLIP - Test releases

2,380 posts in this topic

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:

[ROROE]
HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\ZZA","200",0,"RunDll32.exe %11%\AdvPack.Dll,LaunchINFSection %10%\HFSLIP\HFSLP200.INF,DefaultInstall"

...

all of that was supposed to be one line

0

Share this post


Link to post
Share on other sites

@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?

0

Share this post


Link to post
Share on other sites

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.....

Edited by tommyp
0

Share this post


Link to post
Share on other sites

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

post-85355-1170637938_thumb.jpg

Edited by Super-Magician
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

Edited by Super-Magician
0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

@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...

Edited by Tomcat76
0

Share this post


Link to post
Share on other sites

(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.

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.

Edited by Super-Magician
0

Share this post


Link to post
Share on other sites

You should be seeing four files, but it should be these:

HFGUI1.EXE

HFGUI2.EXE

HFSLPGUI.CMD

HFSLPGUI.INF

0

Share this post


Link to post
Share on other sites
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...

Perhaps if I understood their intended purpose...

0

Share this post


Link to post
Share on other sites

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

[not XPSP1]new HFANSWER.INI variable (INCALLSKINS=1) to include all abandoned WMP skins that still exist in the source (overrides INCWMPCSKIN=1)

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?

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.