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 
CS> right CS> now,situations like this essentially mean that 
CS> OS/2 can CS> only reliably run one of the two programs at 
CS> 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.

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

This would appear to be obvious, but why not encode the version
number into the DLL name? Eg instead of using MY.DLL, use MY1_0.DLL
for version 1.0, that way, programs automatically use the right DLL,
and there are no name clashes. The only problem I see with this is
that you may run into the 8 char file limit... (Fixing this in OS/2
may help, but don't forget compatability with FAT file systems...)

 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.

CS>If IBM would just use the complete path name for differentiating the DLL 
CS>references, that would take care of the problem, or at 
If IBM did this, it may mean that programs have to get rewritten to
specify full path names... Anyway, I am not keen on the idea, as two
files with the same name can be easily mistaken (by a user) to be the same
thing... 

CS>least 90% of it.  A "standard" format for naming DLL's 
CS>might help, also.  If you used the first 4 characters for 
CS>an organization name and the next 4 for a particular DLL of 
CS>that organization, it might help avoid DLL name clashes.  
CS>But a format like this would certainly be much more 
CS>workable with long file names.

Also, include the version number in this standard format... Again, you
will run of of characters. What about XXXXYYYY.ZZZ, where XXX is the
organisation, YYYY "describes" the DLL (to the organisation), ZZZ is the
version. Major problem with this though is that you lose the .DLL extension...
Any suggestions?

BTW, what makes DLLs a special case? Surely the same problems can occur with
named IPC? (eg named pipes, named *, etc)

Brian May
___
 * MR/2 2.03 NR * Jesus loves you.  Everyone else thinks you're a jerk!

--- Maximus/2 2.01wb