OK... I have something that works. Just want to verify something extra with the SVCPACK install and then I'll release it.

OK, thanks.

I have 2 other requests about hfslip, can you add support, in GuiRunOnce mode, for .cmd files?

Second request, can you add the support for copy files, as $OEM$ do? I mean if I put files in $1 directory, they'll go to %SystemDrive%, if I put files in $$ directory, they'll go to %SystemRoot% directory.
I know that in HFEXPERT directory of HFSLIP, there are WIN and PROGRAMFILES directory, but if I put one file in WIN, and this file has spaces in his name, Windows installation doesn't start, because TXTSETUP.SIF or DOSNET.INF doesn't accept files with spaces in their name.

EDIT: Tomcat I have found where the error messages are shown.
The first message (The system cannot find the file specified.) is related to KB902845 update. I don't know why this message is shown, because, when extract with hfslip script, there are 2 files (setupldr.bin and setupldr.exe), and the same result is if I extract that hotfix manually... Click to view attachment

The second message (The system cannot find the file 'DIR/B/A-D.)is after the copy of .cat files and before the driver.cab is extracted.
Click to view attachment

The third message (File Not Found) is when the script process the HFEXPERT directory, so I think it displays the error message because HFEXPERT/WIN or HFEXPERT/PROGRAMFILES is empty.
Click to view attachment

I have posted the image, so you can understand better

Thanks. Fixed in 70129b.

In the latest stable version there is an error in timezones update processing. I don't know if it's corrected already or not:

line 1117 - FOR /F "TOKENS=* DELIMS= " %%I IN ('FINDSTR/I "Time.Zones" TEMP\UPDATE\_TZC.inf') DO ECHO>>WORK\928388A.TXT %%I

I think you intended to write FINDSTR /R /I "Time.Zones\\ ", because without /R it ain't won't not find nothing.


note the "\\ " I added(a space is there!). This way you can use three less of those search-strings on the next line

EDIT: also I think it's not wise to write the parameters immediately after the command. I had found lots of issues, I can post some if you'd like, but maybe it's just because my cpu is buggy, or maybe it was "feature" not bug... like the above... dunno

I happen to have some issues too. I have rewritten HSLIP a bit, so it might be that i made this bug, but maybe someone can help me where look for solution:

SOURCES with FDV + HFCLEANUP +DX9 (an absolutely conservative general minimal install should be)

1, during install it pops up dirver signing dialogs (i set DELCATS).
2, many services are not removed, for example Utility Manager, which should be by Applications_AccessibilityOptions.inf, and many others. I found out that HFSLIP folder exists in WINDOWS folder, full of inf files. Now when I installed them manually by doubleclicking them, after a restart the entries in Services MMC are removed, so these infs were not processed for some reason during install. As I know the whole folder (WINDOWS\HFSLIP) should be removed by HFSLIP.CMD.

Any idea what is the cause? How does the install process goes exatly? SYSSETUP is called first, and it calls HFSLIPWUF or how? Is it possible that the whole hfslipwu.inf were not processed, or the issue might be with hfslip.cmd? Where should I start looking?

If any installation INF isn't written correctly, it won't install. Sounds like you modded the script and it broke some installation INF. Sorry, I don't plan on helping with this one, there are too many variables. If it means anything, the main setup infs are sysoc.inf, sysssetup.inf, and the hfslip infs. IIRC, syssetup.inf is only processed if using hfcleanup and/or using FDV files.

@TP - could you explain it a bit more...

1. the mistyping I mentioned is in the original HFSLIP, not my modded one.

2. I'm exactly sure there could be problems with writing the parameters next to the command. (i had one issue around hfcleanup, with a findstr i think. the one who wrote hfcleanup also knew something, since all commands there are separated for reason)

3. I understand that my problem above is not your concern in a way like if it happened with the current stable release, so I just asked for your oppinion about it.

Can you scetch the dependecies of inf files during installation? which is the root? what calls it? What is IIRC you mentioned?

By the way I don't make modifications to the script too much, just reidenting and reading it...khm and I had probably this issue for a year, long before I started thinkering the script...khm...

EDIT: Maybe I'm annoying, sorry for that. I wrote this, to be put in the end of :TZ928388 :

At least ON MY "STRANGE" COMPUTER it's working this way correctly. Maybe I'm wrong sorry for that.

EDIT 2: changed to work without RegEx in the 1st and 3th line

Writing switches immediately to the right of the command does not always cause a problem, although I did find that with one particular command it doesn't work. For all others, I have had no issue with it.

IIRC = If I recall correctly...

@whitehorses

It depends on the tool if switches can be combined or not, or even "attached" to the program's name. FIND needs them separated and "detached" but FINDSTR doesn't.

/R stands for Regular expression. It should only be used if there are regular expressions in your search string.

Just to make something clear: there's nothing "wrong" with the time zone code that's there in the current final of HFSLIP; it's "working" and produces the same result as your code. But I admit that your sample is better; I reworked it a little and it's now used in version 70130b. Thanks

I have the problem with the the newest test version in the text mode:


[TXTSETUP.SIF:
[SourceDisksFiles]

IE7_INST.EXE = 1,,,,,,,1200,0,0

I have had the same issue this afternoon when I have tried the latest version of hfslip

Sorry, guys. I didn't check the output in TXTSETUP.SIF when releasing the previous test release. Should be fixed now...

Hmmm... I just don't see why...

FINDSTR/I "Time.Zones" supposed to find strings like:
TIME.zones
time.ZONES
TiMe.ZoNeS

But never ever will it find the string with a space, which was probably what it intended to:
Time Zones

I checked the inf file in concern manually, and at least if you want this command to find something you should not search for /I Time.Zone literally. The "." in regex means any character, including space, so it will return the line you need. Altough this works, there is absolutely no need to use RegEx here, by the way. It would be more efficent and convinient to simply write:

FINDSTR /I /C:"Time Zones"

Using regex searches is just a waste of cpu power, so I suggest only using it when neccessary.



EDIT : So it turned out that findstr takes dots as wildcards by default, and I used total commander's search when I said that I found no occurance of "Time.Zones".

Wow, Tomcat! You've introduced a number of errors in these here test releases! Gotta be more careful there...hehe.

@TC - I see you have changed it in the newest test release. Unfortunately it wasn't quite succesfull, at least to say



This code is a bit different in some aspects than what I suggested, AND... beside that minor formating difference, that you left the spaces in front of the [String] section entries, by not adding that FOR in front of the last FINDSTR, ... which is not an error...
... there is one indicated with red: a missing /R. Though it's much smaller problem than it was before, since this one only just results in four additional entries in the strings section, which is harmless. But if you don't care about it, just ignore the whole line


EDIT: Sorry I will be really annoying I know, but I'm even a bit angry, because I was turned down when I said my installs are not behaving as they should. There are a LOT of such mistypings,as the above, even more serious. Call it bug or ERROR does not matter. Explain this for example:



Yes this is at the end of :CLOSURE, ("New binaries" it says) Should I be surprised if there a no "new binaries" processed when I install my shiny new Windows? I don't clearly see what's the exact results of this code, but I think it can be serious. Hasn't ever anyone noticed something strange about this?

EDIT 2: Ok here is another subject guys: EFFICENCY. Not as important as correctness and validity, but important too.

why would you write SRC1.TXT line by line to FULLSRC.TXT without making any processing on the text, instead of:

FOR /F "TOKENS=1 DELIMS== " %%I IN (WORK\SRC0.TXT) DO ECHO>>WORK\FULLSRC.TXT %%I

Have you tested what's the difference? Well I did! On my 1,4GHz PentiumM the second for cycle on a w2k txtsetup.sif takes 30 seconds!!!! THAT'S A LOT

EDIT 3: I did not want to offend anyone, I just want a clean install, and maybe help others to have so.

EDIT 4: here's the ... more efficent, less... script:


EDIT: the * is needed, sorry for omitting it first

That's right. I thanked you for the IDEAS in the changelog.

It's intentional. I thought you wanted things to go quicker.

I don't see the /R in your code sample. I only see a /VI and it's orange.

The first line is useless because it doesn't strip the tabs. If I try your code on an XPSP2 source, the following files are considered "new" if they appear in a hotfix:
wuau.chm
noise.chs
noise.cht
The only thing I can (and will) do is merge the first two lines of the existing code. I normally even do that, but I was using the temporary file at some time and forgot to update the code when it was no longer necessary.

The second line in your code is garbage: the resulting file is empty (0KB). I tried various alterations but nothing worked except the existing code. Also, I need the temporary file DRV.TXT for the processing of SPX.CAB and DRIVER.CAB.

Hi Tomcat, I've tested the latest version of the script, but there is one bug (maybe, I hope it's a bug or I'll become crazy ). I have slipstreamed Net packages version 1.1 and 2.0 in HFSVCPACK, and 3.0 in HFGUIRUNONCE.
When Windows installation comes to T-13, it installs all the net packages, instead of installing version 3.0 at first logon. Is it only a my problem or someone else has this issue?

This issue isn't present in version hfslip-70129b

I agree. It does not effect anything.


I wanted to color it red... now I changed it by the way /R is not in that sample because it's the original, not the corrected one. coloring supposed to indicate the place where it should have been.


I don't understand what do you mean by that. It works for me on w2k, both during HFSLIP process, and if I just run this command from commandline. I attached FULLSRC_TXTonly.TXT. Seems like it does the job correctly to me.


Sorry I mistyped it:
FINDSTR /I /B /R "[^=]*\." SOURCE\I386\DRVINDEX.INF>>WORK\FULLSRC.TXT
(red is the color)

NOTE: also attached the file to prove that it works for me at least on 2000. with the above script of course


Sorry for that too. I removed the multicab feature so I didn't recognise the dependency.


A question: a few lines below there is a line of code like this:
FINDSTR/IR "\.AX \.ACM \.OCX msxml..dll" WORK\NSFALL1.TXT>>WORK\NSFREG0.TXT
My question is that msxml..dll is what you intended to write? I during HFSLIP process I recognised that there are msxml3.dll and msxml3r.dll in as new binaries. This way only msxml3.dll is processed. Shouldn't msxml3r.dll be included too? If so, then it's needed to write:
FINDSTR/IR "\.AX \.ACM \.OCX msxml.*.dll" WORK\NSFALL1.TXT>>WORK\NSFREG0.TXT at least.
What's your oppinion?

I don't get 4 extra entries without the /R. I'll check out the Italian version of the timezone update -- maybe I'm missing something.

That's nice, but the TXTSETUP.SIF of my XPSP2 has a tab right after the three file names I mentioned (between the file name and the = sign). Your code does not remove that extra tab so I also get it in FULLSRC.TXT. A list of the new and updated files is made after that, and then existing file names are stripped out (so they don't get referenced again in TXTSETUP.SIF and DOSNET.INF) by comparing the two lists. If a hotfix updates those three files, those extra tabs in FULLSRC.TXT will cause DOS to think those files are completely new and as a consequence add duplicate entries into TXTSETUP.SIF and DOSNET.INF.

Alright. I'll test this in a bit.

The msxml*r.dll files aren't supposed to be registered to my knowledge. At least, they produce errors when registered.

@ TC

:TZ928388
The code in question was this, it's from 70130c test release:

FINDSTR/VI "America.Standard.Time.Dynamic.DST...2 Brazilian.Standard.Time.Dynamic.DST...2" WORK\928388A.TXT>>SOURCESS\I386\HFSLPHIV.INF

Just look at this string. "America.Standard"... you find no dots in the .infs, at least not in update_SP2QFE.inf of the hotfix WindowsXP-KB928388-x86-ENU.exe. Since a dot means any character in RegEx, it would recognise the line, if RegEx was enabled. But that needs /R.

But I suggest not to use regex at all, because it's not really needed there. Use this instead:

FINDSTR /V /I /C:"America Standard Time" /C:"Brazilian Standard Time" WORK\928388A.TXT>>SOURCESS\I386\HFSLPHIV.INF


:POSTHFX

I didn't know about that. I would ask MS why that 4 entries needed tabs, dooh
You are right, the first line in my exaple won't remove those, hmm...
At least w2k has no prob with that, there are no tabs in its txtsetup.
Another interesting thing is that I don't see how the code in 70130c can remove it. That won't do this scenario too.

Hmm.. this does:

FOR /F "TOKENS=1 DELIMS== " %%I IN ('FINDSTR ",,," TXTSETUP.SIF') DO ECHO>>SRC_LIST.TXT %%I

NOTE1: It's not visible, but there IS a tab AND a space after DELIMS==
NOTE2: For some reason tab must not be the last, or it messes up everything.



Short and full

hi! i'm so glad i was able to do create some build over the past couple of days ... using 70129a (although it shows here that 70130c is already out) ... here were some of the issues i encountered:
(1) as posted in a different thread: Trouble with slipstream Dell OEM Win XP, i encountered activation issues making use of Dell OEM XP Pro SP2 cd in a clone machine ... have also tried this this no wga but still the same
(2) given the above concern, naturally i had problems with wmp11 & ie7 installation too ... both were not there even if IE7SVCPACK=1 was specified in HFANSWER.ini ... even with rebootting upon finishing of OS installation ...
(3) please correct me if i'm mistaken, i do not need earlier wmp HFs if i were to slipstream wmp11, right? or are the following still required: KB911564 & KB894871 ... would there be any other specific HFs that are required?
(4) i encountered common errors as i hit the desktop: framedyn.dll not found & error loading srclient & only a few addons were installed (& still without wmp11 & ie7) ... i think these were caused by some add-ons ... (any of these could be the culprit: Kels_FGCBA_Handler_addon_v0.897.CAB --- for this 1 there was an error while still running the cmd during the integration of addons, NR_VistaUAP_Addon_1.1.cab, or Ricks_RTMSidebar_AddOn_v2.rar ... taking these out from HFAAO did not produce the aforementioned error ...
(5) likewise encountered at T-13 was this: [b]Installer initialization failed due to following error: Undefined error: Invalid command line argument "Q:A".[/b] ... although i realized later that some installers were incorrectly placed in HFSVCPACK_SW rather than in HFSVCPACK ... this has been rectified by transferring the installers
(6) these 2 .msis even if placed in HFSVCPACK_SW were not installed: TimeZoneSetup.msi & UFDSetupWizard.msi
(7) checking setuperr.log also presented a number of errors ...

i've attached some files that might be of help ...
really nice to be able to run create some builds again
thanks in advance

@whitehorses
It's intentional. The "FirstEntry" and "LastEntry" lines are supposed to be included in HFSLPHIV.INF.

@Kiki
1) HFSLIP supports the OEMBIOS addons -- at least, if I interpret them correctly. I personally doubt it you can use these on a self-assembled PC.
3) Important things to know
4) I'll check out those three addons
5) EXEs in HFSVCPACK_SW are installed with the /Q:A /R:N switches

