|Re: [IBO] Differnt Versions of IB
On 17 May 2001, at 13:22, Rohit Gupta wrote:
> Yes the customer will shoot you.... this is a microsoft generated
> problem insisting that all libs be in a common directory.... totally
> ignoring different version support requirements.
Well, it's a moot point, because Jason says that this isn't something
3.6 was designed to do, but 4.0 will be. As for Microsoft, this is
really really easy to fix. Do it the way Linux (and I think most
unixes) does it, the ability to use soft links in the file system.
> You will find that this why 3rd party lib providers will encode the
> version # in the dpl name. The only other alternative is to put the
> dpls in the same directory as the exe. I have a vague memory of some
> versions of win-xx not checking the full path of the dlls and just
> relying on the basic name to determine if a new copy should be loaded.
You don't always want the complete version number in the .dpl name,
because that defeats the purpose of using a .dpl in the first place.
It really needs to work similar to Linux libraries, if it's going to
Take for example gds.so.0 this is the link for Firebird under Linux.
The actual filename should be the true version number,
gds.so.0.9.4.41 it actually isn't and that's a bug, but that is
beside the point. If tomorrow they release gds.so.220.127.116.11 then it
will probably change the link to gds.so.1
Here is how this should relate to IBObjects V4.0. Call the .dpl
IB_Objects_4.dpl as long as this can be a drop in replacement, then
the .dpl name is IB_Objects_4.dpl. If for some reason it isn't a
drop in replacement, maybe because of a property change, or a
component that works differently, then you change the name of the
Now, if an application doesn't work correctly due to a bug in IBO,
then you just drop in a new version of IBO, without needing to
rebuild and ship a new .exe file. When you ship by email, you don't
want to be shipping 5MB of stuff every time, especially by dial-up!