Tomcat76

Thanks, TAiN. It had nothing to do with the recent WMP10 changes. Windows 2000 copies logagent.exe and laprxy.dll into the Windows Media Player folder by default, but WMP9 and WMP10 expect it in the system32 folder. I worked around this problem when WMP9 is slipstreamed, but forgot that wmfdist.exe also has these files and also expects them in system32. Fixed now.

OK. Check the new version You still have the WMP10 popup at T-13 for XPSP1 (the one you normally get when starting WMP10 for the first time) but at least the installation isn't broken anymore. At this point, you can still choose between following the wizard or closing it. I'll try to get rid of it in the next few days. Also, the Documentation Update is finally slipstreamed, completing support for XPSP1. Windows Update should be cool now

We're getting somewhere. Most problems with WMP10 on XPSP1 are fixed; remaining: - playlists don't work (won't fix this) - window pops up at T-13 to complete installation of WMP10 (normally appears on first run) @the_guy: thanks; that did it @Tomalak: that manual trick won't work properly anymore for DOS-based installs with the current test releases when including WMP10 because of the double custsat.dll files. A workaround will be implemented. I want to test this one more time with XPSP1 and XPSP2 and will release a new version tomorrow at the latest because that's probably the last day you'll be able to check if all hotfixes are slipstreamed properly on XPSP1.

* Have found multiple problems with WMP10 on XPSP1 -- not fixed yet * BITS update on XPSP1 -- fixed for upcoming version * KB839645 is a mystery; it's superseded -- need to find good reg hack * Network Diagnostics Tool for XPSP2 (was this ever supported?) -- fixed for upcoming version

I experienced the same WMP10 problem and it isn't related to the problem I posted above. This'll need a bit of work. Also, WU complains about KB883357 and KB839645. Not ready for XPSP1 yet...

There's a problem with XPSP1. Hold on...

No idea what's going on there. Haven't heard from him in a while. I'd guess either he didn't pay on time or the host suspended the account out of ignorance. You have to be into this stuff to know whether it's legit or not.

Your list is incomplete but that shouldn't be an issue. As the_guy said, remove DirectX90-KB839643-x86-FRA.EXE. Also get rid of these: IE6.0sp1-KB918899-Windows-2000-XP-v2-x86-FRA.exe (you have v3) IE6.0sp1-KB833989-x86-FRA.exe (superseded)

XPSP1 is enough. And do it when you have the time Yes, please. I changed something in the INF handling of IE5; HFSLIP used to duplicate the Rollup INF with the first copy having Windows setup execute the portion relevant to Windows and the second copy execute the stuff for IE5. This is now done from one INF. If using Flash 9, the OCX is 989KB and SWFLASH.IN_ (only for 2K and 2K3) is 1.03KB large.

That's good! If you got any more comments, please don't hesitate to post them.

Things are fine on my end now. Any stress-test volunteers? To test: - 2KSP4 (with/without IE6, DX9 and WMP9) - XPSP1 (with/without WMP10) - XPSP2 (with/without WMP10) - 2K3SP1 Remove the addons while testing. BTW... I forgot to mention this in the changelog a few days ago but the MSXML3.DLL error that used to appear in setuperr.log has been dealt with...

Your posts are getting confusing. I'll clarify.... Win2K has: - MSXML 2.5 version 8.0.6730.0 Win 2K can be upgraded to all of these: - MSXML 2.5 version 8.0.7002.0 - MSXML 2 SP6 version 8.30.9531.0 - MSXML 3 SP7 version 8.70.1104.0 - MSXML 4 SP2 version 4.20.9828.0 - MSXML 6 version 6.0.3883.0 WinXP SP1 has: - MSXML 2.5 version 8.0.6730.0 - MSXML 2 SP? version 8.30.8709.0 - MSXML 3 SP3 version 8.30.9926.0 WinXP SP1 can be upgraded to all of these: - MSXML 2.5 version 8.0.7002.0 - MSXML 2 SP6 version 8.30.9531.0 - MSXML 3 SP7 version 8.70.1104.0 - MSXML 4 SP2 version 4.20.9828.0 - MSXML 6 version 6.0.3883.0 WinXP SP2 has: - MSXML 2.5 version 8.0.7002.0 - MSXML 2 SP? version 8.30.9529.0 - MSXML 3 SP5 version 8.50.2162.0 WinXP SP2 can be upgraded to all of these: - MSXML 2 SP6 version 8.30.9531.0 - MSXML 3 SP7 version 8.70.1104.0 - MSXML 4 SP2 version 4.20.9828.0 - MSXML 6 version 6.0.3883.0 Win2K3 SP1 has: - MSXML 2.5 version 8.0.7002.0 - MSXML 2 SP? version 8.30.9528.0 - MSXML 3 SP7 version 8.70.1104.0 Win2K3 SP1 can be upgraded to all of these: - MSXML 2 SP6 version 8.30.9531.0 - MSXML 4 SP2 version 4.20.9828.0 - MSXML 6 version 6.0.3883.0 No; HFSLIP only adds entries in TXTSETUP.SIF and DOSNET.INF for new binaries, not updated binaries.

From Documents and Settings?

Don't see why. The file names are different: msxml2.dll and msxml2r.dll vs. msxml3.dll and msxml3r.dll... It is now... I prefer to have some more test results come in... This is a good way to test how well the renewed HFSLIP script does...

WMP9, ya know... Nice

Please use the latest test release. The earlier ones may have contained errors.

Sorry, TAiN. Completely forgot about that... For what he's adding, I can do much better than that...

If it's in the new source then 61004b should fix it.

Is PLAYLIST.IN_ present in the I386 folder of the new source?

Doesn't really matter. Temporarily renaming the file works around the issue. I fixed the problem with the "Advanced INF" popup. There's an error in the "custom destination" section of roxio.inf: MS forgot to add ",5" to the end of one of the lines in there. HFSLIP (61004exp) is now stripping out that section and rewriting it the proper way. This is just like codecs10.inf from WMP10 and wmfdist95.exe from both the KB891122 and KB900325 hotfixes... That file is trying to copy "codecs.10" into the INF directory and this hasn't been fixed in like two years... The problem with the shortcuts was my doing. I now removed the silent Adobe Reader, .NET 1.1 and JRE 5u8 installers from RyanVM and stripped this out of my custom .REG file: [HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Player\Settings] ;"Client ID"="" ;"OpenNew"="yes" [HKEY_CURRENT_USER\Software\Microsoft\MediaPlayer\Preferences] ;"SendUserGUID"=hex:00 So one of those was responsible. My guess is that it's the registry entries, heheh. So be aware that modifying the registry with those entries (at least beforehand) will break the shortcuts to WMP9. The problem with the playlists is still a mystery...

Just a little FYI concerning WMP9 slipstreaming... I'm still not sure if it'll make it into the next final. The thing that screwed up the Windows install was the file "PidGen.dll". This file is supposed to end up in the Windows Media Player folder but the Windows installation source already contains a file with that name. I had to give it another name and give it the correct name again during the copy process of Windows installation. These problems remain (in an internal build): a) The WMP9 shortcut is in the Start Menu but it doesn't work. The "Target" path is specified and is correct but the "Start in" path is blank and that's the problem. b) The shortcut that's created in the Quick Launch bar after you go through the WMP post-install wizard (double click wmplayer.exe in the WMP application folder) also doesn't have the "Start in" path specified, making this shortcut useless too. c) During Windows installation, you get an "Advanced INF" popup asking for the location of "Program Files\Windows Media Player" where you need to click OK (the correct path is already specified in the box). This comes from roxio.inf which uses a combination of "custom destination" and a regular string to get the WMP directory path (this is for a registry entry). I may need to have HFSLIP hardcode the reg entry beforehand and strip the relevant section out of roxio.inf. d) WMP9 doesn't see the playlists even though they are in the correct location and the appropriate reg key is set. I may be looking for them in WMP in the wrong location, though: I click the arrow next to the "Now Playing" button and then mouse over "Auto Playlists"; is this where they are supposed to be shown in WMP9?

Nice to see you back, Kiki. Hopefully the recovery is going smooth You can safely unleash your powers on the current test release (hfslip-1.0b-61001a) but you'll probably use the HFSLIP 1.0 final by the time you get things up and running again. These releases should be right up your alley, hehe

Not much point, really. All that the current test releases do is exclude wgalogon.dll from being registered. HFSLIP also renames LegitCheckControl.dll to LCC.dll but that's a global rename that covers the standalone LegitCheckControl.dll (from the CAB) as well. So it's really just this:ECHO>>WORK\NSFREGNOT.TXT wgalogon.dll So let's just keep it in... Funny... The binaries are dated September 20, but they included version 1.5.554 of LegitCheckControl.dll even though version 1.5.708 was released as a standalone on August 7. It's so true that the Microsoft corporation is divided into different segments... Probably one just came back from an extended vacation...

Here's a new experimental release featuring complete WMP10 slipstreaming. This release is safe to use on Windows XP SP2. No more features will be added for Windows XP for the release of HFSLIP 1.0. WMP9 and IE7 are a PITRE (don't ask ). This might take another while to complete and may not make it into the next final. The WMP9 code is still in (which is why the script is much bigger) but it's "locked". MP6 codecs slipstreaming is possible now too but it's still untested.