OK. The new version is there...

hi!

the header for the the thread shows: Test releases, 60510b
but from the very 1st page it shows:
Main program: HFSLIP_60517a
External files: HFANSWER.zip / HFSPLUG1.zip / DBLBINXP.zip

just i bit lost ... but i've aleady downloaded 517a


oh btw ... this means we have a little cleaning up to do on some items we have in HFTOOLS dir (i.e., remove xpize.txt & isoconf.txt), right? or would HFSLIP ignore its presence?

HFSLIP would ignore their presence, yes.

hi to everyone!
Tomcat, i just like to share what happened last night when i attempted to create a new build using 517a & perhaps get your insight why some things happened.
i'm once again stuck at 39mins overnight.
it may not be worth the worry but i saw these lines (or the likes of it that happen for different addons) passed by several times during the process:

Processing Addon_Notepad2G_dgelwin.cab
File Not Found
File Not Found
0 File(s) copied
FINDSTR: Cannot open TEMP\INI.INI
FINDSTR: Cannot open TEMP\INI.INI
FINDSTR: Cannot open TEMP\INI.INI
FINDSTR: Cannot open TEMP\INI.INI
FINDSTR: Cannot open TEMP\INI.INI
FINDSTR: Cannot open TEMP\INI.INI
TEMP\AAO\Entries_Npad2.ini
TEMP\AAO\Notepad2.EXE
TEMP\AAO\Npad.exe
TEMP\AAO\Npad2.inf
TEMP\AAO\Npad21.inf
5 File(s) copied

does HFSLIP tackle the KBs (fixes) 1st over those in the addon packs (ie, ryanvm's update)?
should there be duplicates with the contents of HF folder & those that are in the update pack, which will HFSLIP prioritize or ignore?

for the removal files, these would be the add-ons from ryanvm's website too, right?

i have attached too some text files for your ref
ryanvm.txt is just the .inf file renamed fr RVMUpdatePack2.0.5.cab
nliteaddon.txt is simply about some addons i used via nLite for reducing the source (incidentally, nLite just moved these 2 files to i386\svcpack dir as .exe files) ... oh btw, could we use nLite addons too in HF? (i will experiment on this also tonight if i won't be dead tired )

could there be anything i've done wrong that messed things up?
i suppose i missed on recompressing the cabs via nLite ...
i haven't had this frustration for a very long time ...

i will be creating new builds again later ...

thanks again!

Can you do this:

1) Get the latest internal build
2) Download cabsdk.exe, get EXTRACT.EXE out of it (it's in the BIN subfolder) and place it in HFTOOLS
3) Remove hotfixes that are included in the RVM Update Pack
4) Remove duplicate addons

See if you still get the "File not found" messages.

