Re: [Plib-devel] Releasing PLIB 1.2 *soon*.

[Eero P. <epa...@ko...>]

Steve Baker wrote:
> 
> Eero Pajarre wrote:
> >
> > Steve Baker wrote:
> > >
> >
> > > So, if the library is a DLL, he can do that - but there is a
> > > good chance that if he does, the program will crash because
> > > of the C++ issues.
> > >
> >
> > I really don't yet know if this would work. Almost certainly
> > it would only work within a certain family of compilers.
> 
> The problem is with C++ and DLL's (or '.so's in UNIX/Linux)
> is that any slight change to the C++ header file will generally
> result in a new library module that will die when linked to
> a program that was compiled with the old header.
> 
> That causes endless problems for the poor library maintainer
> because he'll get lots of emails of the form "PLIB sucks -
> it keeps crashing."...the problem being that someone upgraded
> PLIB (either accidentally whilst installing something else
> or on purpose) - and didn't recompile *all* the programs
> that refer to it.
> 
> I'm absolutely adamant that I'm not going there.  PLIB support
> already takes up *WAY* too much of my time.
> 
> You are at liberty (of course) to take a copy of PLIB, change it
> to create DLL's, call it something slightly different (PLIBDLL
> or something) and deal with the maintenance calls for that new
> package yourself.
> 

I am in the "lucky" position that I expect that my program will
have a small distribution. (And thus it will be expensive).
The typical client will also get an maintenance package. 

Obviously the client is not allowed to mess with those
application files which are not specifically allowed.
"Recovery services available at $100/hour"

So if I bundle PLIB then I am not worried about possible
dll problems ;-)

In any case this still speculation, Currently I only use 
the old "very free" PUI, not so much for license reasons,
but because my feature requirements wree satisfied with that
version.


		Eero