tommyp

I'm not sure what you are slipstreaming but here's some info. * If you are slipstreaming SP3, you need to have wbemoc.cab in hfcabs. * If you are using a SP3 source, create a folder called REPLACE\I386 alongside the hfslip cmd file. Place your wbomoc.in_ file inside that folder.

Bill - thanks for pointing this out. I had a little "operator error" when making my 2k updates earlier this week. You identified the 926122 error. The update will be posted shortly. The WMP updates are a little strange. Please tell me - are you slipstreaming WMP9? Or are you just slipstreaming the WMP9 codecs? This will help me try to tailor the script so it picks and chooses the right binaries. I just want to iron out the MSI stuff before I start tackling this prob. I'd rather do one fix at a time as my coding skills are rusty.

Thanks for the reports guys. I was unable to extract the MSI using a 2k box. I relied on a file extractor and saw the langspecific folder. Like you said, the folder is non-existent. Rev Q corrects both the non-existent missing folder and adds the zero before mui foldername. All should be good to go now. Are there any issues with the latest set of XP's WM hotfixes?

Thanks for the inputs guys. Rev M was ok, so I went back to rev M and re-rolled the changes in. Maybe I had a copy/paste error or accidentally hit something on the keyboard I shouldn't have. Anyway, I still left the rev M in the zip package. Hope this does the trick. Please post results (good, bad or indifferent). I like to see feedback. Once this is all well and good, I'll try tackling the WMP hotfix issues. The prob with that is that hfslip attempts to discover what WMP you are using and applies the appropriate hotfixes. The hotfix binaries come from inconsistant named files that seem to have no pattern. It's not as simple as you think, or maybe I just think too much.

WM hotfixes are troublesome. The microsoft software clowns don't seem to pack the WM hotfixes in the same manner, they like to rename folders with a unique naming scheme for no rhyme or reason. I'll have to trouble shoot these over the weekend.

gluon found a bug. Those two "move" lines should be deleted. It was remnants of a copy/paste I did. My bad. For those with the wpdshext file copy problem - if you used the same HF fileset and used rev M of the script, does the problem surface? Or is the prob a rev o only? If it's a rev M and rev N prob - please tell me what hotfix includes the wpdshext.* or wpdshextres.* files? Use winrar to extract them and examine. This would make life easier for me to troubleshoot. I glanced through the script and wpdshext.res is hardcoded as part of WMP11 installer. So I'll assume for now that it's a wmp11 hotfix. billtodd posted a message about WM hotfixes. MSFT changes their mind with WM hotfixes all the time. When extracted, they decide to use various foldernames instead of standardizing. I'll have to work on that too. Maybe all will get fixed this weekend if I feel up to it.

Sometimes a bad disk cluster makes bad files in an iso. But I can't read what the image says. I'm a puke who only can read english.

Billtodd - sometimes legitcheckcontrol is used to download special nonessential hotfixes/files that people think are critical and essential. Normally it would reside in the sys32 folder. But if you need it in a bind, just extract the cab to your desktop, register the dll, download your file, unregister the dll and delete the dll.

Muppet - if slipstreaming the msi v4.5, there are no other files to include other than the installer obviously. The new rev o slipstreams this now. You can thank Tomalak for testing out various betas and providing constructive criticism.

I found that some of the newer sysinternals freebee programs don't quite work well with 2k. The older ones just seem to work with 2k. Sometimes you just have to make due with the old versions. I suppose you could try a newer version, extract it to its own folder and run the exe from there. Or in other words, keep it out of win\sys32. Just a dumb idea to try I guess.

tomalak - thanks for your patience w/this. I saw how I could change to hex instead of decimal. Try the newer rev o. This should do the trick.

Yep, you're right, but it was the thought that counted. lol. New beta rev o posted. Added in gluon's contribution too.

gluon - Kudos for the code contribution. I'll roll in your request in in a day or two. I'd like to hear results from the installer v4.5 first though. I wanted to do any bugfixes and I can add your contribution at the same time.

