Installer help, Microsoft DLL hell

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?

Just a guess, and a hack too if it works.

Locked files can sometimes be renamed even though they are in use.

How about renaming the dll's if they exist, install the new dll's, install your software and register a small app to silently kill the renamed dll's at next reboot (but the user does not have to know).

And why not check what st**id a** application is locking the files? http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

It's a wonderful world, so you might as well enjoy it.

How about renaming the dll's if they exist, install the new dll's, install your software and register a small app to silently kill the renamed dll's at next reboot (but the user does not have to know)

Good idea, but not an option. Doing that way would defeat the internal routines that InstallShield uses to check DLL versions and increase lock counts, which determine whether or not it overwrote the DLL and whether or not to erase or leave the DLL at de-install time. I would hate for someone's system to stop working when they deinstalled our product because it also deinstalled SHLWAPI.

I will also check that utility you linked, thanks.

``Fat load of no help'' wiseacre response:

I'm sure Mr. Lord could provide you with a solution that would quickly fall into the ``What I Can't Do'' category.

Okay, the utility showed me for sure what I already suspected. The Windows Explorer is what had SHLWAPI locked.

I think there's a relatively painless way to shut down the explorer temporarily without shutting down windows. I know we've done it before. Whether or not this unlocks SHLWAPI in this particular case is something I have to find out on my own...

Blimey Tony, steady on! I can tell you are cross but this is the first time you've effed and blinded on this board since you arrived. Something really got your goat...

Can I (gently, and with respect) smack you on the wrist?

You're right, I was upset. I apologize for swearing about the stupid [censored] [censored] [censored] microsoft DLL [censored].

Have you tried putting your DLL's is a cab file and putting the cab file in an object on a web page. IE will automatically install and register DLLs that way (we did that for the MUSICMATCH holiday web radio cards...we couldn't believe that it worked!). I don't know if it will bybass the locking problem, but you coud try.

IE automatically downloads and installs DLLs?

Gee that sounds secure.

Okay, thanks, got the problem solved. Terminated all running copies of Explorer and Internet Explorer using KillProcess before installing the DLLs. Then check to see if the DLL is still locked, then whine at the user if it's still locked.

I know this is the backwards way to go about it, and there are drawbacks to this method, but for our particular application (locked-down systems of fixed hardware/software) it actually is the best solution.