Martin H

There's two msft supported methods for integrating updates into an install-source(i.e. there's msft docs available about those methods), and that's to either use the /integrate switch, or to use svcpack.inf to get all the update-installers to install at T-13. The /integrate switch method dosen't seems to be what you're after, since that method will also directly replace outdated binaries in the install-source with the new updated ones(besides integrating all the installers and running them at T-13). If you still wants to do this, then the easiest way is to simply just make a batchfile, like e.g. for %%g in (*.exe) do "%%g" /q /integrate:D:\XPCD For the svcpack.inf method, then again, the easiest method is to just do it yourself, and the MSFN 'Unattended Guide' shows you how this is done(and also the previous method)...

@FDV Adding acelpdec.ax to RegisterDlls worked the last time i tried it a few days ago, but since it in the past have failed many times from there, then i have just again tested adding it to registerocxs instead, which in my last several tests always has worked, and it also worked fine this time, so if you could please add acelpdec.ax to registerocxs in mpcodecs.inf in your next fileset, then i would appreciate it... [registerocxs] "%11%\mpg2splt.ax" "%11%\ivfsrc.ax" "%11%\msdxm.ocx" "%11%\msdxmlc.dll" "%11%\strmdll.dll" "%11%\acelpdec.ax" Thanks in advance, mate! CU, Martin.

I don't really know about nLite, i must confess, but with methods like winnt.sif and such, then adding numbers infront of the foldernames won't change the install order, as Windows setup dosen't install drivers in a "folder-name" chronological order like that... Hint: You can check '%windir%\setupapi.log' for the actual install-order of the drivers...

The 'attrib' cmd command supports defining a folder-name as target, but then wildcards isn't supported. Also, there's switches for enabling recursiveness(/s) and for enabling the processing of folders additionally(/d).

@fdv Thanks alot, mate! Yeah, the first one is good, i've just tested it. Btw, was the acelpdec.ax missing in mpcodecs.inf on purposse? (from registering i mean...).

Yes, you can also integrate/slipstream other updates into your install-source than just the high-priority security patches, but if you e.g. use the /integrate switch to slipstream the updates, then it's not all updates that's supported, and you'll have to find that out for yourself. If using svcpack.inf, then most updates work without problems...

@FDV Thanks alot, my friend! I've just tested set-8h and all files registered fine from mpcodecs.inf! (acelpdec.ax isn't set to registering from that inf, though, but i don't know if that's on purposse or not... ) About the regkey you added to hivedef.inf: HKCU\Software\Microsoft\Windows\CurrentVersion\Controls Folder... I'm sorry, and i should have explained it better, but what i meant was that Tomcat's HFNetChk script that's available from the HFSLIP site's support section, needs to check a specific value under that regkey you added to hivedef.inf, and that value is: "Presentation LCID"=dword:00000409 Which defines the language(1033 on US), and without this value, then that regkey alone from hivedef.inf isn't helping... However, adding that regkey+value to hivedef.inf isn't really needed afterall, since the key+value is automatically generated by Windows after a little time anyway, and also since if the key+value isn't available when running the HFNetChk script, then the script will report on the screen that the OS language couldn't be identified, and that a text file named lang.txt should be made with the language code(1033), and then to rerun the script, and then it works. So i would suggest to either remove that regkey from hivedef.inf, or to keep it while also adding that extra value to it... Sorry again for not explaing that better the first time, mate! Again, thanks alot for your work, man; it's much apprecited!

The difference is that the /integrate switch actually slipstreams the updated binaries from the updates into the install-source, whereas using svcpack.inf, only integrates the update-installers into the install-source, and installs them at T-13. However, the /integrate switch is implemented pretty badly IMHO, since this method still also leaves all the update-installers into the install-source, and runs them at T-13, just to get the needed reg-entries and possible post-install commands. Another bad thing, is that if the outdated binaries in the install-source where cabbed, then the /integrate switch will leave the updated binaries uncabbed in the install-source. nLite by default slipstreams the updated binaries directly without using the /integrate switch method, but not all updates are supported, and for those, then nLite either uses the /integrate switch, or lastly the svcpack.inf method. There is also a cmd script named HFSLIP, which will slipstream the updated binaries directly, without integrating the installers and running them at T-13, and without leaving the updated binaries uncabbed in the install-source, and it supports more updates for direct integration than nLite does(atleast for win2k that is)...

