If you are using the ISO to do clean installs, you can remove all the folders except for i386 and $oem$. The other folders are used for upgrades and whatnot. If you have your application addons and silent installers folders all filled up, then obviously you'll have a bloated iso too. HFSLIP isn't smart enough to delete things like that for you

To get these up to date update these files:

MUAuth.cab - authorization.xml 21-05-2009
MUWEB_SITE.CAB - muweb.cat, muweb.dll, muweb.inf 06-08-2009
For WGA I use an addon http://rapidlibrary.com/download_file_i.ph...-2+-+redxii+.7z

Hi,

I'm using this ISO to do clean installs.
I haven't got $oem$ folder, addons ou silent installers folders.
My ISO is just a installation CD XP POST SP3. (I have just winnt.sif + winnt32.sif)

Folders "cmpnents", "DOCS", "DOTNETFX", "SUPPORT" and "VALUEADD" take 79.1 Mo.


My "MUAuth.cab" : 21-05-2009
My "MUWEB_SITE.CAB" : 16-10-2008 (Your :06-08-2009) => This is the problem ?

WGA_Validation_AddOn_1.9.40.0-2_-_redxii : how can use it ?

Thanks !

download here http://www.update.microsoft.com/microsoftu.../muweb_site.cab
put WGA_Validation_AddOn_1.9.40.0-2_-_redxii in the HFAAO folder.
xable has them too, didn't test them. http://xable.net/

With the new "muweb_site.cab", I have got the same think :

Windows Genuine Advantage Validation Tool (KB892130)
Windows Genuine Advantage (KB905474)

I haven't integrate WGA_Validation_AddOn_1.9.40.0-2_-_redxii because I don't know where is HFAAO folder.

I need extrat 7z file in the HFAAO folder or integrate directly the 7z file ?
Where is HFAAO folder ?

Best regards

Forget that "Addon", just put legitcheckcontrol.cab instead (plus the other cabs: muauth, muweb_site and mucatalogwebcontrol).
After that, WU only wants that useless crap, WGA notifications.

Thats exactly what the addon gets rid of.
Place the addon in <HFSLIPDIR>/HFAAO if you don't have this directory you can create it.

Just a dumb question I have to ask. Is anyone else besides gluon having problems with kb973525?

I don't have problem with kb973525.

Kind regards

No Problems here with kb973525.

Got distracted for a while by real life, but I did mean to get back to the problems I was describing in the Windows Update topic.

It turns out that they don't seem to occur (though I did switch test machines too) when using the 1.7.9 S release rather than the nominally stable 1.7.8 release (I did mention at one point that I was using that release, but perhaps not prominently enough). Since HFSLIP.org encourages people to report problems in the forums here I did so; since I was using the stable release rather than a test release, I did so in what appeared to be the appropriate topic.

It might be helpful to explain (if indeed this is the case) that HFSLIP development (and in particular bug-fixing) focuses on the beta releases rather than on the stable release. It might also be helpful to capture a snapshot of the set of set of updates which the stable release seems to handle correctly and associate that snapshot with the stable release, since it appears likely that updates occurring after the freezing of that code may well not work correctly with it (at the very least, warning people about this would have prevented the kind of wasted time on both my part and yours that occurred). Failing that, I'm not sure what useful purpose having a stable release (and directing people to it) serves.

- bill

It still doesn't slipstream the WGA update. I have been using beta s, but the 905474 update still doesn't slip. I tried using Xable's addon by placing it in the HFCABS folder, and it worked on Windows XP Home but not Windows XP Pro. Any ideas or suggestions on how to get this stupid WGA to integrate?

mserbin - check out this: http://hfslip.org/extras.html. I think you need to put in a few more files into HFTOOLS, or at least your last hfslip.log file you posted in a different thread didn't have it.

