I have a DLL-hell problem that I need to solve for my job, and I'm in a catch-22 that I'm looking for a way out of. I'm hoping someone here can help. Please bear with me, it's got a long setup explanation:

Background:

I've got an install program which has to install a shitload of Microsoft libraries.

Among the libraries are the Internet Explorer libraries for rendering web pages, SHLWAPI.DLL and WININET.DLL.

Also among the crap that's got to be installed is the Microsoft Data Access components and the Distributed Component Object Model libraries. These come in the form of self-running EXEs that Microsoft has pre-determined an install method for (MDAC_TYP.EXE and DCOM95.EXE). I just fire them off in Silent mode, and they automatically stick themselves in the start menu so that they install themselves on the next reboot.

We also have to set up our stuff and install all of our DLL's. Some of these DLLs are self-registering (because they used the Microsoft libraries to get their job done), and their self-registering function ("DLLRegisterServer()") makes a call to the SHLWAPI/WININET stuff as part of its registration process.

So this is done in two steps: Our program runs its setup, which reboots the computer at the end of the setup so that any locked DLLs can be overwritten. Only after this reboot is the Microshaft mdac/dcom stuff installed.

All of this works well, except for one problem...

The Problem

If you install this onto a '95 system, all is well, because '95 doesn't have the SHLWAPI stuff installed at all. Our stuff gets installed and fresh new copies of SHLWAPI (etc) go into place.

If you install this onto a '98 system, all is well, because '98 has recent enough versions of the SHLWAPI stuff so that the Microsloth libraries function when they try to self-register themselves.

If you install this onto a '95-SR2 system, you're completely fucked. Because '95-SR2 has an old, half-assed version of the SHLWAPI stuff installed which won't allow our libraries to self-register. Our libraries die when they try to self-register against the SR2 version of SHLWAPI.

Guess which version of the OS our branches are running?

Sure, we're replacing the SHLWAPI stuff with the newer version, but it isn't in place until after the next reboot (have to use wininit.ini to put the newer versions in because the SHLWAPI shit is locked at the initial install time). And I've got no provisions to defer a self-registration until after a reboot. Besides, the microsloth stuff is doing its install after that reboot and I can't do shit at that time anyway.

What I can't do:

I can't ask our programmers to change their libraries or the self-registration process. My first statement to the manager was that it was a bug in our libraries and they should be fixed so that they don't call the Microshit libraries during self-registration. I was shot down, because our programming team wouldn't even know where to begin to do that. They can only create "monkey-see-monkey-do" programs that depend completely on the Microsoft code bases.

I can't defer the self-registration of our DLLs to another time period without a huge amount of work. There's no provision in InstallShield for doing that, so I'd have to code something up myself, totally custom, and completely rewrite my (already complex) build. Okay, sure, I could do that, but it's a last-resort thing only.

I can't create a fucking "two-reboot" setup for a stupid little training program. I just won't do it. One reboot, max. I'm pissed that the program even has to reboot once, let alone deliberately code it so that it needs two boots to install.

My Request:

What stupid-ass process has the SHLWAPI shit locked in 95-SR2 so I can simply kill it dead dead dead before my install starts, and then my install will work?