From: MikkelFJ <mikkelj-anti-spam@...1.dknet.dk>
Date: 2001-08-25T21:54:20+09:00
Subject: [ruby-talk:20368] Re: New Windows InstallShield version of Ruby


"Kevin Smith" <kevinbsmith@yahoo.com> wrote in message
news:20010825015907.31268.qmail@web13808.mail.yahoo.com...

> I've been out of the Windows internals game for a while,
> but I believe this is left over from the 16-bit days, and
> I've heard it will be fixed in Windows XP.

This XP fix - does this relate to the 16bit subsystem (WOW) or windows as
whole?

16bit windows (and 16bit subsystem on 32bit windows) has its own set of
problems: an app that crashes will not unload its loaded dll's because it is
not a process. This will leave the dll hanging - which can be very annoying
(16 bit only!).

> "Modules", as they refer to DLL's and EXE's, have a short
> name that is used internally. If that name already exists
> in memory, the copy in memory is reused, even if the _path_
> to load that module is different. Which is exactly what you
> describe.

Not sure about 16 windows, although I doubt it.
However, there are many different ways to load a dll: using COM technology
or Visual Studio's internal dll loading mechanism.

(For those wondering - COM is usually just an advanced use of DLL's)

> The other post referred to the possibility that the DLL was
> remaining in memory for some time after the last app using
> it had unloaded. Someone said this was impossible, but I
> find it plausible.

<addressing 32 bit windows only>
That was probably me, although I didn't say impossible.

To be sure, I just wrote a testapp, copying a test dll to two different
places. Then I created a test program that loads the dll - which I ran twice
simultanously. The program also investigates the module path of the loaded
dll. In each instance, I loaded exactly the dll I wanted, and I had both
dll's running simultanously.
If this wasn't possible, it would also be very difficult to work with
versioned in-process COM components.
But again - depending on the mechanism used to load the library, you may
have a point.
Using the LoadLibrary call, you can control exactly what dll you want to
load.
Finding the right dll is a completely different issue - also known as dll
hell - partially solved by COM component registration - but replaced with
even more complicated problems.

> We've exhausted my knowlege (and then some), so I'll duck
> out now.

It is a nightmare - I have always tried to know only just enough about this
issue to actually get something running.

Mikkel