billtodd - I keep a running changelog in the first post of the thread. There is also a changelog in the downloaded zip file. 95% of the changes are due to MSFT not being consistant with their file and folder naming structure. Sometimes what they do for english isn't the same as other languages. HFSLIP attempts to correct this. It's pretty much beyond our control on how MSFT names things. Also, MSFT likes to classify non essential things as critical updates, and then people start pulling their hair out because hfslip didnt' slipstream something non essential. Scare tactics... gotta love it. Hey, it's Halloween today, what a good time for a scare tactic. The reason why there is a release at hfslp.org is because it's tomcat76's website. A brief history lesson for you. I developed hfslip as a personal tool for my 2k box. Then I decided share it with FDV and integrated it with his fileset and released it. Several years went by and tomcat76 approached me, he had some excellent ideas on how to better the code. Then and I co-maintained it. He was a far better coder than me, so Tomcat76 maintained it for a year or so, until he he went missing in action. Its' been almost 1.5 years since I have heard from him. During the time tomcat was actively handling things, he generated a cool website. Currently I have plans to update the download zip file there in a bit, but the site isn't administered by me. I'm at the mercy of someone else to update it. Sorry you had to run a few HFSLIP runs. Think of what I had to do in the past... hfslip runs on several OS's each with different variations of WMP and different variations of IE and with and without plugins. During the early parts of writing hfslip, I cooked a hard drive to death. Yes, the drive was shot and I lost some good data. Now that's a lot of runs! To properly produce a stable release would mean I would need all OS install disks (OEM, Retail and VLK) for all languages and run the script on each. Then test 4 or 5 different ways on each disk. Multiply that effort by 2, because there is 32 and 64 bit host OSs I have to run it on. A monsterous task. Recently, a majority of the beta changes are due to some fluke that msft does, or to add some code that someone creates. Case in point, gluon can't slipstream some activex rollup thing that seems to specific to his language cd. So I have to add a workaround for it. I welcome code to add. Trust me, I don't like changes either, but the root of this problem of it is that msft keeps changes things and we cannot fix the root of the problem. Nlite has similar issue with this, but I do not recall seeing an update there in some time, so nlite users are still seeing and complaining about things not slipstreaming. I try, when possible to keep things updated.... and I do it as a free service for you and others. Please, let's keep this thread to discuss what probs you are having, and please report it as simple and concise problem statement. Let's not get into the who's and why's and reasons of beta releases.

To all - With that all said, a new beta was released to fix a dell cd issue that mserbin and some others were having. Mserbin reported that x64 host OSs can run hfslip, and code was added to properly detect the host. Mserbin provided and improved OS detection algorithm. Also, gluon reported that his activex rollups weren't slipstreaming, if you are experiencing the same problem, read the hfslip.log file. Most of the changes won't affect anyone, but as usual, I'd like to get a feel for maturity of a 1.8 release. Please report your findings.

tommyp -

Indeed, you keep a running changelog in the first post of this thread. The fact that this thread is specifically directed at 'test releases', and the fact that its first entry starts with the statement "These versions are test builds and are pretty much stable. As usual, use them at your own risk", and the fact that it then redirects people (twice) to the 1.7.8 release, pretty much ensures that anyone looking only for base functionality rather than for the latest bells and whistles will first check out the 1.7.8 release and if it appears to offer the facilities they need look no farther (at least until they find it doesn't work, at which point they'll start notifying you of the fact, as I did: where I come from, released but not yet retired software that no longer works has a high priority for fixing - or at the very least documenting its limitations).

Perhaps you misunderstood my previous comment: it was in no way a complaint that you're not working your tail off (something I've come to appreciate even more as the complexity of this task became more apparent), or that HFSLIP is not a useful project. It was very specifically a comment to the effect that HFSLIP is poorly described as a tool. In particular (and I now realize that this is somewhat beyond your control at HFSLIP.org, but not here) HFSLIP 1.7.8 is presented as a stable and hence presumably usable tool, when in fact on any kind of on-going basis only a recent beta (assuming that it works reasonably well, which 1.7.9 s seems to have done for me) comes anywhere near that definition.

