Here's the latest.

Slipstreaming: This version slipstreams and applies update INFs a bit differently than the past. It should help out the network installation people a bit more. It also corrects some XP related hotfix issues that came up.

Driver repacking: I took some advice from Oleg & FDV about driver repacking. This version repacks drivers and leaves no remnant SP#.cab folders in the slipstreamed source.

MORE driver repacking. Oleg sent me some great reading material. File copying during text mode should be faster now.

File repacking: Files are makecab'd a bit differently now. I'm not sure if it saves time making the cabs or saves time copying files during installation.

Final installation: HFSLIP only leaves one residual file on your drive after installing the slipstreamed source.

For the people who cannot live life with a pop-up window during the installation of windows, create a folder alongside HFSLIP called HFEXPERT. Inside the HFEXPERT folder, create a folder called SYSTEM32. Inside that folder, place cmdow.exe.


Additions:
HFTOOLS: This is the new placeholder for HFSLIP related tools.
1) MSI Extractor tool
2) modifype.exe
3) cdimage.exe and boot.img (OPTIONAL! Put these files here if you want HFSLIP to generate an ISO image for you.)
4) For those running an old version of HFSLIP, there is no need to rename your MSIEXT folder. HFSLIP renames it for you.
5) Future iterations of HFSLIP will use HFTOOLS for any additions/tools needed by HFSLIP.

Users should also keep in mind that other items can be slipstreamed/replaced during the HFSLIP process using the HFEXPERT folder. Other items include slipstreamed codecs, alternate applications, additional system32 files, additional system files and additional %windir% files.

Any tips/corrections/comments appreciated.


Thanks for testing guys... beta is out, see first post.

You look at the file size...and then have to reread what it does, then you look at the file size again, and just shake your head and say Daaaaamn.

Hopefully can give it a run thru soon, after I finish reorganizing these damned Harddrives (maybe finish is too strong of a word, halfazzedly organized might be more doable).

OK, I wont be able to fully test this until the morning since I am doing this remotely at the moment. I have run your process, now all that's left is to install XP.

couple of questions...

1. You talk about letting HFSLIP create ISO automatically. I put the CDIMAGE files in HFTOOLS, but never saw an ISO created. Is that not implemented yet?

2. When using HFEXPERT to add things to "System32", can you add directories, or just files? (I added a directory, but don't see it anywhere in the resulting source)

This will be great if this does work for my "network" based install. Still attempting to get CD based working correctly.

Hello tommyp,

I replaced my hotfix-integrator stuff with HFSLIP, worked ok. Now replaced it with this beta, and I have some comments to add:

First I will provide my background on fixes and building steps.

1) Fixes I'm trying to slipstream (placed in HF):


ESN is code language of Spanish. I'm doing a modular builder, so I split fixes for ENU and ESN.

Language Neutral Fixes (for all the languages):


First I start from a XPSP1 CD, slipstream SP2 and then copy fixes and move I386 to SOURCES for HFSLIP processing.

Later, to the processed I386, I automatically perform HDAudio (KB888111) integration (later could post how I solved this, no insert disk dialog & sound still work after reboots).

Added automatically custom drivers (pyron's method) and then created the ISO.

2) After installation, go to Windows Update and showed only two critical updates:
KB887472 & KB890046

Even that both are included in the HF directory.

besides that, everything worked good. Later will try to include specific updates related to Firewire IEEE 1394b and MPEG2 in Adobe Premiere Pro, which are common on my env.

A suggestion for the Add/Remove programs in control panel:
Your HFSLIP item shows a "Change/Remove" button, the code in hfslip_51024.cmd starting at line 1990.
Adding the following lines will remove it, like the integrated hotfixes from the traditional method (not yours).



Don't know how to express dword values in the INF, but adding this remove the totally useless button in this item.

So far, this beta perform better than before and smaller, ~20MB of total (566MB total compared with previous version, 587MB) and ~120MB smaller than traditional hotfix integration (/integrate).

Thank you for this wonderful script/tool!!!

Later,

Zero

