[tommyp]

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

[Glowy]

chtom, on Oct 28 2009, 09:29 AM, said:

Hi, I have test this beta S (October 20, 2009).
It's work with XP French : SP3 + IE8 + Last DirectX + WMP11.
after reboot, I need install only :
- Windows Genuine Advantage Validation Tool (KB892130) when access "Windows Update"
- Windows Genuine Advantage (KB905474) when access "Windows Update"

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

[chtom]

tommyp, on Oct 28 2009, 10:47 AM, said:

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

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.

Glowy, on Oct 29 2009, 09:20 AM, said:

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

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 !

[Glowy]

chtom, on Oct 29 2009, 11:01 AM, said:

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/

[chtom]

Glowy, on Oct 29 2009, 12:39 PM, said:

chtom, on Oct 29 2009, 11:01 AM, said:

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

[jvidal]

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.

[Glowy]

jvidal, on Oct 30 2009, 07:26 AM, said:

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.

[tommyp]

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

[Geej]

tommyp, on Oct 30 2009, 05:30 PM, said:

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

[wela]

No Problems here with kb973525.

[billtodd]

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

[mserbin]

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?

[tommyp]

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.

This post has been edited by tommyp: 31 October 2009 - 04:58 AM

[billtodd]

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

[mserbin]

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!

[gluon]

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.

[tommyp]

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.

[gluon]

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.

[tommyp]

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

[gluon]

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.