Can you remove your custom explorer.exe and retest? If that still fails, can you test your source to see if the problem is there? It seems that you are using a VM to do your testing, so this should be relatively easy. First, rename your hfanswer.ini. Next, delete your sourcess. Rename your source folder to sourcess. Run hfslip and instead of typing I have read the instructions, type MAKEISO instead. It will make an bootable iso. After that, rename your sourcess to source. Run the VM using the newly created ISO and see if the problem lies in your source.

New beta is re-posted that slipstreams the Macrosoft Installer v4.5. Slipstreaming this is only possible using a XP OS and slipstreaming XP. Or in other words, you can't slipstream an XP source using a 2k host OS. Why? The installer is not extractable via a commandline switch in a 2000 host os. Please post constructive criticism. I have not tested this beta in an xp host os.

Most excellent contribution. Thanks for the inputs. I think I have a way to automate this. The prob I have to deal with is that the installer is not expandable via a commandline when the host OS is 2000. Edit - New beta is posted that hopefully slipstreams the 4.5 installer. It will ONLY work on an XP host machine that is slipstreaming XP.

a) What do those pictures say in english? B) Do you know what language of the IE6 cabs you downloaded? Your best bet is to make sure you got the language of your OS. Check out this link for IE6 cab language specific downloads. http://www.hfslip.org/hflists.html Please look at the details of the two msapsspc.dll & msnsspc.dll files in the sourcess\i386 folder. Check the what the date is. I checked mine out and it appears that msapsspc.dll is left unchanged (same date as my source\i386 folder). My sourcess does not have msnsspc.dll because it's not a required component. IIRC, msnsspc isn't updated via hfslip anyways. In troubleshooting mode, it makes things easier for me to help if you move some files elsewhere so they won't get parsed. The trick is to find the key file that "breaks" things. Like I said before, please remove all the files from HFGUIRUNONCE and HFSVCPACK. Also, it may be worthwhile to remove the HFSLIP_POST_SPEEDUP_V0.2.CMD from the hftools folder too. In HFCABS, please remove the MUAuth.cab, MuCatalogWebControl.cab, and muweb_site.cab files. You do not need to delete those files, just move them elsewhere so they don't get parsed.

I won't compare your list to see if it's all up to snuff. However, as I stated in my previous post, you need to place the correct dx9 hotfix there. You still have the directx7 hotfix named Windows2000-KB971633-x86-PTB.EXE. You want the dx9 hotfix instead. Place the Windows2000-DirectX9-KB971633-x86-xxx.exe there instead (the xxx is the language). You also had a problem with jscript/vbscript. I can assume that the culprit is js56nptb.exe. I'm not quite sure where you got that file from, but it's an oldie that I haven't seen in quite some time because it's outdated. You should really consider visiting the w2k hotfix thread, it's a stickied post in this forum. You have lots of non essential files in your HF folder. For example, there is only 3 IE6 hofixes required now, you have 10. There are 4 msxml hotfixes required now, you have 7. You also have a cab file in HF, which will be ignored. I also see a blast from the past - Windows2000-KB951698-v2-DX9-PTB.exe. That has been outdated for quite some time (it's a directx9 hotfix). For WMP9, you need to download it from MSFT directly. I'll bet that you need to clean up your nonsense hotfixes, and run barebones to verify WMP9 functions before you populate the HFGUIRUNONCE and HFSVCPACK folders. The problem may lie in one of the programs you are installing. Sometimes you just gotta walk before running.

Integrate or slipstream? KB971691 - a new version of jscript.dll (ver 5.6.0.8837) KB944338 - a new version of jscript.dll and vbscript.dll (both are 5.6.0.8835). KB971633 - is dependent on which directx you are using. Make sure you select the DX9 version if you are slipstreaming DX9. DX9 is a family of files, but the most important one I believe is quartz.dll. DX9 updates are 99% of the time just updates of quartz.dll. I ran hfslip the other day, jscript.dll is 5.6.0.8837, vbscript.dll is 5.6.0.8835 and quartz.dll is 6.5.1.911. These are the latest and greatest of the above listed files. So to answer your Q, I see that hfslip is doing the job just right over here. Perhaps the hotfixes you downloaded are just bad downloads from msft? Post your zipped hfslip.log if you are running into probs. FYI, the 5 in 6.5.1.xxx signifies dx9. If the 5 was replaced by a 1, (i.e. 6.1.9.xxx), it would signify DX7.