@ NtegrA
HFEXPERT Folder, will only (by default)
Use/Add the following directories (if placed into HFEXPERT):
* Slipstream files to a %Windir%\GRE and %Windir%\BIN folders

Additionally it will slip the following files in HFEXPERT\*.*
\CODECS\*
\SYSTEM32\*
\SYSTEM\*
\WIN\*
\APPREPLACEMENT\*

You will need to modify the script to make it add other directories, shouldn't be too hard...

@NtegrA - If you want the ISO created, you need both cdimage.exe and the boot.img files. It won't work with one of them missing. I had a typo in the first thread, it should have been boot.img and not boot.bin.

@zerospeed - You said you are missing KB887472. In your HF listing, you have WindowsXP-KB887742-x86-ESN.exe listed but not 887472. Thanks for reporting KB890046. I'll update the script later today. Also about the add/remove software in the control panel. That was done intentionally.

@Crash&Burn - HFSLIP intentionally does not create the HFEXPERT folder. It was made to discover by those who visit FDV's site. The HFEXPERT folders listed are the only ones supported by HFSLIP. In fact, there will be some other *surprises* for those who read the instructions in a few weeks. The other surprises will require some reading by the user.

Please keep the results coming...

Anybody tried on a real computer? It asks for a SP4 CD now... Maybe merging drivers was not a good thing
Trying to locate the problem.

Well so long as its not a Microsoft suprise, like, use UR1.v1 and you now have no harddrives

@ Oleg II, I usually Nlite the source and remove every single driver I have MFG Drivers for any of my hardware that needs one, with periodic checks to see if any have been updated. While PnP in theory is good when an OS is first released...not so much afterwards, 5 years later and MS doesn't re-release an updated drivers.cab, if you run solely on PnP you're using drivers that are 5 years old, and possibly buggy & provided by microsoft.

Oops... Seems to be a problem with my computer - older versions of HFSLIP have the same effect. Experimenting...

@Crash&Burn - Thanks, I decided to create the folder later during the install.