will do sir ... have already done it ... (517b & cabsdk.exe)
if only i had more time last night (& didn't fall asleep doing such), i would have experimented on removal & retention of fixes
thanks!

Found the prob. Sorry...

(60518a)

no biggie TC!
got 518a ... btw, were there changes made to the other 3 accompanying files: HFANSWER.zip / HFSPLUG1.zip / DBLBINXP.zip?
thanks!

No, but here's a general note for you: you don't need to include everything that's available; just take whatever you need.

crystal sir!
i do not include those i do not need (some are present though in ryanvm update pack ... but i guess the update caters to all types of users be it for desktop or portable)
if its regarding the zip files, i won't use what i don't need next time!

hi!

i was able to come up w/ a successful build after 3 tries ... the most significant change was the removal of .cab files ...

i'd just like to ask if this has some effect on the build though:

Creating ISO...
G:\HFTOOLS\mkisofs.exe (600): *** Could not create mutex for list synchronisation.

do we need to remove also directx files from the HFCABS folder if already in ryanvm update pack 2.0.6?
in short, anything that is duplicated needs to be removed?

attached is HFSLIP.txt for your reference is needed.

as i understand, HFSLIP actually considers only the latest file version when recompressing, correct?
as such, HFSLIP should just ignore presence of duplicate files, right?
please correct me if i am mistaken.

thanks again!

CAB files or CAT files?

I've really no idea. I never use mkisofs so I don't know this program. TommyP added support for it a long time ago...

It's already at version 2.0.6? Then I better check that it's still working properly in HFSLIP, hehe. I used 2.0.5...

Your file list is getting better. There are still some duplicates. Did you check RVM's list?

You can remove msxmlcab.exe, msxml6.msi, the D3DX9 cabs, swflash.cab and MUWEB_SITE.CAB. At this moment, you don't need LegitCheckControl.cab either I believe. There could still be some hotfixes that you can remove but I didn't verify that.

Are these two different programs?
Addon_LClock_v4w_dgelwin.cab
Addon_LClock_v4_dgelwin.cab

Yep.

Not exactly. If there are files with identical names then the latest will be used. But SYSOC.INF or SVCPACK.INF will install the program more than once (once per addon). This isn't necessarily problematic but it can be. It's best not to try that out.

hi Tomcat!
oops ... i'm sorry ... CAT it is!
he! he!
yup i did check the list but i focused more on the KBs ... as for the rest, they've been sitting in the folders eversince (mostly those in the HFCABS
yes sir ...

TC, pardon me for asking but will HFSLIP eventually come to completely support RyanVM update addon?
Honestly, I do not have anything against it. In fact, it helps us getting just 1 big chunk than having to download each hotfixes (that apply to our systems). (It is helpful RyanVM! ) However, this brings me to the next question about the path HFSLIP will thread ... having everything done the HFSLIP way!
On the other hand, should HFSLIP completely welcome the use of the update pack (& some others), perhaps we can request RyanVM (& the other creators) to consider HFSLIP's processes & requirements when coming up w/ update addons for best compatibility purposes!

Sir(s), again from my end ... however or whichever way you guys decide to bring HFSLIP ... i will support it! It will just be a matter of getting/using the resources for coming up w/ successful builds!

btw sir, in some other builds i experimented on, i tried adding regular .exe installers in the HFSVCPACK FOLDERS & until now i've been observing their functions in the GUI already & i see nothing wrong ... they install at T-13 & completes successfully ... and works fine while in the OS already ! anything bad about doing this?

Thanks!

It is supposed to be supported completely. Your CAT problem seems to be unique. The only part that isn't covered is the removal of duplicate driver binaries but that's "corrected" with DBLBINXP.EXT.

Not that I can see. But you're lucky... XP is "better" than 2000 at letting you install things at T-13 but it's still not perfect; some programs (like MDAC_TYP.EXE) just won't install at T-13.

KiKi, im sorry if this has been covered before, but why are you using hfslip at all if your going to use the RVM Pack? Most, if not all of the updates covered by hfslip would already be in the RVM pack i would have thought?

Dont get me wrong, its great your testing hfslip because they can always use more testers, but i was wondering. Personally, the reason i use hfslip is so i dont have to use the RVM pack.

If you're just into adding "all" hotfixes then you can do with the RVM Integrator in this particular case. But HFSLIP can do much more than adding hotfixes.

Good point TC. Maybe im just slow, but for some reason i didnt think of the extra features like adding in codecs automagically, easy appreplacements, etc when it came to XP. I think i've been fiddling with Win2k to much!

Hi, I think I have put my post in the wrong plance and this is the better one. There is a little problem with sliplstream of KB897338 for non-US Windows, because this hotfix change the default value (in INTL.INF, sectio [Defaultvalue]) of locale to 00000409, this make the UWCD useless for atualization and give conflict of idiom. I think it would not dificult to implement a correction in batch file for non US to return the original value. I have slipstreamed with and without this hotfix and the problem occur only with it (by the way I´m using the HFSLIP_60518a version)

When I run HFSLIP_60518b with files in the HFEXPERT\WIN subfolders, the files do not get installed. This is what is put into TXTSETUP.SIF:

[WinntDirectories]
1101 = "PCHEALTH\HELPCTR\BATCH"

[SourceDisksFiles]
cmdow.exe = 1,,,,,,,2,0,0
sifdir,0,0
sifdir,0,0
sifdir,0,0

As you can see the directory is identified but the file output is sifdir,0,0. They are correct in DOSNET.INF.

Also on line 2359 is the following command, DEL/Q/F DRV.TXT. This causes an error when HFSLIP is running as there is no other reference to DRV.TXT in the command file.

heisking: Can you attach your log file or tell us the directory/file structure of your HFEXPERT folders?

The sifdir variable is part of the HFEXPERT script section in HFSLIP. However, it is not supposed to be added to TXTSETUP.SIF, of course. There may be something wrong with the structure of your folders.

That's a strange problem, heisking. I placed a file in HFEXPERT\WIN\PCHEALTH\HELPCTR\BATCH and let HFSLIP do its thing. The filename was entered into TXTSETUP.SIF correctly.

As Super-Magician said, could you attach your zipped HFSLIP.LOG file? Thanks...

TC
Here is the zipped HFSLIP.LOG file.



Click to view attachment

I've no idea how to handle file names that start with an exclamation mark in this context. Maybe Yzöwl knows this. Would it be a problem to use an underscore or something else instead?

You would really need to turn off the delayed expansion. It may be possible to toggle off, then back on again, where required.

I would suggest you don't, not due to any difficulty, more to do with the principal. It's a similar thing to the expand and %xpand% thing we went through recently. The script is already at a stage where it needs constant update in order to remain current. It cannot be expected to cater for people using !obscure! (non-standard), naming conventions.

Whenever you work with files using command scripts and delayed expansion you expect this to happen. The script writer due to the unexpected expansion of the project, didn't forsee the introduction of 3rd party files and therefore the problem occurs. It will take considerably more work to fix at the script end than it will for the complainant to rename their own files.

What exactly does the ENABLEDELAYEDEXPANSION thing do?

In simple terms, when a script is invoked, it is read in its entirety prior to execution; (all environment variables are expanded at this time). Delayed expansion means that the environment variable is read when it is reached during execution. A delayed environment variable uses an exclamation mark, as opposed to a percent symbol, hence the problem.

The script has uses delayed expansion, because changes are made to variables within FOR loops. The HFSLP variable is incremented by one for example, meaning that its value is almost dynamic instead of static. When the script is read initially, this 'dynamic' value has not yet been created; therefore in order for it to be used it must be read at execution time.

In order to fix the problem mentioned above, every FOR loop using delayed expansion, would need to make a CALL expand the variable return back.

Even though I did use nlite, HFNetChk does not complain about any missing update.
In fact it says blablablaSP1, not SP2, blablabla and 2 files that have file versions greater than expected.



It's maybe the best iso I ever made.
Thanks a lot.

@Camarade_Tux: Which version did you use?


To everyone...
Any new problems with this release? No more updates are planned for the next final release except for a "cosmetic" change in the part that handles HFCLEANUP. This needs to be rounded up as the current final doesn't handle some of the hotfixes that appear on Windows Update.

To check:
- WinXP SP1: when not including MDAC_TYP.EXE and MP10Setup.exe, Windows Update should only propose WMP10 and the Windows XP Documentation Update
- WinXP SP2: RVM Update Pack
- Win2K: Gurgelmeyer's USP5
- application addons
- HFEXPERT

0521d as far as I remember and HFCleanup (dblinxp.ext I think).

hi Axed!
i have been using & testing HFSLIP for quite sometime now & (just like the others) i'm trying to see which fits & otherwise ... i believe doing so makes Tomcat & tommyp consider some other ideas ...
everybody's contribution is important to make HFSLIP the best it can be ...
as Tomcat & tommyp know, know that i am all for doing things the HFSLIP way ... & i couldn't agree w/ you more ...
but then again, if it always worth testing HFSLIP!

So how's 60523a doing IRL?

thanks alot to you, tomcat76!

i am using livestate too and had problems because wmplayer10 and scriptde.exe gave me errors during the installation process (. i just tried your new test-release (HFSLIP_60523a) and now it works!

during second copying phase in setup i got errors for 40 files, starting with

qasf.dll
scrobj.dll
scrrun.dll
wshcon.dll
...

so if you encounter problems with livestate or winnt.exe installations - try this new release!

i think 60523a is quite stable as there has been not much reported issues w/ it ... perhaps a final then?

Hi all!
I have question about:

KB912817
KB918005

Are they handled by current HFSLIP?

Have you tried?

@SQ5FG: I quickly checked them and they should be supported.


If no new test version will be released, the only difference between the current test version and the next final will be: added support for IUCTL.CAB in conjunction with RVM Update Pack when WindowsUpdateAgent20.exe is absent.

Checked OK:
- WinXP SP2 English + RVM Update Pack
- WinXP SP2 Dutch + SWFLASH.CAB

Still to be checked: WinXP SP1 + Win2K USP5

hi SQ5FG!
for hotifxes supported by HFSLIP, you may always cross refer with:

Windows XP updates and hotfixes (maintained by Tomcat76)
http://www.msfn.org/board/index.php?showtopic=62177
Windows XP (all) (maintained by the guy)
http://www.msfn.org/board/index.php?showtopic=74840

Thank you guys! :-)
I am going to do my slipstream and finally reinstall my current faulty system. :-)

