OS/2

From: Steve Mastrianni <stevemas_at_persys.com>
Date: Sat May 27 16:15:03 2000

That's specified by the import library at link time and included in the run
time image. The loader reads it when it loads the executable, then searches
the LIBPATH for the DLL and dynamically binds to the DLL by ordinal or name.

> The primary flaw of Windows DLLs

Correct. You can cause that to happen, but its unlikely because the Windows
DLLs you are using are probably already loaded. But that's always been a
flwa with Windows, especially with MFC and the dozens of different
MFC42.DLL versions. Windows 2K prevents that with what they call "side by
side" DLLs. You can't replace one of the system DLLs. When you install a
program that tries to replace a system DLL, Windows 2K will make it look
like the DLL has been replaced, but then replace it with the original DLL..
It also allows you to place custom versions of a DLL in your executable's
directory and have them loaded and used instead of the system's copy. So
things are better, but still not perfect.

In a more perfect world, I would have preferred OS/2 over Windows any day.
It has snappier response on an equivalent machine, and works extremely well
for real time data acquisition, has low interrupt latency and predicatble
response times.


At 03:11 PM 5/27/00 -0500, you wrote:

>So in the OS/2 scheme, how does it map the info at the faulted
>instruction into the filename and function of the DLL?
>
>To me, the primary flaw of Windows DLLs is the tremendous opportunity
>for the wrong DLL to be loaded - because of the lack of proper
>implementation of version checking, search path, etc.
>
>- John


- Steve Mastrianni
Received on Sat May 27 2000 - 16:15:03 BST