ey TC ... nice to hear from you again!
(1) yup you granted my request on these previously ... the only thing that i noticed though is these files were only copied to an OEM directory ... created parallel to i386 & the rest ... OEMBIOS.* files already exist in i386 ... i do not know though if something is executed by the Siginet's addon ... i'll read further ...
(2) how about this?
(3) already read about this ... (been always recommending this link to the others who post related issues ... he! he!) ... KB894871 is a by-request only HF (would you have this HF TC ... could you kindly share it with me for download so i could test it too) while KB911564 if i recall it correctly is still needed for wmp11 as per S-M
(4) thanks!
(5) yup this screenshot is what i got (pls see screenshot ... oops i can't find it sorry) ... but i have th text copy attached
(6) how about this too?
(7) any comment on this?

really wish i could do more tests so i could participate more here ... he! he!
thanks!

What do you mean? (What first and last entry?)

hi! i'm just wondering since 7-zip has already been supported: Extended changelog for HFSLIP 1.0, would by any chance .rar be supported thanks!

@TC

Could you add support for reg files in HFGUIRUNONCE?

thanks

You can put them in HFSVCPACK directory... the results is the same.

@Kiki
1) I only have HFSLIP do what the information files in Siginet's addons tell it to do. As far as I can see, the result should be that a CMD is executed during Windows setup that takes care of everything.
2) WMP11 is slipstreamed. You don't get WMP11 when clicking on "Windows Media Player"?
3) KB911564 is not related to any version of WMP in particular so you still need it when slipstreaming WMP11.
4) There's something fishy about the Sidebar addon. When I include it (RAR will be supported in next version), I get an error message at every login saying that Sidebar couldn't start because some file could not be found. The strange thing is: this file is not part of Windows, it's not included with the addon, and the forum post you linked to doesn't say anything about it either. Crazy stuff. I also tested the other two addons you mentioned and they are OK as far as I can see.
5) Do a proper run with the version I'll upload later and then see if you still get that error message.
6) Do they require a specific version of .NET? I see in your log that you are installing .NET 1.1 and .NET 2.0 in one go; this will cause other programs to think .NET 2.0 isn't installed yet before rebooting. If that's the case, either put those MSIs in HFGUIRUNONCE, or remove .NET 1.1 (or put .NET 1.1 in HFGUIRUNONCE).
7) Same as 5).