If HFSLIP is going to be presented as a tool that anyone with moderate technical skills can use, rather than as an interesting development project that anyone may participate in and perhaps benefit from, it needs to be presented in a way that people can use without knowing the kinds of things I've had to learn over the past few weeks about how it works internally and how it is maintained. One way to do this might be to track the most recent beta release that seems to have been reasonably stable, snapshot the set of updates that it worked well on, and present that as the release of choice for people just looking for a tool rather than a project. Any release presented as such a tool should be kept up to date *for that set of updates* - i.e., if some flaw in its handling of those updates is later discovered, it should be documented or, preferably, fixed (that's the definition of 'released' - as distinct from beta - but not yet 'retired' software, at least it was back when I was developing software more actively).

This is the second time that you've suggested that I was posting in the wrong thread, which demonstrates another area that could benefit from better explanation (i.e., what topics belong where).

Once again, I'm not requesting anything here save that you present HFSLIP as what it actually is. If you don't care to deal with anything but the current beta, just say that so that new arrivals will know that HFSLIP is not something they can 'just use'. If you want to take another relatively small step and create something that people can 'just use', pick a recent beta that works well, snapshot its associated set of updates, and point people there if they aren't interested in having a more intimate and on-going relationship with your project (maintaining that as a separate topic which gets reinitialized with each new apparently stable beta would give them a place to report problems so that others could see them and you could make sure that they're fixed in the next beta placed there, while otherwise keeping those discussions out of your hair if you don't have the time to engage in them).

Beyond giving people that minimal understanding of what they're getting into if they choose to try out HFSLIP I'm not suggesting that you have any additional moral obligations whatsoever: it's not as if you were getting paid for any of this, and the input presented here by others should make it clear how well HFSLIP is meeting its stated goals.

- bill

TommyP, I checked out the extra's page but not sure what tool I need. All my slipstreams are with XP SP3, and the extra file removal addons for XP stop at SP2. The other 2 things listed on the site were for XPize and the HFSLIP answer file. Currently in my HFTOOLS I have bbie.exe, cWind.exe, modifyPE.exe, mkisofs.exe, cygwin1.dll, and boot.bin. Is there another tool I need to help get this WGA update to work? Thanks for all your help I really appreciate it!

sorry maybe a bit of misunderstanding here I got no issue with the latest killbit hotfix kb973525 whatsoever.

I was just wondering whether this 1.7.8 changelog entry is still relevant even for the latest killbit hotfix

"current cumulative ActiveX KillBits are force-added by HFSLIP so it isn't needed to include KB948881 or KB950760 To override this behavior, specify NoKillBits=YES in HFANSWER.INI."

and whether there is still value in keeping the code since it seems redundant given that we would have to put future killbit hotfix everytime Microsoft updates it.

Again I'm so sorry for causing u so much trouble, I thought u were going to update that section of the code to cater for future killbit hotfix so we don't need to put the latest killbit hotfix in HF folder.

mserbin - If you are using the hfaao folder, you'll need a few additional files. In the hftools folder, you'll need extract.exe if you have cab files; you'll need a 7za.exe in hftools if you have 7z files. There's details about it on the "extras" at hfslip.org.

tested rev T without putting the kb973525 in HF folder and MBSA still reports its missing kb973525.
I'd like to reiterate that this is a NON-ISSUE. I'll be putting kb973525 and any future killbit update from MS in the HF folder.

It's more of a question whether the killbit section of HFSLIP even worth maintaining given that the benefit is not immediately apparent (it doesn't satisfy MBSA or qfecheck). I know it sounds stupid and reckless but I just feel the killbit section of HFSLIP doesn't seem that useful and could be safely removed.

Since I'm only using Windows XP 32-bit EN I'm sure there are other things that I haven't considered and I would appreciate it if tommyp or someone else could shed some light into it.

gluon, yes that code is pretty much undocumented. I'll remove it when it comes time for final. Nobody is complaining it's not working, it's probably time for a new final. The hard part will be updating the main website...

I know this is a crazy idea, but given that you're having trouble with hfslip.org would you consider code.google.com or ourproject.org to host your project?

