CA> one thing i always wondered about: aren't dlls from
 CA> os/2 always backward
 CA> compatible (assuming the author made no error programming them)?

No, there can be incompatibilities even if the DLL is bug-free.  For
example, an entry point that is no longer needed could have been removed. 
This would break older applications that used this entry point rather than
a newer, more powerful one.  Or there could be minor semantic differences
between the older version of the DLL and the newer version, for instance
who is responsible for deallocating a memory buffer, the DLL or the user of
the DLL?

 CA> backward compatibility was ALWAYS the case (i remember no exception) on
 CA> amigados, and the only way making sense to me right now...

Most likely you were just lucky.  There is guarantee that
ensures different DLL versions will remain compatible, even though that is
usually a desirable behavior.

 CA> you just had to pick up the newest version of a
 CA> library. however commodore
 CA> had implemented an easy way to give binary files version number which
 CA> could be check by the user (via "version "
 CA> as far a i remember).
 CA> there where routines to load a library regardless of
 CA> it's version and some
 CA> that loaded only libraries with a minimum version number.

You could easily simulate this with OS/2 DLL's by defining an entry point
for version checking.  As far as I know, however, there isn't a standard
for this version checking in OS/2 2.x.

 CA> maybe someone can fill me in on having incompatible
 CA> dlls of the same name?

Besides the things I mentioned earlier, two vendors could name totally
different DLL's the same thing.  For example, one programmer could have
written an asynchronous communications support DLL and named it
ASYNCCOM.DLL.  Another programmer could write a DLL for asynchronous
compression using idle-time threads to do compression in the background and
could also name this ASYNCCOM.DLL.  Since OS/2 can only load one DLL with
the name ASYNCCOM.DLL, there is instantly a problem if anybody wanted to
use two programs that use the two different ASYNCCOM.DLL files.

 CA> oh, another question: how are things referred to in a dll? on amiga
 CA> libraries they were always referenced to via an offset specifying which
 CA> entry of a jump table was to use. everything needed to
 CA> access a library's
 CA> function was it's offset. the functions could be namen
 CA> quite individually
 CA> to match the programmer's likes and needs.

OS/2 DLL's either use named entry points or ordinal (unique number) entry
points that are resolved into address by the run-time loader.

 CA> and another one: why doesn't os/2 prompts the user
 CA> with an information box
 CA> stating clearly which dll couldn't be found (this way it's done on
 CA> amigados) instead of popping up an information box simply saying that a
 CA> program could not be started (pm right here) for whatever reason?

It's an oversight of IBM's.  If you start the program from a command line,
it will tell you that a module is missing.  But even this message could be
improved a bit so it is more clear to the average user.

 CA> but if the author simply puts things into a dll
 CA> without the intention to
 CA> use the same dll somewhere else and without providing header files for
 CA> other programmers to make use of it there is (for me)
 CA> no obvious reason to
 CA> use a dll, instead its another burden for the user to take care of.

Sure there's a reason.  What is a "program" to you?  Many people
probably think of it is a file that creates a single running process. I
don't quite think of it this way -- I'd say a program is a complete set of
files required for a computer to perform some task. The reason I think of
it this way is because I am writing a program that is split up into
multiple processes in order to help ensure the complete program never fails
abruptly, even if there is bug in the software.  Also I'm concerned in this
particular program that I don't want a bug in a printing routine to cause
data acquisition to fail. Printing can always be restarted, terminating
data acquisition means that data is lost that can never be recovered.  So
we've isolated various activities into separate processes by creating
multiple EXE files.  To keep memory and disk space requirements down, we
use DLL files to share code across processes.  If this was done as LIB
files instead, the code would be linked into the EXE files and would appear
multiple times in memory and on disk rather than once in the DLL file.

 CA> as i work sometimes on macintoshies i can clearly say
 CA> for me, that i very
 CA> much like one icon and one file for one program and that i very much
 CA> dislike to always have to have a separate directory for nearly every
 CA> single, little program in order not to mix up the
 CA> specific files (so to be
 CA> able to remove or update a program).

In general I don't think it is likely that OS/2 programs are going to be
reduced to one file -- often there is need for configuration
files,hypertext documentation, DLL's, and other files.

 CA> by the way, why aren't configuration information of
 CA> programs always stored
 CA> in a programfile's extended attributes?

What if there is a need to run the program in different
configurations, such as by different users on a LAN?

--- Maximus/2 2.01wb