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

If the DLL author did not introduce any incompatibilities, then that
is the case.  But removing entry points, renaming entry points,
changing ordinal numbers, changing memory model or calling convention,
or introducing side-effects in the code that otherwise interfere with
the client's use of the DLL are all ways to break old code with new
DLLs.  And there are probably a few others.

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

IBM SOM libraries have a concept of programmatically determining the
version and release of classes in DLLs, and does some of this work for
you.  But this is still separate from the DLL namespace issue.

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

OS/2 V3 will have a BLDLEVEL command that can be used to query the
build level of EXE or DLL modules, but this will only work for newly
created DLLs and EXEs.

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

Having two or more DLLs with the same name but incompatible contents
is a bad thing, and one is going to win out over the other.  IBM did
this themselves when EPM's ETK*.DLL files conflicted with the email app
that came with TCP/IP 1.2, which had same-named DLLs.  A typical
install would render the email app crippled as a result.  What was even
worse is that the DLL names had a three-digit version number in them,
giving the wholly mistaken impression that someone was changing these
numbers when incompatibilities were introduced.  A good example of lazy
or misdirected software engineering.

OS/2 V3 may have improved matters somewhat by adding a dynamic
LIBPATH, but the problem might still exist, that once a module name is
loaded and in use, another process cannot load a different module of
the same name.

Aside from all this, it is possible to run a utility like DLLRNAME.EXE
(found in IBM C Set++) which edits the loader information in EXE and
DLL files, renaming DLLs and changing references to them in the DLLs
and EXEs given on the command line.  Of course, it's better to not get
into the situation in the first place.  (IBM ships this utility to aid
in renaming the DLLs shipped with C Set++, a few of which the licensee
is permitted to ship, but only if the names have been changed).

CA> oh, another question: how are things referred to in a dll?

DLL entry points can be referenced by name (NUL-terminated string), or
ordinal number assigned by the DLL creator.

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

Good question.  At a command prompt, running the same program will
give you "SYS1804: The system cannot find the file XXX".  When
attempting to DosExecPgm or DosStartSession, there is a space in the
API to specify where the failing module's name can be placed.  So
anything that starts another process has an opportunity to know the
name of the *first* DLL that prevented successful loading of the
program.  It might help to put this information in the dialog that the
WPS puts up.

CA> and why is it that os/2 doesn't simply say on the commandline that
CA> the DLL   files named xxx was not found instead of irritating the
CA> average user with   "xxx not found" (or similar)? but i guess that
CA> these questions can only be   answered by ibm, right?

This is because it is pointless for the loader to continue attempting
to load a module once a failure has occurred.  From the perspective of
the user, the important thing is that they didn't get what they wanted.
 (So I kind of answered my own question above.)

CA> another thing i did always wonder about is the sense of a dll
CA> supplied   with a single program. i mean if the author is absolutely
CA> sure about   releasing other programs interesting enough for the
CA> same user and the   other programs make use of the dll, it's okay.
CA> 
CA> but if the author simply puts things into a dll without the
CA> intention to   use the same dll somewhere else and without providing
CA> header files for   other programmers to make use of it there is (for
CA> me) no obvious reason to   use a dll, instead its another burden for
CA> the user to take care of.

From a software engineering point of view, there can be entirely valid
reasons for providing a single-client DLL.  Modular isolation of a body
of code away from the main application benefits the developer, which in
turn benefits the user.  Also, future upgrades of parts of an
application can be made easier by just shipping the DLL or DLLs with
bug fixes or other enhancements.  Last, there are features of DLLs that
can improve reliability (such as DLL-private memory, maintaining a
separate compiler runtime environment, using DosProtect* APIs, etc.)
that can help troubleshooting and future development work.

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

I'll give you three reasons: 1. Manipulating EAs is more tedious than
using the Prf* APIs to manipulate an application-specific INI file.  2.
Attaching per-user configuration information to the executable implies
that only one user will use the executable.  In a LAN environment, this
is often not the case.  3. Executable files are often sensibly placed
in read-only directories on LAN servers, where it is not possible to
manipulate the file's EAs.  Same can be said for CD-ROMs and other
read-only media.

CA> thanks for any reasonable answers (-:

I hope my answers to your *many* questions were reasonable to you.

John
--- Maximus/2 2.01wb