I tried latest test release without nlite; wmpui.dll should be updated since I have WMP8 (which I usually remove with nLite).
Other updates seem to be alright (though I still have to test two of them I did not have in \HF)



edit: @Tomcat, 833989 seems to be needed but you do not list it. It corrects the GDI+ vulnerability.
It is really confusing because lots of applications are concerned but I think I finally understood it:
-KB833987 updates Windows GDI+ component
-KB833989 updates IE6 SP1 GDI+ component
See this page (in french) http://www.microsoft.com/france/technet/se...e/ms04-028.mspx
The IE6 patch is listed at the middle of the page and contains vgx.dll.

@Camarade_Tux: HFSLIP didn't process KB911565 because of an old restriction for KB817787. That's corrected now. Quite a coincidence... I was testing XPSP1 the last couple of hours and noticed the same thing...


We're nearing in. I still need to do some stress-testing on Win2K, especially with USP5 as there seem to be some problems in that domain.

I updated my XP SP1 hotfix lists (thanks Camarade_Tux). I hope everything is OK now...

Ok. Anyway, with latest test version, everything is OK.
All updates are present, tested without nLite.

HFNetChk reports all WMP updates are present, MDAC update not present (normal since I don't want it), and two files version greater as expected.

And just a quick note : these files are post-installed:
Q914798.EXE
Q840374.EXE
Q832483.EXE

Thanks a lot for this version.

Win2K with SP4 and hotfixes went OK except that the MDAC 2.5 SP3 hotfix wasn't processed. That's fixed in 60527b.

Still to go: Win2K + USP5...


@Camarade_Tux: That's great. Thanks

USP5 is a strange thing. Kramy already told me the other day he got file copy errors in the beginning of Windows setup and I experienced the same a few hours ago. I traced it down to the slipstreaming of the USP5 service pack itself: some binaries (413 to be exact) are not copied into the source. This can only mean two things:

- my w2ksp51.exe file is corrupt
- the standard MS service pack switches are not supported by USP5

I checked the FAQ on the Hotstream forum and noticed that only the /integrate method is listed as a supported slipstreaming method. So I tried that, but the result is the same.

I'm now in the process of downloading the latest version... Be back in an hour or so...

I'm gonna ask for support on the Hotstream forum. I download the latest version and the same thing is happening. I even slipstreamed (or attempted to slipstream) USP5 outside of HFSLIP...

Ok, here's the lastest I've got - these screenshots show the discrepancy. The first two are of my flawelessly working HFSLIP mod ver. The second 3 are of the latest test release.

Click to view attachment
Click to view attachment

Notice the filesize differences...and that even stream.sys is missing from it.
Click to view attachment
Click to view attachment

Also, a missing file on the first line - not sure what, and haven't checked if my perfectly working ver has that or not.
Click to view attachment

I know that Tomcat rearranged a lot of slipstreaming code, and while poking around today I caught a few errors. Sadly, I didn't notice them when I originally duplicated them, so I had to fix them in my ver as well. Due to the particular order though, they had no effect in my version.

It appears that "ELSE" is not a recognizable command unless it's on the same line as an IF.


However, the above folder sizes were taken after applying the ELSE fix. Now I need to test if my latest ISO will install, which I doubt it will with several hundred missing files. I'll report back on if it works or not.

Kramy: I do not believe any ELSE fix was required. In all of the original code for the :HFSPACK4 section (60527c), the ELSE commands were on the same line as the corresponding IF commands.

If the problem you are experiencing is indeed an HFSLIP script problem, I guess Tomcat must have gone too crazy with the cleanup .

Ahh, he must have beat me to it then. He sent me multiple versions last night(60527a,60527b ), and I said I'd look into some error messages in the morning.

Yep... That problem was fixed in the 27c release.

Either way, the one remaining problem (414 missing files) is not an HFSLIP problem. I suggest we continue that discussion in the other thread.

I've sent a new final version of HFSLIP to TommyP a couple of hours ago which is based on 60527c but has the USP5 functionality stripped out. I'll let him decide what we're gonna do...

I don't understand how it can't be an HFSLIP problem, since I have a totally fine older version of HFSLIP that outputs a working slipstreamed & nLitable SOURCESS every time. Well, assuming I move the exe back to HFSPACK before running it, that is.