CS> vendor A requires version 1.01 of a DLL and vendor B
CS> requires version 1.02 of the same DLL?  As it stands right CS>
now,situations like this essentially mean that OS/2 can CS> only
reliably run one of the two programs at any one time.

 CM>   In this instance it is responsibility of the
 CM> developer's of the DLL to insure backwards
 CM> compatibility (I know those are dirty words) in the
 CM> later version of the DLL.

Sometimes that's a difficult thing to do.  This is one of the reasons why I
think that distributing libraries as DLL's is a semi-dangerous activity
unless you have a lot of resources for testing and ensuring backwards
compatibility.  Fortunately at the moment the DLL's I'm writing are for
software over which I have complete control -- when it comes time to update
the software after we get the first release done, we'll probably distribute
updates such that they reformat the hard disk of the system and load the
most recent OS/2 and the software.  Since this software is running on
computers that we provide and that will run nothing else, this sort of
brute force wipe of a hard drive is OK. Hopefully it will also help avoid
problems with compatibility bugs.

 CM>   Where the larger problem comes into the light is
 CM> when two different vendors have a name clash on their
 CM> DLLs. In this situation though, it isn't going to
 CM> matter how long the names are, because clashes can
 CM> still occur. However, something longer than 8.3 does
 CM> reduce the possibility for one.

If IBM would just use the complete path name for differentiating the DLL
references, that would take care of the problem, or at least 90% of it.  A
"standard" format for naming DLL's might help, also.  If you used
the first 4 characters for an organization name and the next 4 for a
particular DLL of that organization, it might help avoid DLL name clashes. 
But a format like this would certainly be much more workable with long file
names.


--- Maximus/2 2.01wb