I actually have both files in there. I did not copy the .ini that I was using. (just checked again, I have cdimagegui.exe in there [OOOPS]

Now when I do my install, File copy process is crying about problems with: sp2.cab, legitcheckcontrol.dll,gwfspidgen.dll.

After first reboot, copy problems with: spmsg.dll, spupdsvc.exe, wga1.dll, wga2.dll

Copy process slowed WAY down as well around 54% or so. Still copying files at 64%. Have to go to a meeting before finishing, but wanted to let you know what was going on. I will attach the error and wu once install is complete.

Thanks

btw, you can ignore the HFEXPERT part (unless that is causing issues). I am trying again now that I have the cdimage.exe and deleted the HFEXPERT. (just in case)

While using old drivers on new hardware is not always the best way to do things, or the fastest, stability is hardly the issue. Any hardware that has drivers on the XP CD that requires an update for stability reasons will have one available via Windows Update. As for using the drivers on a 4 year old computer with a 4 year old OS, it's not like bugs suddenly *appear*...

Now, if you have updated drivers available, trying them out isn't always a bad idea. I usually only recommend clients that a driver upgrade is necessary when they run across a specific, repeatable issue that is fixed by the driver upgrade.

Results:

I made the CD and performed the install. I must admit, I was surprised (pleasantly) not to see any errors during the copy process (or anywhere for that matter). I guess doing the install from network can't handle the LFNs such as LegitCheckControl.....

I went to Windows Update, it did it's validation check (without downloading any files), then showed me 1 update needed to be installed (KB887472). NOT BAD! I attached my files below. Is the wu.txt normal or should it be blank?

I am going to try WIN PE and see if that gets around dos's shortcomings.

Excellent work.

@NtegrA - About the LegitCheckControl files. You are the first to report errors on this. You need to download the proper legitcheckcontrol.cab file. Please refer to FDV's site for a download link. Please place the correct legitcheckcontrol.cab file in HFCABS and report back. Also, just as the hfslip.zip file contents say, HFSLIP is designed for people who install using a CD. Using it not the way it was designed for will cause some problems. Lastly, be sure that you have WindowsXP-KB887472-x86-enu.exe in your HF folder and not WindowsXP-KB887472-x86-SP1-ENU.exe. You only need the SP1 version if you are running XPSP1.



I did some homework and cleaned up a few things.
a. There shouldn't be any CAT files in the sourcess\i386.
b. Fixed the SP# cabs missing during file copy stage.
c. Fixed another XP related hotfix (a non-English issue).
d. Addressed NtegrA's concern for file copying.
e. Please don't say that HFSLIP didn't cab everything in your sourcess\i386 folder. The files that are un-cabbed in the source remain un-cabbed in the sourcess. For example, with XP, there is exactly 111 DLL files in my source\i386. My sourcess\i386 folder also has 111 DLL files.
f. Also, please no comments about small txt files in the sourcess. Using the same case as above, there are 5 txt files in my source\i386 and 5 txt files in my sourcess\i386. I tried deleting them many versions ago with HFSLIP and people complained about copy errors. I'm not going that route again.
g. It is not HFSLIP's intent to strip files away.
h. LegitCheckControl may appear to not be slipstreamed if you don't apply the registry "correction" during installation or after installation. YOU need to apply the reg tweak to make it happen, I don't do it for you (yet).



I NEED YOUR HELP if you want me to slipstream and fix things correctly. I don't have time to test all the variations of installations.


There are two versions of HFSLIP. Each version packs binaries differently, but the slipstreaming process is exactly the same. I need to know if "Version A" copies faster or if "Version B" copies faster. This will settle something people have nagged me about for a while. I'll let you guys decide which is better and I'll go with the version that copies faster.

Ah! That was my careless again! Don't even want to talk about it (I deleted SP4 mark in the root of sourcess folder

Works great!

Sorry, I missed something? There are two versions? This one seems fast but I should compare

@TommyP

Can you explain a little bit further on how this beta HFSLIP is supposed to be faster?

Also, here's a suggestion: unpacking Windows Update Rollup on Win2k takes forever. How about if HFSLIP processed an already unpacked Update Rollup 1 v2?

@ tommyp
Have you tried xxcopy? (Freeware for noncommercial use).
And XXcopy in Batchfiles in their reference guides.

Not sure if it's any faster or not, but it's very enhanced, and allows for much cleaner batchfiles too.

The two versions are exactly the same EXCEPT one version makecab's the new binaries using the regular makecab function. The other version makecab's the new binaries with the makecab and the CompressionType=LZX and other switches. People continually tell me that the CompressionType=LZX type is supposed to make the file copy stage faster, but I can't confirm and don't have time to test it out. So, I'll let the community judge which is better and I'll use the better method in future HFSLIPs. As far as execution time of HFSLIP, one may be faster, but I can't confirm that either.

I don't plan on having an unpacked hotfix folder, it will add too many other files to maintain if re-running HFSLIP. Typically what I do when running hfslip is to fire it up and come back 15 minutes later. If you want a significant speed improvement, disable your virus software.

I have also tried out xxcopy. It's a great program. However, from what I remember, if you save the executable somewhere else, reload your system, and then launch the executable again, it complains that you ran out of time using the program. I don't want to deal with that. It's hard enough to get people to read the directions This is why I went with what utilities are already available on someone's PC.

I tested HFSLIP_51025B.cmd in a VM. It's everything alright now.
thank You for your BIG WORK


dziubek

@dziubek - Thanks for your help with the non-English versions. I appreciate your time and feedback!


@ALL - I uploaded the last of the betas... It has the HFEXPERT\DRIVER folder addition, as well as selectable driver.cab packing. Thanks to Oleg for finding me the right info for this!!! Txtmode copy for XP went from 8 minutes to 3 using option B for packing. Your mileage may vary. Pleae post any last minute items before I send this to FDV for hosting.
Thanks
TP

@TommyP, I'm presuming that step 4 above means:

1) put MSICabExtract.exe into C:\HFSLIP\HFEXPERT\HFTOOLS and
2) delete the folder C:\HFSLIP\MSIEXT

