[fpc-devel] FPC dynamic libraries

[George Birbilis]

> > If you meant having many libs of different version exist 
> side-by-side, 
> > .NET runtime supports it, but Win32 itself doesn't
> 
> Most unixes also have it. The point is that it kind of 
> defeats the purpose.
> Having 20+ libraries called fpcrtl-xyz.dll (or 
> fpcrtl.so.x.y.z on unixes) defeats the purpose of a shared 
> library: saving disk and (more importantly) memory space by 
> factoring out common code. 
> 
> If we'd know that the fpcrtl.so (or .dll) interface will stay 
> the same in the next 5 years, it makes sense to distribute 
> this. Since the interface changes still wildly, it's a bad idea.
> 
> Look at Delphi packages: as soon as the interface of a 
> package changes, you must re-compile all the binaries that 
> use it. The same would be true for FPC. I can assure you this 
> is a major headache when distributing apps.
> 

Indeed, what Delphi does sucks too, I sell VCL components (binary only) for
QuickTime and QuickTimeVR (QTVR) and have to provide a separate version for
each Delphi version (@#$#@$@#). I also have the same components as ActiveX
controls (wrapping the VCL ones in them [made using Delphi's nice AX wizard
and only added property pages, which I wonder why normal VCL components
don't have as a concept]) and they're much easier to maintain, just one
build for all clients (Office, Delphi, .NET etc.). The problem with the
ActiveX is that you have to install them at the user's machine, so running
from CD with zero footprint isn't possible (there's a work arround with
products like "thinstall" that provide a small OS wrapper [just 300k for new
version of thinstall I read] arround the exe that uses a virtual filesystem
and registry just for your app, resulting in zero-footprint on user's
machine - I suppose they hijack/patch the registry and filesystem [maybe
also the disk access] APIs imports of the EXE, maybe also redefine old-style
DOS interrupts etc.)

With ActiveX too you have problem if you redefine the interfaces you
implement, but in general COM promotes the concept of "Immutable interface"
(once you publish it, never change it - not remove, nor add stuff). You can
extend evolved interfaces from it, but keep implementing it if you want
backwards compatibilty. COM itself evolves like that, e.g. with
IClassFactoryEx interface (or maybe IClassFactory2, don't remember the name)
that most probably (though not necessery) descends from IClassFactory etc.

I'd really love to be able to sell components for Lazarus too, but seems
impossible at the moment (I usually opensource the core functionality and
have the components provide extra features like I did with JEDI-QuickTime
that came out of my QT4Delphi [now QT4All] sourcebase). Maybe if Lazarus
could host ActiveX controls (not sure if the form designer now supports such
a thing, although I think FPC does support ActiveX controls more or less)

cheers,
George

----------------
George Birbilis (birbilis at kagi.com)
Computer & Informatics Engineer
Microsoft MVP J# for 2004-2007
Borland "Spirit of Delphi"
3D, QuickTime, QTVR, Java, Delphi,
ActiveX, .NET components, Robotics
http://www.kagi.com/birbilis
http://birbilis.spaces.live.com