@FDV: With fileset-8g, then i've noticed that the reg-key: 'HKCU\Software\Microsoft\Windows\CurrentVersion\Controls Folder' isn't created upon a fresh install, but then after some days when i checked again, then it had been created... I can't remember if it was the same with fileset-8e(the last one i used when checking that reg-key), but could you please tell me if you have changed something with respect to that key? Thanks in advance, mate. CU, Martin.

@FDV Thanks alot for set-8g, mate! I've just tested it, and no files missed registering and media playback worked fine in MPC(with dx9c)! Also, many thanks for now keeping the regkey: 'HKCU\Software\Microsoft\Windows\CurrentVersion\Controls Folder'. Btw, from reading the fileset-changelog, then it states that hivesft.inf in set-7 includes "fixed timezone-information" untill Jan '08, but does that then mean that the timezone update on Tommy's list isn't needed then? (I'm guessing yes, but just wanted to be sure, and i'm reffering to this update: HFSLIP_PRE_TZ4.CAB/CMD ~ KB951072) You don't have to respond to this next part if you don't want to, and i'm just posting it if anyone should care On a fresh set-8g/dx9c install, then all files registered since fdv deleted the bad ones from mpcodecs.inf's 'register' section. I then tried to register the files that FDV had deleted, and the sucess-rate varied with what method/dll-engine used: With setupapi.dll(e.g. when rightclik/Install) and 'RegisterOCXs': + acelpdec.ax + mpg2splt.ax + ivfsrc.ax + msdxm.ocx + msdxmlc.dll + strmdll.dll With advpack.dll and 'RegisterOCXs': + acelpdec.ax + mpg2splt.ax - ivfsrc.ax - msdxm.ocx - msdxmlc.dll - strmdll.dll With setupapi.dll(e.g. when rightclik/Install) and 'RegisterDlls': + acelpdec.ax + mpg2splt.ax + ivfsrc.ax - msdxm.ocx - msdxmlc.dll - strmdll.dll With advpack.dll and 'RegisterDlls': - acelpdec.ax - mpg2splt.ax - ivfsrc.ax - msdxm.ocx - msdxmlc.dll - strmdll.dll (The inf wouldn't install at all, so no error-logs/messages and no files registered)

I've just made a new test, and i really don't understand why, but with this test, then there was a change in what files could be registered from mpcodecs.inf... This time, then the new thing was that mpg2splt.ax couldn't register, but acelpdec.ax could. Btw, mpg2splt.ax is registered no matter if mpcodecs.inf does it or not, as hfslip does that(twice actually; by an inf call and by calling dxdllreg.exe...). So, the non-registerable files now where: ivfsrc.ax msdxm.ocx msdxmlc.dll strmdll.dll mpg2splt.ax Then the next observation i've done, is that i've now gotten all those unregisterable files to register by running an inf which used the same registering-method as used in mplayer2.inf: [Version] Signature=$Windows NT$ [DefaultInstall] RegisterOCXs=registerocxs [registerocxs] "%11%\mpg2splt.ax" "%11%\ivfsrc.ax" "%11%\msdxm.ocx" "%11%\msdxmlc.dll" "%11%\strmdll.dll" Then afterwards, i did the same with a dx7 install and again gotten all files registered using the above technique, and then i tested MPC, but still, not a single DVDRip(xvid) would work anyways, so the key to getting everyting working is obviously hfslip's dx9 integration... Btw, i'm not wanting you to try and fix the dx7 issue, as i'm okay with using dx9, but since the above also relates to dx9, then i thought that i would post it to you CU, Martin.

@FDV I'm guessing that you're gonna comment out the 4 following files from your latest mpcodecs.inf, since they will not register on either dx9 or dx7: ivfsrc.ax msdxm.ocx msdxmlc.dll strmdll.dll But could you then please do me a favor, and keep the file 'mpg2splt.ax' as the very last file in the 'register' section, since that's the only additional file which won't register on dx7, and so if you keep it last, then i can skip slipstreaming dx9c, as i will then only miss getting one file registered(mpg2splt.ax) compared to if using dx9c, but if you don't keep it last, then i will miss all the underneath listed files getting registered on dx7... Thank's in advance Edit: Just wanted to say that i will from now on always slipstream dx9c, as i just made a test of doing what i described above to mpcodecs.inf and with dx7 then i cannot play a single audio or video file in MPC...

I've now logged the output of Tomcat's hfnetchk script to find out why it dosen't work on my VM test of set#8f(it works on my installed system with set#8e) and the result is: The script runs this line: REGEDIT/S/E WINLNG1.TXT "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Controls Folder" That regkey isn't in set#8f, but is on set#8e... Just an observation...

You are very welcome, mate (although it was Tommy's credit, not mine... )

I've just finished a VM test-run of the silent update of set#8f and with dx9c slipstreamed, and the result is that mpcodecs.inf still dosen't register any files, since the first file to be registered fails registering... I then comented the bad file out and re-installed the inf etc untill no more errors in setupapi.log and so here's the list of the unregisterable files: ivfsrc.ax msdxm.ocx msdxmlc.dll strmdll.dll Another kinda strange thing was that with Tomcat's hfnetcheck cmd script(the one from the hfslip homepage), then i got an error message from the console about not being able to determine the correct language, and previously, there have never been such problems ?

Sorry, what i wrote before was not entirelly accurate... When using the standard 7z-sfx module, then there's no text-mode file-copy errors, but there are file-copy errors, when using the modded module from Oleg S. I don't really myself understand how the official module can escape from having this issue, since even though the part of the PE header where the checksum is stored in, is called 'Optional', then it shouldn't be optional for executables, or atleast that's what i've read... In short: modifyPE.exe is your friend as Tommy said

Thanks for your reply! Actually, then i meant that 'dxdllreg.exe' should be run, as the dx9c redist also does it, but that then the following was redundant: ECHO>>WORK\ROROEWU.TXT HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",ZZZ611,,"RunDll32.exe %%11%%\AdvPack.Dll,LaunchINFSection %%10%%\INF\dxdllreg.inf,DirectShow" ECHO>>WORK\ROROEWU.TXT HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",ZZZ612,,"RunDll32.exe %%11%%\AdvPack.Dll,LaunchINFSection %%10%%\INF\dxdllreg.inf,DirectSound" ECHO>>WORK\ROROEWU.TXT HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",ZZZ613,,"RunDll32.exe %%11%%\AdvPack.Dll,LaunchINFSection %%10%%\INF\dxdllreg.inf,DirectPlay" ECHO>>WORK\ROROEWU.TXT HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",ZZZ614,,"RunDll32.exe %%11%%\AdvPack.Dll,LaunchINFSection %%10%%\INF\dxdllreg.inf,DxDiag" ECHO>>WORK\ROROEWU.TXT HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",ZZZ615,,"RunDll32.exe %%11%%\AdvPack.Dll,LaunchINFSection %%10%%\INF\dxdllreg.inf,DX8RetailDLLs" IF "!VERSION!"=="2000" ECHO>>WORK\ROROEWU.TXT HKLM,"SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce",ZZZ616,,"RunDll32.exe %%11%%\AdvPack.Dll,LaunchINFSection %%10%%\INF\dxbda.inf,BDADllRegister" When running 'dxdllreg.exe', then it will run exactly these specific INF sections that you call with the above code, and make the 'DirectX.log' in '%windir%'... Anyway, this is really nitpicking, since your script works fine and that's the main thing of course, but i just thought that there weren't any reason to register the same files twice after eachother and that avoiding this could shave some secs of the install time, but no biggie Just ignore me, it was just meant as an observation Sure thing, mate - no problem, i'll just slipstream dx9c always from now on Anyway, my posts was also to tell you that many of the dll's are allready registered by HFSLIP, which can be seen by everything seems to be working fine with dx9c and your fileset, even though previously, then mpcodecs.inf wouldn't have regsitered one single file, since the very first file failes... I will test the new change now and report back if all dlls registered fine(with dx9c)...

Yeah, Tommy is right! I remember this issue myself, as i used to use HFGUIRUNONCE along time ago, and if not running modifyPE on the exe's first, then that exact error came up(Tommy also helped me with that issue back then!)... It's because if Windows is copying files during setup, then setup calculates the exe's checksum and compares it to the PE checksum stored in the exe's header, but on e.g. 7z sfx's, then the PE checksum in the header comes from the 7zs.sfx module(which is the actual header on 7z sfx's) and hence, will always be the same value and not match the actual exe's checksum, as the real checksum would obviously vary from exe to exe...

There are a bunch of good Hash calculating/verifying apps available(i prefer the command-line fsum.exe), and IMHO, then the only need for Msft's CRC verification tool, is if wanting to verify the AutoCRC value of MSDN ISO's, or other ISO's made with cdimage.exe's -x switch, and for that, then v3.05 is just fine... Just my 2 cents, though

Just a very small thing... As i said before, then the non-registerable files from mpcodecs.inf where: acelpdec.ax ivfsrc.ax mpg2splt.ax msdxm.ocx msdxmlc.dll strmdll.dll When looking through '%windir%\DirectX.log', then it shows many of the dx9c dll's that's been registered... On that list, then i only found one of the unregisterable files listed above i.e. 'mpg2splt.ax' and that had registered fine and actually twice, from both 'dxdllreg.inf,DirectShow' and 'dxbda.inf,BDADllRegister'. Then i looked at those inf's and they register the files like this: RegisterOCXs=DShow_RegisterDll [DShow_RegisterDll] %11%\mpg2splt.ax Also, another of the unregisterable files i found in mplayer2.inf(i know it isn't installed with FDV's fileset) i.e. 'msdxm.ocx', and that was also installed like above... Maybe using 'RegisterOCXs' works better than 'RegisterDlls' that 'mpcodecs.inf' uses? I haven't had time to test it yet, though... Just a thought... @Tommy: In your dx9c script, then you define 'dxdllreg.exe' to run from RunOnceEx, which then will register many of the dx9c dlls(by calling specific inf sections in dxdllreg.inf and dxbda.inf) and make the logfile '%windir%\DirectX.log', but isn't it then redundant to also call from RunOnce these specific inf sections(which 'dxdllreg.exe' also calls): dxdllreg.inf,DirectShow dxdllreg.inf,DirectSound dxdllreg.inf,DirectPlay dxdllreg.inf,DxDiag dxdllreg.inf,DX8RetailDLLs dxbda.inf,BDADllRegister Just wondering, though Edit: The last VM i made was a non-FDV install with standard dx7, but anyways, i then tried to run an inf which would register the above listed unregisterable files, and i also tried it with both 'RegisterDlls' and 'RegisterOCXs' methods, and in both methods, then all the unregisterable files except 'msdxmlc.dll' and 'strmdll.dll' would register. Then i upgraded to dx9c and tried again, and still same result...

Download HFSLIP and read through the source-code(standard CMD-syntax). Also, you can download Ryan or Xable's update-packs and then extract them and check out the contents... The updated binaries of the updates should overwrite the outdated ones in the source. If the binaries aren't allready in the source, then entries should be made for the new binaries in txsetup.sif and layout.inf(dosnet.inf for non-CD installs). The catalog files are moved to SVCPACK folder and referenced in svcpack.inf to be copied over at install time. Each update's inf file should then be analysed, and the relevant AddReg sections should be copied out and either injected into the HIVE files, or into a custom inf file which is set to be installed at install time, and also any relevant post-install commands from the update's inf files should also be run at install time from e.g. a custom inf...

Thanks alot, my friend CU, Martin.

@Tommy: When using your Win2k list, then hfnetchk/qfecheck shows no missing patches/problems, but on WU, then except the obvious ones that i didn't include, then states that i'm missing: Windows2000-KB926122-x86-ENU.EXE (MS07-039) IE5.01sp4-KB938127-Windows2000sp4-x86-ENU.exe (MS07-050) The first one is an error since it's for 2K-Server, but the next one seems legit to me: When downloading and unpacking it, then it contains one updated binary: vgx.dll v5.0.3854.2500, and the inf copies/overwrites it into '%programfiles%\Common Files\Microsoft Shared\VGX\', and the old vgx.dll on the ISO is v5.0.3014.1003 Again, if i'm wrong, then i'm really sorry for the bother... Edit: Btw, i know that KB938127 is replaced on Win2k with IE6-SP1, but not for Win2k IE5-SP4...

Thanks alot for your reply, mate Btw, it's just 1 hotfix and i've never disagreed with your severity ratings... Thanks again, mate

Hi Tommy Sorry for keeping bothering you, but when you have the time/motivation, then could you please tell me if you disagree with what i said above? Thanks in advance.