RyanVM

My next release will be adding a registry entry as well which gives the version of the pack installed, so that'll make life a bit easier

Now there's an understatement I can relate to

Like bhurtel said, you're going to have to disable WFP if you want to delete those files and not receive any prompts about doing it.

Follow the "Where's the next version?" link in my sig

And it's loosely based on Java circa 1997 EDIT: http://www.msfn.org/board/index.php?showto...ndpost&p=186239

There's a 1.2.2b update in my forums which contains the June security updates. But like kelsenellenelvian said, I really want to get 1.3.0 out this month.

Wow, that's really bad software design. I'd seriously consider emailing the developers asking them to support a modern JVM rather than that archaic piece of junk.

Try deleting the equivalent files back to back. In other words, delete "%systemroot%\system32\dllcache\ss3dfo.scr" and immediately after, delete "%systemroot%\system32\ss3dfo.scr". That should get rid of both copies before WFP is able to replace them (and yes, if a file is in dllcache, it's protected by WFP). Of course, you'll be prompted to insert your XP CD when WFP is unable to restore the file from the hard drive.

I've got MU partially integrated. The only difference between it and WUv6 is that it also includes a file muweb.dll, which must also (along with wups2.dll) be registered. However, Tools...Windows Update still defaults to WUv6. Also, the first visit to MU still requires the user to go through the "Start using Microsoft Update" stuff (though nothing has to actually be downloaded from the site). After going through that, Tools...Windows Update points to MU like it's supposed to. I think MU is going to eventually replace WUv6 once the kinks are worked out anyway, so this may be a moot point. Given the current bugginess of MU, I'm actually OK with it defaulting to WUv6.

WinUpdatesList v1.12 Web site: http://www.nirsoft.net

What I don't get is why this issue even affects XPSP2. The MS JVM hasn't been included with Windows since SP1a. I suppose there are those who manually install it, but that's crazy IMO given how extremely outdated and insecure it is (as I've ranted about in other threads on this forum).

Yeah, all it is is a registry change. I'm not sure if it's a final fix or a temporary workaround until they come up with a real fix for the problem.

I'd be willing to help you work on integrating my stuff through your program, but not to actually create it from scratch.

Is there an MSP of 10.0.1 yet?

So, anyone figure out a way to unattendedly make MU the default site yet?

Have fun

But seriously, good luck to you on this project. Here's to hoping it turns out alright .

It's RyanVM, not ryanvm (hmm, I think I should go old school and go back to my first MSFN title - Grammar Nazi)

Let's start with the basics, are you certain the batch file is actually executing? cmdlines.txt syntax looks like this: [COMMANDS] ".\update.cmd"In this example, update.cmd is sitting directly in the $OEM$ folder along with cmdlines.txt (not in any subfolder of it). EDIT: Here's a screenshot to give you a better idea of what I'm talking about.

Driver integration is the only way. You can either follow GreenMachine's guide for adding SATA drivers for your specific controller, or you can use Bâshrat the Sneaky's driver packs, which should support your controller.

If you have OemPreinstall set to Yes in your winnt.sif, F6 will not work for loading drivers.

HKLM can be added at any time (but I just add all my tweaks at once). If I were you, I'd call a batch file from cmdlines.txt which then runs regedit. The scope of commands which can be run from cmdlines.txt itself is fairly limited. Batch files will give you much more flexibility.

Link?

What we've been saying all along is that there's nothing on the XP Install CD which uses InstallShield, so those files aren't coming from the XP Install. Nobody's been debating that the EXE comes from InstallShield.