You would see that problem if you have IE6 hotfixes+IE6 cabs+fdv's fileset, which was what you did. From FDV's site, you have a choice for different IE's. You should not mix and match what you want to do. a) keep ie5 (use ie5 hotfixes) B) ie6 slipstream (use ie6 hotfixes *and* ie6 cabs) c) kill ie (use ie5 hotfixes and fdvfiles) On a sidenote, you do realize that explorer.exe has been replaced by a hotfix. Are you really sure you want to use hfexpert to replace it?

I extracted and checked out the msi v4.5 installer earlier this week. It's packed with every imaginable language! HFSLIP does not support this (neither does Nlite IIRC). Slipstreaming this is possible, but would be lots of work with no reward. I'd say that one possibility is to manually extract it, chose your language, rename the binaries and use the hfexpert directory option. Installation *could* fail though. I think that the windows xp setup routines kinda sorta needs the right msi binaries, but I could be wrong. I haven't tested the hfexpert msi method, but you are free to try it out. Getting back to the item #6. When I say repack, I mean to chose packing option A, B or C (i.e. do not create an SPX.CAB file). A typical SYS driver is located inside drivers.cab. So, after chosing options A, B or C, the newer driver will be put into the driver.cab file. As far as the WU goes, MSFT changes their mind on what registry info is present on the host OS for WU to work. I could have sworn that the CAB files or some hotfix added the necessary registry info into the install disk. If something needs to be hardcoded, I can add it in. Or perhaps it's just an outdated hotfix? I can't quite say what the answer is. I do know that msft likes to keep several versions of the same filename on their downloads available where only one of the files is the latest. Go figure. It could be as simple as a hyperlink pointing to an old version of an update on the hotfix page. If you want to try something fun, search for a filename on the MSFT website. You'd be surprised at the lack of info you find. I especially like it when the pop up thing shows up asking if it likes the info shown. I've found that to properly search microsoft, you have to use google. Bantering off. lol

pr0fessor - I'm not sure what you're getting at with making your own installers. Your best bet is to just download the dx9 hotfix from microsoft, put it in HF and call it a day For the english version, the filename is Windows2000-DirectX9-KB971633-x86-ENU.exe. After running hfslip, I get quartz.dll version 6.5.1.911. MMDominator88 - Please read the general FAQs on hfslip.org for how to set up the program.

pr0fessor - If you are slipstreaming DX9, then you need the appropriate DX9 version of the hotfix.

Thanks Bill. I'll roll those changes into the w2k list, expect it sometime after patch tuesday.

Don't count on updates at the moment. Typically spare time is spent away from the computer, and yes, real life is far better than sitting in front of a machine coding for free. Item 6 - This is an optional update. Typically optional updates aren't required. However, usually sys files are part of cab files. You can probably try choosing repacking of the cabs when running the program. Item 7 - The link you provide says "This is a Customer Preview Release. At the conclusion of this preview phase, the final version of the update will be released via Windows Update" in the overview of the download. Because it's a preview, and non-mandated hotfix, you'll be on your own playing with microsoft alphaware. Once the article/download is mature enough to warrant a "critical" status, then we'll play things by ear and/or fix the script. I do not see the point of making hfslip work for microsoft alphaware at this point in time. In my opinion, just because microsoft offers a software, does not automatically mean it is functional and you are mandated to have it installed. Item 9 - do you have modifype in the hftools directory? Item 10 - I do not use windowsupdate & I haven't used it in many years. There are commandline alternates that provide the same info in a fraction of the amount of time. Please post what registry fixes and/or file fixes should be in place for MU to work. Item 11 - Usually when unpacking troublesome hotfixes, the binaries are renamed to something else when installed into the OS. You can try using a program that examines what files are replaced and what registry additions are put in place when a program is installed. From there, you can see what files are replaced. I don't have the program name handy, but will post the program name it if you are interested in troubleshooting. edit - the free software is called Installrite. You can see what files are swapped/replaced and what registry entries are created/removed. From the sounds of things, it sounds like the non-essential msft bloatware needs hardcoded fixes.