new fileset

[Martin H]

OK, i am now officially confused

I got to think about that the error in setuperr.log about mpcodecs.inf also was present when slipstreaming dx9c, so i just now checked setupapi.log on the system i'm typing from now, which is a FDV set#8e system with dx9c slipstreamed(the previous post was from a VM session), and what do i see there:

[2008/11/15 02:50:59 348.2106]
Setup could not register the OLE Control C:\WINNT\system32\acelpdec.ax because of the following error:
DllRegisterServer returned error 2147746132
Error parsing RegisterDlls section register in C:\WINNT\INF\mpcodecs.inf: Error 0x80040154: Class not registered
Error parsing install section DefaultInstall of C:\WINNT\INF\mpcodecs.inf: Error 0x80040154: Class not registered

And MPC works fine on that system...

Now since the failling file is at the top of the inf's 'register' section, then all the underneath listed files should also not have been registered ???

Hmm, maybe the other dx9c install inf's, which is run from RunOnceEx are then registering them ?

[Martin H]

OK, i've now just re-read the dx9c part of the hfslip batchfile, and then also looked at the dx9c install inf's, and yes, the reason for MPC working still, even though mpcodecs.inf dosen't register the codecfiles(errors out on the first file), is that the dx9c inf's which HFSLIP sets to run from RunOnceEx, allready registeres many of them, like e.g. dxdllreg.inf:

[DShow_RegisterDll]
%11%\amstream.dll
%11%\devenum.dll
%11%\encapi.dll
%11%\mswebdvd.dll
%11%\qasf.dll
%11%\qcap.dll
%11%\qdv.dll
%11%\qdvd.dll
%11%\qedit.dll
%11%\quartz.dll
%11%\l3codecx.ax
%11%\mpg2splt.ax

[tommyp]

The directx 9 portion of the script brings back many bad memories and countless test runs on a vm. The issue was that the W2K setup is pretty complex with multiple runonce's that get parsed during install. It was tricky getting custom INFs to run at the right point in time, and as early as possible so it would not interfere with the remainder of the setup. If an INF was called too late, then all the custom hfslip INFs would get overwritten. Thus the reason for the entry in the add/remove programs. If something wasn't run at the right point in time, that entry would not be there (and it put a nice little tommyp touch on the OS). With XP, it's a piece of cake. There's only one runonce called. Man, that must have taken me about 3 weeks to figure out what was happening thanks to undocumented setup routines that msft doesn't provide. Putting that into a script to autogenerate the INFs was the next tricky step. I'm surprised you were able to read through that code. May I suggest that the troublesome INF get cleaned up in the next fileset. If any entry is incorrect in an INF file, it won't run. Trust me, I found that out the hard way when coding a while ago. Sorry for rambling. Happy new year!

[Martin H]

Many thanks for your reply, Tommy - and i wish you a happy new year too, mate

Yeah, while reading through the HFSLIP code and the dx9c inf's, i also thought to myself, how one earth you had figured all that stuff out by yourself Very impressive!

Anyhow, i love ramblings, so please don't hold yourself back when replying to me, as i enjoy background-stories, insights and getting to learn whats going on in detail...

Btw, Happy new year also to Fred and to all other MSFN members

CU, Martin.

[Martin H]

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

Edited January 5, 2009 by Martin H

[tommyp]

The 'dxdllreg.exe' call is probably redundant, but if one were to install dx9c the old fashioned way (i.e. from the MSFT distributal), the end result is a reboot now box, but if you look in the runonceex section of the registry, you'll see same 'dxdllreg.exe' call. HFSLIP just mimics the whole thing. IIRC, without the dxdllreg command, you see dx version 7 instead of 9c when you type start/run/dxdiag.exe. I could be wrong but I believe dx is tightly knit with playing media files. If too many files are removed you won't be able to play media files. I had a tricky time with that when developing hfcleanup.

[fdv]

The last VM i made was a non-FDV install with standard dx7 ... 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.

This is truly strange; I don't recall ever seeing some sort of DLL dependency where something has to be present for registration success. Or if I do know I am not remembering. I mean, clearly, when you register these files, they are looking for some other file my fileset rips out. I have to be honest, it's really too much trouble to fix. I have modified my INF file to deal with acelpdec.ax. Other than that, I have to make the presumption that most people will install dx9.

The only other thing I can do would be to have HFSLIP "see" which dx is being installed, and then call a special install section and include two [DefaultInstall] sections, like:

[DefaultInstall]

...

RegisterDlls = register.dx7,register.dx9

[dx7install]

...

RegisterDlls = register.dx7

Etc. Too much work, though, to make HFSLIP mod an INF and call a dx7 installer if the dx9 cabs are not present.

[Martin H]

The 'dxdllreg.exe' call is probably redundant[...]

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

[...]I have to be honest, it's really too much trouble to fix.[...]

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

[Martin H]

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 ?

[Martin H]

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

[Martin H]

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

Edited January 11, 2009 by Martin H

[Martin H]

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.

[tommyp]

I'm not sure if this helps or not, but I think there may be some dependencies broken. With my hfcleanup'd ie6 core/dx9 2k source (I'm not using FDV's fileset), I'm able to register all of those files listed in the previous post except strmdll.dll and msdxmlc.dll. The others all register fine. I had many issues developing the hfcleanup fileset and being able to play media files, it was like walking a tightrope. There seems to be some sort of hidden link between files like this, or in other words, a file can't register because there's another certain file(s) missing. Other than putting the removed files back into the system32 folder one by one and retesting the register process, I'm not too sure how to handle this.

[Martin H]

@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)

Edited January 18, 2009 by Martin H

[Martin H]

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

Edited January 23, 2009 by Martin H