noisehole

take a look at the [setupData] and [DiskSpaceRequirements] sections in txtsetup.sif, sounds like there're the values you've been looking for regards

Installing Vista Beta 1 (x86) without DVD media i installed x64 version using that method and it worked like a charm, but instead of /s i used /e /c as xcopy switches since it failed on ntuser.dat regards

i started getting into this "setup modding business" when i found tommyp's script. it just works and he did a great job, but as a developer i just had to try the inf-parsing approch. the parsing itself works pretty well atm, im just not 100% sure how to integrate those results into the installation. eg you are suggesting to add my inf to syssetup.inf instead of sysoc.inf. ive no idea when exactly those files are executed by the installation but thanks for the tip, ill have a try. the multi-os hotfixes arent the problem, here's a snippet from the log analyzing IE6.0sp1-KB883939-Windows-2000-XP-x86-ENU.exe detected hft2 6.1.0022.4 extracting... branched hf, using update\update_W2K.inf identified as Windows 2000 Hotfix - KB883939, enqueued with id 883939 what makes me doubtful are these things: from the ur1 inf [ProductInstall.Conditional] FileCondition= MDAC2X53X6310.Condition [MDAC2X53X6310.Condition] InstallFromSection=MDAC.Install.Section Operation=CustomFunction,UpdCustom.dll, UpdInstallMdac2X53X6310, MDAC2X53X6310.Section CopyFlags=SP_COPY_NEWER_OR_SAME | SP_COPY_REPLACEONLY it calling a function from a dll thats included in the hotfix, and i guess i can just forget about doing so because it returns results based on the system it is executed on another issue are all those different inf sections. is the hotfix exe reading all infsection and decides which of them to execute or is it looking for hardcoded ones? im currently taking the 2nd approch with these strings (and different suffixes) ProductInstall.DontDelayUntilReboot ProductInstall.CopyFilesAlways ProductInstall ProductInstall.128BitFiles ProductInstall.ReplaceFilesIfExist and as a result i get some fileoperations more than once. from the log updating qmgr.dll from v6.2.3630.2522 to v6.6.2600.1596 ERROR: source file does not exist: qmgr.dll this file should be present in 2 locations. i dont know how to handle that (do i have 1 fileop too much?) regards

well the gui sucks big time, so you basically only got the log as memo (rightclick that to copy contents to clipboard) and a "go" button

oh, sfc is disabled at this stage. i dont wanna edit the installation, there're enough tools for that, but i couldnt find a reliable solution to edit the setupfiles and leave sfc intact afterwards. setupapi.dll is patched and sfcfiles.dll is replaced with an empty list of files. im getting Setting reg key HKLM\Software\Microsoft\Works\6.0\Calendar\CurSize Error 5: Access is denied. while inserting the rollup reg values. if i remove the calendar entries it works. any hints on that?

readme: this little app tries to slipstream ms packages into a windows installation (unlike /integrate of hft2 packages) the idea is to analyze these packages as they are with the goal to be as universal and accurate as possible (hence the name) pros: - should work with all supported hotfix types - should work with all available languages - should work with various editions of a windows version - fileversioninfo is used to get the exact version - no duplicate files with different versions, driver cabinets are merged cons: - relies on expand.exe, makecab.exe and MSICabExtract.exe - files need to be extracted to get fileversioninfo - the .inf parser implementation is done just by peeking at the files, at this state it might be partially wrong limits: - supported packages are hotfix types 1 (.exe and .cab) and 2 (only .exe) - .msi support currently just for MSXML 4.0 Service Pack 2 - at this state the whole installation is copied and extracted instead of modified since this is an experimental version (installation get huge!) - this is the first release, w2k pro mode is hardcoded. dont use other versions/editions at this time - inf conditions are not implemented - currently svcpack.inf is newly generated instead of modified - currently the process is uninterruptable so check your settings i started this app last weekend, so its in a very early stage. youre welcome to try it and report back what happened im currently not 100% convinced that this is a successful approch (parsing the packages) since the inf files can get pretty complicated (eg conditions). let me know what you think of it. my last log is inside the attached archive, take a look and you'll get the idea what this app is for and how it works. i only tested the packages reported in the log, so dont even think about throwing dx, netfx, wmp etc at it current issues: when integrating ie6 first logon hangs (you can see the ie6 runonceex thing), this is because registerdll wont find some files. follow these steps: - when logon hangs, press ctrl+alt+del and logout - login again - copy uhfs.inf from \i386 off the cd - remove readonly flag - edit header like this: from [Version] Signature="$Windows NT$" ClassGUID={00000000-0000-0000-0000-000000000000} layoutfile=LAYOUT.INF [Optional Components] UHFS [UHFS] OptionDesc="UHFS combined inf" Tip="UHFS combined inf" Modes=0,1,2,3 CopyFiles=xxx AddReg=xxx DelReg=xxx RegisterDlls=xxx to [Version] Signature="$Windows NT$" [DefaultInstall] AddReg=xxx DelReg=xxx RegisterDlls=xxx then save, rightclick it and chosse install relogin now ie and oe should report the rigth version there're still tons of other issues because i just started looking at how the installation procedure works. edit uhfs.ini to test my app put hotfixes in the PATH_HF directory. subdirectories are ignored except "ie6setup" where you can put the whole ie6 installation (13 cabs) regards uhfs 0.0.1.0