Also, the cmdow.exe file you refer to in your original post, you're referring to this right?

http://www.commandline.co.uk/cmdow/

Please correct me if I'm wrong.

Also, tried downloading HFSLIP last night from FDV's website and it was older version. Let us know if you've included Yzowl's ASPI update to HFSLIP in the latest version also.

Every time I think HFSLIP can't get better, it does!

@saugatak - The beta hfslip automatically renames your MSIEXC folder to HFTOOLS. It's up to you to fill it up. Depending on what you want to slipstream, HFSLIP will prompt you that you need a tool. Yes, the cmdow link you talk about is correct. Place the exe file into your HFEXPERT\SYSTEM32 folder (you need to create the HFEXPERT folder). The hfslip file talked about in this thread is on the first post of this thread. The file posted has Yzowl's ASPI update too (along with some other things).

@TommyP

1) Once I choose driver compression:A then during the installation I get an error message - blue screen:""
ERROR THe installer cannot access the CD drive containing the XP's installable files
I may choose:
enter - restart and then I get no NTLDR file
F3 - end

2) if I choose driver compression B --->> I get no errors during the installation
I haven't changed anything in the way of installation for 50 tries.

p.s i used HFSLIP_51026.cmd

dziubek

dziubek
Redownload the file, it's from October 27 now.

Use the latest version, HFSLIP_51027.cmd.

@tommyp
Hi,

In your UPDATE LOG inside the HFSLIP you mention
for this to fully work you also need to modify the FOR statement in the creations of the HFSLIP.CMD file in the :UPDATE_INIT section
in this sentence

a custom path must be declared to allow a multiboot image to work, by example

...this custom path could be an enviroment variable, so if someone wants to create 2 or 3 CD images, just especify this path in each HFSLIP_XXXX.CMD run and every image could be created with the correct path inside the CMD file.

Will try this new version... excelent work

Also, I'm trying to integrate components inside the sourcess for applications developed on VBasic 6.0, SQL Server 2000 and Crystal Reports, so the HFEXPERT folder has been my saviour, i could register OCX components for VB, Crystal.. but SQL Server's SQL-DMO requiries (at least in the documentation) that 2 Resources files are located inside [WinDir]\System32\Resources\XXXX (where XXXX is the country languaje code 1033 for English U.S.), so custom folders have to be created when installing the files from the CD...
I made a little script which read the DIRECTORIES inside of the HFEXPERT folder and add them in the [WinntDirectories] but have one problem, don't know how to increment or decrement the Folder number in the statement in Bold



I know that this is very specific for my case, but maybe other people would need to create custom folder inside WinDir to similar purposes, and your tool is in the right way for doing this, there are aplication that requiries specific path to be created from some point inside WinDir...

