tommyp

I haven't tested hfcleanup with xp in a looooooooong time. Remember, it's an unsupported and will always remain unsupported. There's too many bugs with it, but it works great with 2k . You HAVE use a modified syssetup.dl_, maybe sys_oc.dll too. Without the syssetup.dl_ file (maybe the other one too), you WILL get setup errors and setup failures. Since you said you aren't using modified files, of course you'll get errors. The readme file says the same thing! Try recreating the modified syssetup.dll (and maybe sys_oc.dll) files, modifype them, cab them and place into replace\i386. Run the script without hfcleanup. If all installs OK, then retry with hfcleanup and select A, B or C to clean things up. If you can't get it to work, you're probably better off using nlite to reduce the source. It's easier and better to use than hfcleanup.

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

bfc - do you have the appropriate items needed in the HFTOOLS folder? There's info about it on the hfslip website. Refer to step 3 here.

Dumb Q, but does a SP3 exist for XP x64? Yea, I know it's a dumb Q but I have to ask. I'll see what I can do when I get some free time.

Typically a hfaao is a cab or 7z file. To replace files in side the cab or 7z files, you have to open it up with your favorite unpacking program, and then remove and replace the outdated binaries with new ones. Click save when your done and you have an updated cab file.

You can always repack the latest binaries in that cab file....

Make sure the right tools are in hftools and test it out in a vm. I can't say whether or not they work, in fact, I don't use HFAAO.

It's dead I suppose. I don't have a 64 bit OS or machine, so I'll never be able to test and tune. What kind of probs are you having with it? Maybe I can mod some code if needed.

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.

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?

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

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.

Here's what I do to keep my updates in sync - I keep my setups on a different drive. On patch Tuesday I visit microsoft's current hotfix page, read through the articles that affect my OS and then remove and replace what is required. The total time for me is about 4 minutes to keep things updated. Typically when doing that, I also update the hotfix update page that is in the stickied thread.

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.

That sounds cool, but I think it's best that an auto downloader program is a separate entity that can be pre-run before hfslip starts. More code = more possible bugs. At one point in time, jcarle got in touch with me about integrating his WUA with hfslip. I was unable to get his program to work so I left it alone. I think his program is dependant on some IE specific files which I have stripped off my OS because I do not use IE, I only need the IE core. I never persued looking up what files are actually needed for his program to work. The goal of hfslip is to just be minimalist commandline program, where one does not need to install dotnet framework.

Good find dudeman! Lemme test out renaming the 999s and see what happens.

mserbin - If you're up to the challenge, PM muppet and duke it out. I'd like for someone to maintain it and release it in a timely manner. I can't as I don't have enough time.

Thanks for the lines of code. I'll roll that into the next beta. Just remove the svcpack.in_. Leave the svcpack.dl_ alone. Also, open txtsetup.sif and look for svcpack.inf. Put as ; [semicolon] before that line. Rerun the script. Remember, these are test cases and you'll need to recopy the source folder once again if this doesn't work out well. IIRC, I've seen a few dell cd's that put some KB (i.e. hotfixes) into the i386 folder. You can probably delete them too, along with the apprioriate entry in txtsetup.sif.

In a SAMPLE run, try this. It appears your source is pre-modded with something.. Try this. Remove the svcpack folder in source, also remove the svcpack.in_ or svcpack.inf. This is a test case that's worth a shot. Oh, nobody else is having the prob you are having, or at least that's what the people in the beta thread are saying.

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

The latest beta slipstreams it, the change log says it too. I hope that muppet resumes the XP list updates soon.

I can't say whether or not it will work on a 64 bit machine. I know for sure it does work on a 32 bit one though. Try it out and report back.

Your host OS is unrecognized. Did you use an XP machine when you ran HFSLIP? You'll need an 2000, XP or 2003 to run hfslip. If you have another OS, then all bets are off. If you are indeed using 2k/xp/2003, please use the latest beta, it's more up to date than the one you are currently using. The beta is stickied on this forum. You may want to clean up your hotfixes too. For starters, you can place the 4.5 installer into HF now.

I'm not sure what files you are missing during copymode, but like I said, the files should reside in your sourcess\i386 folder. I'm afraid you'll have to be a little more specific on what files are not getting copied. I can't check that for you on this side of the screen. The inf files are copied right after the drive is partitioned. I'm unaware of cmd files that can be run at that point because the OS isn't installed at that point in time. I think it's probably a better idea to post your hfslip.log file.

If the "missing" file is indeed in the i386 folder and the filename is also part of txtsetup.sif, then I'm at a loss of words. Maybe try booting from the CD to install (i.e. clean installation), or reburning your CD. Other than that, I really can't help.