There you go I've said it..... awaiting flames from every corner of MSFN.

I'm not opposed to the idea. But please note that we aren't having trouble with the current site. It is just that our webmaster is on hiatus.

When using the t release i get the following error.




not getting this error when using the S release

I was afraid this was going to happen. Can you zip up your old and new txtsetup.sif files as well as the hfslip.log file?

Here you go. freshly made

Weird, beta t works just fine for me

Glowy, What is HF923800.INF? Do you get any other errors other than HF923800.INF not copying? Something tells me that HF923800.INF is the only prob. This is something you are adding in and not a hotfix.

Delete the HF923800.INF = 1,,,,,,,999,0,0 line from your txtsetup and it should work fine (hint type in makeiso instead of i have read the instructions. A new iso will be created using the sourcess folder.

It seems that the prob lies in HFSLIP_PRE_KB838079.CMD or HFSLIP_PRE_KB923800.CMD. Is there a way I can view those files? Where did you get them?

edit again - looks like you can delete those two CMD files I just mentioned. They are outdated and not required. Rerun hfslip and you should be OK. Please report back.

files removed (also from _EXTERNAL) making a new build (I removed the sourcess folder). Will report back after install is done.

EDIT:problem solved! thanks!

Also working fine for me too!!

A new final was released on November 9, 2009~

No Download Link~~

L-F - Please be patient while Tain updates the website.

It is updated now for those who are in a hurry. But TP hasn't had a chance to check the changes to ensure I didn't screw something up, so proceed with caution until he chimes in.

Sorry I'm so slow on the webmastering...we really need Tomcat76 back

I notice the HFSLIP 1.7.9 doesn't contain the latest KILLBITS anymore. Were these changes causing problems?

Was it causing a problem? No. However, V1.7.9 includes the same killbits as v1.7.8. It's ridiculous to continually update the hfslip for activex killbits that are released every month. There was a lot of back and forth killbit discussion on the past few pages. The conclusion that evolved is that hfslip processes msft killbits hotfixes without error.

Hello All,

Just finished my testing of v1.7.9 with Windows 2000 and it worked fantastic!

The only modifications I had to make were:

Put DNF1120 from Silent .NET Maker synthesized in HFSVCPACK folder.

Put "Windows2000-WindowsMedia-KB952069-x86-ENU.exe" and "Windows2000-KB958470-x86-ENU.EXE" in HFSVCPACK_SW1 folder changing the filenames to KB952069 and KB958470 respectively.

Put "Silverlight3" in HFSVCPACK_SW2 folder changing the filename to SL3 and changing switch to \q for silent install.

With those changes in place everything ran smooth.... no copy errors ....no updates missing .... heck, no errors at all.

Great job tommyp. Thanks to everyone who posted helps to get me through.

Now it on to testing XP. Report back when I'm finished.

M2GD

hi! if using ie8, is silverlight.exe supported & if it is, does it go in HF too? thanks!

Silverlight = not critical update = not supported. Sorry Kiki.

np tp! i seldom use ie8 anyways (but just for complete ms update's sake i have it slipstreamed too ... and when you pull it up, sooner or later it offers installation of silverlight) just wondering, would the trick by M2GD (as posted above) for his 2k work with xp? ... i always have firefox handy thanks!

btw, would a .7z file (in my case, XPDNF11SP120SP230SP235SP1.7z as output from running Silent .NET Maker synthesized 20091105 ... i've already asked strel in another thread & just waiting for confirmation if i had it right) be processed correctly if placed in HFSVCPACK folder? thanks again.

kiki - I'm sure m2gd's fix will work fine. If it works on 2k, then 99% of the time, it will work on xp. For your 2nd q, if the installer switches are known and you place it in the right svcpack folder, it should get processed. To be safe, use 8.3 file name format.
m2gd - i see that you put the 958470 in sw1. Can I ask you if you are slipstreaming wmp9? Or just the codecs?

I'm slipstreaming wmp9.



Kiki- "My fix", it's not my fix as I found it on another post, does work with XP.