...ahh... could be possible that you add legacy support in your TOOL in HFEXPERT section to include windows Help Folder ([WinntDirectories] #21)

And, as usual some "off the topic" question
Have anybody succefull installed MDAC in Win2k calling it from inside SVCPACK.INF after slipstreaming the sourcess with HFSLIP, i'm trying with 2.8 SP1 version, tried with the original package, repacked with IExpress to be silent, and it doesn't install... no error, will try later to run it with parametter to see interface and watch any error that may occur...

@pain, thanks for the great feedback. I'll see what I can do to incorporate your ideas. I know it's all possible, even with the incrementing/decrementing. I just have to think things out to make the hfexpert folder a little easier to use and create. However, I will keep HFSLIP from automatically generating HFEXPERT. I want this to be a hidden gem. And before you ask, there are other hidden gems in there already that remain undocumented.

@tommy
Hi..
I made an small modification on the little script, but for some reason the Directory number increase is not working, I started a new CMD prompt with /V:ON /E:ON paraments and nothing, even enable DelayedExpansion on the registry on LOCAL_MACHINE and still doesn't work..., take a look, maybe you could see if it and error on my script or and error on my computer


Also... I tested the new version of your TOOL with Win2K Pro, and when I go trough WU it tells me that the UpdateRollup is not installed when in fact it is... in your previous version (HFSLIP_51017) WU was happy about it, didn't display any errors..., I read in the http://www.vorck.com site about some problem with this file halmacpi.dll, actually you delete the file when you extract it in your script in the :HFRU section... in both script versions, but the HFSLIP_51017 version works OK, new version not...

I attached my reports...

Wow, wow

I figured out the problem with the incrementing thing in the directories... you have to enable DelayedExpansion for the command prompt to work, by default is disabled on Win2K, the script would look like this, pay attention on the bold enviroment, you no longer use "%", you use "!"


... that would take care of the directory thing in HFEXPERT folder... you could put any directory you want inside WinDir, one challenge would be how make directory recursion...
by example how to create this properly on "WinDirectories"

...this must have to be traduced on this on TXTSETUP.SIF [WinDirectories] entry

...of course, this would have to include DIR1 only if it have file inside it
i don't have any idea about it...

I used HFSLIP_51027.cmd and I chose driver compression:A--->> I get no errors during the installation on VM


BUT I get an error during real installation to hard drive - blue screen:



http://support.microsoft.com/default.aspx?...b;en-us;Q314474
http://support.microsoft.com/?kbid=101096&sd=RMVP


P.S When I install alone WindowsXP-KB885836-x86-PLK my wu.txt looks that:WU2.txt


dziubek

You need to increment the DIRNUMBER. Put this after your FOR line:
SET /A DIRNUMBER=!DIRNUMBER! + 1. If the !'s don't do the trick, try %'s.

Tell you what, I really don't want to craft this piece of the puzzle, but if you would like additional files/folder copied over, please generate a "plug-in" for hfslip and I'll incorporate it.

As far as the W2K rollup goes. See if this does the trick. Rename the SYSTEM32\Windows Media\Server\NSCM.EXE to NSM.EXE. I thought I found that as a typo the other day and I corrected it, see if that file rename does the trick. Report back. I don't use WU, so I'll need your help with that.

@tommyp
thank tommy for the ! alternative, it worked...
ok.. I figured out how to make directory recursion and read the contents of files... increment the directory number and everything... for the directory recursion i needed an extra tool, called munge found on
this page, it allow you to replace strings inside files, i put on HFTOOLS folder.., it needed cause when you issue a DIR command with a /S switch it prints the absolute path of the directories it founds.. so, here we are working with relative paths, so they have to be cutted to only include the relative path..

Sometimes, there are aplications (like SQL Server SQL-DMO) which requiries that certain files to be present within a folder structure hardcoded inside the application to work properly, and sometimes this structure have empty folders before reaching the folders with the actual files needed by the aplication. So, we must exclude those empty folders, and Windows Setup recreates the empty folders when it installs the files.
To skip the folders not containing files (just subfolders), I had to put a DUMMY.FIL inside them, 'cause I couldn't figure out how to exclude empty folders in the final FOR inside the batch, so I created DUMMY.FIL file inside them and removed those folders with DUMMY files from the paths used in final list which will run the final FOR statement.
One usefull thing with this it's that you can also put folders inside the system folders used by windows, and the script will include it the same way you create 'em, to test it try puting a folder inside system32 and you will see
in TXTSETUP.SIF

here's the script



Hope, this helps other people like me...

No, that didn't do the trick, i renamed the file and run WU and still tells me that Update rollup is not installed.

@pnkiller78 - Try swapping the halmacpi.dll from the rollup back into the system32 folder. Test that out. It was a buggy dll that won't make your PC happy, but will make WU happy. Thanks for the scripting, I'll see if it all works, and if it does, I'll incorporate it. Thanks for the help!

@dziubek - Are you getting the copy error during the txtmode copy stage? Are you installing from a CD? I just did an english version here on a real box and it works fine. Are you installing anything else to cause this? Check the version number of that dll in the sourcess folder. Google for the version number. Oh and see if it's a QFE type.

@ pnkiller78 & tommyp
Based upon what I understood your needs to be, the following should allow you to add directories to HFEXPERT, update both dosnet.inf and txtsetup.sif accordingly and add the directories to the WORK\I386E directory. Tommy would just need to ensure that the folders are integrated into I386 okay.
P.S. - no third party tools are required@ tommyp
just a note to say that in line 3 I have included drivers and help in the findstr command, for pnkiller78s benefit only.

@Yzöwl

Wow...
That script really kick my **s
I tested and it does the job, just one thing: AFAIK the files doesn't need to be copied to the WORK\I386E folder along with the folder structure, you just need to copy the files plain inside WORK\I386E, cause after that they are compressed by makecab and incoporated into the SOURCESS\I386.
After that, during Windows Setup the structure is recreated inside WinNT isntallation directory using the directory numbers information stored in txtsetup.sif (somebody correct my if I'm wrong); apart of that is great, by the way: I didn't know that cmd prompt can do that...

Well, i suppose that if tommy wants to include something it will be yours, mine it more simple and easy to understand for begginers (like me), but yours is more pro... it doesn't need any dummy files nor third party tools.. great.

By the way, where do you think I can read a more professional doc about Command prompt scripting for Windows..., i would really want to learn...

Thank you.

Here's one I found, Rob van der Woude's Scripting Pages, that seemed to be better than any I'd seen before... Click on Batch files on the left page index.

I added the directories for the simple reason that someone is bound to add sufficient additional folders plus subfolders to have matching filenames. At that point overwrites or the lack of will cause problems.

The ideal, as I suggested in my last post would be to integrate the folders structure into I386 instead of just individual files.

I am always asked about resources for learning, however other than whatever you can find on Google, everything I do is trial and error type learning.

OK, that's ok, but recreating that folder structure in the final SOURCESS\I386 would make that installation directory look a little overcharged... i see why you add the folder entries on DOSNET.INF [Directories] section, to allow WinSetup find the files in that folder structure inside I386 at install time.
I would prefer just to compress the files and put'em on I386 using d1, filename.fil in DOSNET.INF, less cleaner I386 folder..
for this to you only have to modify the line 31 where you xcopy the files along with the structure to just copy the files.. maybe a simple copy "%DirName%" "WORK\I386E" /y>nul

Does the .inf have entries to disable uneeded services? Maybe a few other reg tweaks too.

@Yzöwl - You da man. That's the coolest thing I've seen. I'm in the middle of integrating it into HFS. I think I like it when files are all crammed into one place. So I modded it a bit so it's all packed into i386. I'll see if there is a need to put it into additional folders in i386 later. I would prefer to have it all packed into one place. Remember, the intent of HFSLIP isn't to make a big source and to slipstream programs. But if the need arises, maybe I'll have to change my tune. Again, thanks Yzöwl, you create the coolest scripts.

I'm running into trouble finalizing Yzöwl's code (with some mods to HFSLIPify it). Can someone help me?

Let's say your file/folder structure is this:
SOURCESS\I386\FOLDER1
SOURCESS\I386\FOLDER1\FILENAME1.FIL
SOURCESS\I386\FOLDER2
SOURCESS\I386\FOLDER2\FILENAME2.FIL

What lines does txtsetup.sif need so that it finds the files during the file copy stage? The code below doesn't do it. What am I missing?

Txtsetup.sif is only used to place files, not find them. The files added to it are only for inclusion into the %SYSTEMROOT% structure. i.e. all locations shown in [WinntDirectories] are relative to the location within %SYSTEMROOT% where the relevant files in [SourceDisksFiles] will be copied.

I was under the impression that the files were all added using the [Files] and [Directories] sections of Dosnet.inf. This would tell the locations on the CD for the first phase of the unattended file copy process to a temporary location. At that point the Txtsetup file would be used to place the files in their final location from that temporary location.

I plan on having two versions of HFEXPERT in the future. One is to just slipstream it along with the source (which works now). With this method, anything placed there will overwrite any existing binaries on a CD. But I also plan on having anther HFEXPERT structure where you place files/folders a different HFEXPERT subfolder. With the latter method, the folders you create will be additonal folders inside the I386 folder, so no binaries will overwrite. There may be some overlap there, but tinkering with txtsetup.sif is pretty limited. Anyway, with the code I presented in the post above, the files cannot be found on the cd. There must be something to put between the commas so the setup can find the files that are nested inside folders inside the i386 folder. I think this could be cool because you would be able to slipstream firefox and rip out IE. A perfect addition to the HFEXPERT hidden utility.

Well, if the files filename1.fi_ and filename2.fi_ are in the <SourceDrive>:\I386 folder during setup it will work fine, but if they are located in <SourceDrive>:\I386\FOLDER1 and <SourceDrive>:\I386\FOLDER2 respectily it will not work, at least that FOLDER1 and FOLDER2 are declared in DOSNET.INF like this


I think that there's an error on Yzöwl's script, not completely sure, but in DOSNET.INF, under [Directories], d1 = \ refers to the <SourceDrive>:\I386 folder, the files are actually there, that's why in the [Files] section you only especify the filename, in Yzöwl's script he creates the DOSNET.INF like this

I think that could be the problem because WinSetup would think that FILENAME1.FIL is in <SourceDrive>:\I386\I386\FOLDER1

Personally i don't like the idea of recreating the needed folder structure under the <SourceDrive>:\I386 folder. Well imagine this situation.
You put this files under you HFEXPERT\SYSTEM32 folder...
HFEXPERT\SYSTEM32\MyDir\DllVer.dll
HFEXPERT\SYSTEM32\YourDir\DllVer.dll
and suppose that the file in <MyDir> is a newer version that the same file in <YourDir>, when those files get installed there would be 2 version of the same DLL in the system, one being older that another... I don't know if that could create problem in WinRegistry, but for me would be better just put everything you need under <SourceDrive>:\I386, there will be no need to alter DOSNET.INF with extra source folder in the [Directories] section, just throw the files with d1, FILENAME1.FIL, there would be a more clean <SourceDrive>:\I386 folder, not those strange directories scatered all over the place... and the need structure would be recreated by TXTSETUP.SIF
as far as I know, somebody correct if I'm wrong, one of the functions of DOSNET.INF is to copy the source files on the hard disk during the textmode part of windows setup, I think is uses a folde called $WINNT$.$LS$ or something like that; after that, the final location of those files in created by the [WinntDirectories] section on TXTSETUP.SIF. So, i think that cosmetically is unncessary to recreate the custom folder structure under the sources media.

The logic in my script is just to throw the files in WORK\I386E, then let HFSLIP compress them and add them at the end of DOSNET.INF using d1, FILANEMES.FIL, then I insert the final (and so needed) folder structure in [WinntDirectories] section in TXTSETUP.SIF along with their proper filenames declarations in then [SourceDiskFiles] section.
That way, you just end with one version of any file, the source files stay in <SourceDrive>:\I386, and the ultimate goal of all this is reached succefull.

Oh, by the way, i tested the halmacpi.dll thing, and it didn't work too, this file, I think, it's the Hardware abstraction layer (HAL.DLL) that end in system32... but this particular file (halmacpi.dll) is for multiprocessor systems kernel... that why I think that have nothing to do with my problem, cause my test system is an UniProccesor system, the proper hal.dll I think it's halaacpi.dll, cause in fact TXTSETUP.SIF rename the file properly acording to the detected system during installation, you can check out this in [Hal] section in TXTSETUP.SIF... I suppose the during the hardware detection WinSetup detect the type of system and TXTSETUP.SIF install the proper file, in my case I'm testing on "ACPI Uniprocesor PC", so setup uses the halaacpi.dll, rename it to hal.dll an install it... I compared the expanded halaacpi.dl_ that it's my in my sourcess media against my installed and running C:\winnt\system32\hal.dll and both files are the same..., that why I think that halmacpi.dll got nothing to do with the UpdateRollup problem in WU... and another clue it that in your previous HFSLIP version HFSLIP_51017 there were no problem with WU... everything worked like a charm... also, in this version there are some application which I was testing to install via a CMD file launched in SVCPACK.INF that now doesn't install, these program (Paint Shop Pro 9, and TextPad 4.7.3) I install them using MSI files and now if use the /log switch to see what happened they abort with this error in the log
DEBUG: Error 2103 : Coudl not resolve path for shell folder 26
MSI (s) (28:2C) Product JASC Paint Shop Pro 9 -- Internal error 2103, 26

@pain, thanks for the info. About the windowsrollup. Are you still doing the network installation? Remember, HFSLIP is for a CD installation. With a CD install, all the files are there as are the registry changes. As far as the HFEXPERT thing goes, I don't plan on going to wild with dosnet.inf and HFEXPERT. Dosnet.inf isn't needed for a CD install.

@tommy...
No, now i'm only trying Cd install, clean Cd install and multiboot Cd install... actually it's the same..., just that the <CD Source Media Root> is moved from <DriveLetter:\> to <DriveLetter:\multiboot_path\> , the diference is actually the SetupSourcePath = '\' which is changed to SetupSourcePath = '\CUSTOM_PATH\'

Well, hope everything helps, cuase HFSLIP rocks
By the way, tommy, you think that maybe someday in the future, you can consider integrating MDAC (more recent version)... that would be totally cool... cause in fact MDAC 2.5 SP3 it's allready on win2k sp4...; i resolved my previous problem by installing in my CMD custom application file and calling RunOnceEx proccess inmediatly so all registering scheduled by MDAC are performed right after the install, after all, the mdac files are not used in that stage of installation, so it not hurts to register everything there.., hotfix it's not installed even if it run successfull (checked the logs), maybe some WFP issue (not sure though).

I don't know what you mean about that, in my (XP) dosnet.inf file the files are relative to the root of the CD \My folders as intended would be correctly identified in I386.

However as tommyp stated it appears that during the file copy process messages stating that the said files cannot be found are displayed. This suggests that dosnet.inf cannot identify the folders, (certainly not inside i386 after tests to date).

For now I have decided to ignore copying the folders over, however, if you don't overdo it, (possibly replicating filenames), you can still with the altered script below, create the file /folder structure you require to have inside %WINDIR% on your installed system by placing the same structure in your \HFSLIP\HFEXPERT directory.

In my current HFSLIP version 51017, I would add the red line as shownThen I would add this after the HFEBIN stuffHope this helps for now, it should keep the I386 structure clean, but also have the benefit of not mixing many files directly in the %WINDIR% on the installed system.

I took a look at the guts of the MDAC installer (the 2.8 one). It's loaded with lots of garbage that defeats the purpose of my lean machine (I rip MDAC out because I don't use it). However, it is possible to install it via svcpack and a cmdline. Perhaps I'll do a little mod to the script so it installs that way. Also, on the mutiboot cd, can you try installing it the old-fashioned way with one OS on the cd and see if it works. I don't want to chase my tail on this issue. Everything works fine on my side, so I'm not sure what I'm missing. Last thing, to check for your updates, can you run the MS Baseline Analyzer? That tells tons more than a visit to the windersupdate site.

Yeah, you are right, in winxp d1 = \I386, I was using Win2K, and its dosnet.inf file has d1 = \ maybe that was the problem, didn't know that you was using xp for building your script..



I tested that way, old fashioned way, just to be completily sure, the I386 folder on CD Root, and the same result... I think will try using ms baseline... I have never used but I think it will not be too much challenge
Another idea I was having, was to binary compare every UpdateRollup file againts the ones that are on the running system, to see which one differs and maybe if something is missing...

For MDAC... I used the same (2.8 alone, no SP1 or SP2), and install fine via cmdline... I resolved the Q832483 thing, by decompressing ENU_Q832483_MDAC_X86.exe file, and recabing using IExpress only the 4 files actually needed by my system.

telling IExpress to run the INF as the default command, everything worked fine... the file stayed there...
my cmd file like this


Will post what i found...

****, this is a high level conversation!

@TommyP, you rip out MDAC? Don't you need ODBC and/or OLE at all?