Removing "Dynamic.DST...2" from the search string will cause those lines which contain "FirstEntry" and "LastEntry" to be stripped as well. They should not be stripped.

Not really. "HKEY_CURRENT_USER" doesn't exist at T-13; any such entries will be converted to "HKEY_USERS" by Windows setup. And if you add entries at T-13 they may get overwritten again by applications that are installed later on.

New version underway.

You are right, I missed that. Hmm... Then yours is the right string to search for, with regex of course

@whitehorses
I added your proposed changes except the /R switch. Is it really necessary? A dot is a wildcard and it's working fine without that switch for me.

I must check it. Maybe you're right. Are you saying that "." is a wildcard even without regex?
findstr /? does not say anything about that at least, but I will check it

EDIT:
Hmmm...
I've just understood why those brazilian and south american updates are filtered: they have a linebrake, and you added them manually instead... nice

EDIT 2:
Ow crap MS, you're right. I have seen many search utilities but MS can always give some surprising moments with their "standards". So no /R is needed in that case

EDIT 3: I have changed mine to the following:
... FINDSTR /I /R "Time.Zones.*Dynamic.DST" ...
... FINDSTR /V /I /R "South.America.*0x1, Central.Brazilian.*0x1," ...
Notice "0x1,"? That's the most unique difference I could found