yeah its not, reread my post and try your multi cd with just erd on it there are "\i386" "\IA386" and "\AMD64" strings in txtsetup. even xp32 has amd64 strings in it. i guess the bootloader selects a section based on the cpu

i had the same problem with erd 2005 and xp64. the folders interfere. eg there were some references to '\amd64' in txtsetup from erd. removing xp64 from the cd resolved the prob. so i guess one of your windows versions on the cd has a standard folder name and erd tries to load those instead of its own files. i also tried editing txtsetup from erd but with no sucess. if you make it, let me know regards

good to hear, please report back whatever comes out of 64bit pe on the other side, i cant get erd2005 and xp64 (unmodified!) to work on multiboot. there're some instances of "\amd64" etc in txtsetup.inf of erd. i tried to modify it in some ways but couldnt get it to work if xp64 \amd64 is on the dvd too so a hacked setupldr is most welcome regards

tommyp: de the script doesnt work on german version, i didnt dive too deep into it but i guess some regkeys differ too regards

which means pe based wont work <{POST_SNAPBACK}> using winnt.exe in Dos won't work, correct. But you can use winnt32.exe in a command line on winpe. I've done it, i know it can be done. <{POST_SNAPBACK}> oh ok, sounds good. at least one way to do it

well i tried to initiate the setup with some other option than booting from cd, but after reading http://support.microsoft.com/kb/896334 i dont think there're many possibilities except network based setups and which means pe based wont work so i guess the only multiboot solution is to hack/use another ntldr

yes, the original filename is 'Q818043_W2K_SP5_x86_EN.EXE', but the scripts looks for the word 'windows' in the filename to determine if its hf1 or hf2. so i guess tommyp simply renamed the file (it is a hf1). in case all q*.exe fixes are hf1 add this after line 340: 'FINDSTR /B /I /C:Q HF.TXT >>HFT1.TXT' im testing the german version atm. there are a few lines hardcoded for the en version i changed: 3 times Windows2000-KB891861-x86-ENU.EXE (DEU) and tons of 'scripten' from ie6 (scriptde) and i can see 'REM ROOTS UPDATE, STILL NEEDS A CMD LINE RUN NOT IMPLEMENTED YET' but it seems the *.sst files are copied during the install. so i guess i could simply execute updroots.exe authroots.sst updroots.exe updroots.sst updroots.exe -l roots.sst updroots.exe -d delroots.sst using svcpack.inf/cmdlinex.txt/guirunonce? but great work so far, keep up regards

poking at that file (xp64 final) shows some interresting strings: http://pastebin.com/308398 it partly shows what the bootloader is capable of doing. maybe there a way to trick the loader (eg ramdisk with original loader and different txtsetup.sif) i tried a modified pre-sp1 2003 loader with xp64 but that didnt work

hey, im new here so 1st of all: hi reading a bit on these forums helped me out while compiling my own dvd. i managed to put w2k de&en, xp de&en, xp64 en, symantec rescue disc (ghost 9) and erd commander on one dvd (and tons of recue/diag bootdisks). both w2ks have sp4 and update rollup 1 integrated as both xp's have sp2. you prolly already know it but i though i share how i got those 2 winpe setups on my disc. problem was that i didnt want to mess around with the setupldr.bin/txtsetup.sif of xp64 since it has 2 root folders: i386 and amd64. looks like in i386 are wow32 libs and the bootloader which sets the cpu to 64bit mode and installs primary from the amd64 folder. symantec rescue disc is in \GHO9 and erd is in \ERDC on my disc and they both run smooth. what i couldnt edit was the "documents and settings" folder from both pe's, so i copied that one to the root (luckily erd one was empty and so no files are conflicting) what i edited for erd: - setupldr.bin: i386 to ERDC on all occurrences - txtsetup.sif: SetupSourcePath = "\ERDC\" cdtagfile = "\ERDC\win51is" cdtagfilei = "\ERDC\win51is" cdtagfilem = "\ERDC\win51ms" cdtagfilea = "\ERDC\win51as" as you can see i just put the windows tagfiles into the subfolder instead of root. i didnt test it but if i had done it the other way they could have conficted with the root tag files (eg. xp sp2 and sp1). those tagfiles are needed or the environment wont find its files. thats it. did the same for GHO9 (well tagfiles arent 100% like erd but you get the idea) x64 installs fine since its 100% untouched and both pe's are working oh and im using bcdw-2.0a1 and cdimage, no cdshell memdisk or whatever there is next thing im trying to add is an edited copy of setupldr.bin/txtsetup.sif to install german mui for x64 unattended as soon as i get my hands on it. (2 bootoptions for xp64). regards