EDIT 4:
I found a "bottleneck": In :INTEGRATE in the main binary compression FOR cycle there is a double use of if statment. There are many throughout the script by the way, but this one is the most inefficent since this cycle runs around far more than 500 times (as many files it has to process, it can be much more)

I suggest to change it to something similiar to this instead:

Right. I could have HFSLIP parse that INF section line by line (like it's done with the addons) but that would take too long on your Sempron

I could be wrong, but isn't that extra work? You're creating an extra temporary file.

Yeah. I didn't update that small bit yet. I'll change it to this:
Less lines...

I also updated the text a few lines lower (EXISTANT instead of EXISTENT) which I corrected in the 64-bit version draft but not here...

i think Siginet's addon is more geared for use in nLite & RVMIntegrator
not even a shortcut
gotcha! maybe we should put this & any similar info in Important things to know section
thanks for testing TC ... really appreciate it! i also got that error ... i was informed by ricktendo64 to include the following files: KB918997 & VAIO XP Build #2 (this is their project of porting vista to xp) ... as of my 2nd run still no go
will do ... although this was already resolved by moving the files to the correct directory ... completely my bad ... sorry.
will try this moving these .msis to HFGUIRUNONCE ... although they would install after OS install ...
okalready downloaded it ... have requested 7zip support before ... granted! .... & now requested for .rar support ... granted too! thanks much! i thik we are nearing a final ...

Well I made some modifications, but mainly it's the same, take a look:

It does the job. Uses one temp txt, and removes trailing spaces.


You mean that other compression cycle? What do you mean about "existant"?


And now that we are thinkering near these codes... can you tell me what is this line:

FOR /F "TOKENS=1 DELIMS=" %%I IN ('DIR /B /A:D /S WORK\I386E') DO IF ERRORLEVEL 0 DIR /B /A:D "%%I" >NUL 2>&1&&CALL :DPSCANSDIRS "%%~I"

This is the most cryptic line in the whole batch


EDIT: That ASM folder stuff can be written like this:

Not that crucial, anyway

Bug report

70202a or 70130c will not install IE7, which the stable release 1.2.2 have no problems.

I been trying to slipstream IE7-KB929969-WindowsXP-x86-enu.exe into my compilation which 1.2.2 will not do. Other than that, 1.2.2 will install IE7 and WMP 11 and other updates without any problems.

I tried 70202a to see if I can slipstream IE7-KB929969-WindowsXP-x86-enu.exe which is suppose to be supported but the end result is that IE 7 is not installed. WMP 11 is installed. There is not even an IE7 log in the Windows directory to indicate what errors occurred. There is an IE7 file in the svcpack directory and svcpack.inf, but no IE 7 after Windows completed installation.

Attached the log file.

@kenlau
That log is from HFSLIP 1.2.2 which doesn't support IE7 hotfixes so it's pretty useless in trying to solve your problem


@whitehorses
What does "0x1" do?

There was a typo in the accompanying (REMmed out) text. I corrected it. Search for "EXISTENT" in the current test release.

Haha. You're not a top grader, eh?
It's based on code by Yzöwl so you should ask him...

nothing. It's just a string. That's the datatype of the registry entry. Those FirstEntry LastEntry values have different datatype than the ones which store the customizations. This leaves in First/LastEntries.


Maybe you'll get surprised some day



... Oh ... I have a little present just for you... a little surprise

Oh, OK. Didn't see that, heheh. I'll put it in

Gimme a bit more time to try to figure out what it is...

What about this?

Talk about efficiency...

ouch... that hurts, thank you very much! You won.

OK...

I have put WindowsDefender.msi in HFSVCPACK_SW but Windows doesn't install it at T-13. Is it an HFSLIP issue or Windows Defender can't be installed at T-13?

For Windows 2000, Windows Defender requires gdiplus.dll. Put gdiplus_dnld.exe in HF and 7za.exe from the "7-Zip Command Line Version" package in HFTOOLS.

This used to be covered through an external file (HFSPLUG1.CMD) but was merged into HFSLIP 1.0. I removed the HFSPLUG1.CMD info from the site but apparantly forgot to provide info on GDI+ elsewhere. I'll rectify this.

@TC - please look at that sample, because it is really ... interesting...

I'm leaving in an hour or so, and it seems to me it's a high priority stuff.

@S3pHiroTh, Windows Defender can't be installed at T-13. I've tried it with the MSI and a switchless installer. Put the file in HFGUIRUNONCE instead.

I suppose this has to do with HFCLEANUP. If that's the case, I'm the wrong person to ask: I don't manage that part of the code. I never used or tested HFCLEANUP either so I'm not entitled to give any comments.

I see. I have to go now. By the way, I had some clean installs since then so probably this is a big catch.

OK Tomcat.

Attached my log file from 70202b.

1.2.2 will install IE7 but not IE7 hotfixes.

Your latest test release suppose to slipstream IE7 hotfixes but end up IE is not installed.

I think that's it in a nutshell.

@kenlau
If you create a multiboot CD you need to specify the path to the I386 folder when prompted to. If it will be located in X:\Professional\i386, you need to specify Professional\ (including the backslash).

I'm just curious, does HFSLIP support application addons in .zip format. If not, the only requirement would be 7za.exe in HFTOOLS.

Other than that, the current test release is looking good.

the_guy

What? They exist too?
Why can't they stick to something and keep using it? I can understand them using 7z, but RAR is payware and so is ZIP. Next thing you know they'll make them in TAR and ACE...

OK... I'll add support for ZIP...

I did not specify the i386 folder in HFSlip because I run winnt32.exe /noreboot and then edit the txtsetup.sif file to point that to the i386 folder. To cut a long story short, I first run Hfslip, then Bashrat's drivers, and the create the multiboot dvd as per MSFN's guide.

So far, it work beautifully, and usually Hfslip work without any problems. As a matter of fact, 1.2.2 work using this method without any problems whatsoever, but not the latest test releases. I ran the exact same hotfixes, updates and cab files in 1.2.2 and the test releases.

I notice another odd thing. I place UPHClean-Setup.msi in the HF directory as per your guide, but once I ran Hfslip, I notice that it move this file to HFSVCPACK_SW directory.

I always edit txtsetup.sif so it will point to the i386 directory. I just notice that I need to edit the hfslip.cmd file in the svcpack directory as well. I will do that and retest, but the odd thing is that I did not do that for 1.2.2 and the installation still went smoothly.