[fpc-devel] FPC dynamic libraries
Michael Van Canneyt
michael at freepascal.org
Thu Feb 8 14:32:18 CET 2007
On Thu, 8 Feb 2007, Daniël Mantione wrote:
> Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
> > > Design a plugin binary API, dynload the plugin. It is not necessary that
> > > the RTL is shared for this purpose (allthough it could reduce the size).
> > >
> > > This way you only have to keep the plugin API backwards compatible,
> > > and could allow binary plugins to be used with any Lazarus version.
> > > Keeping a plugin API compatible is very doable, unlike of the full RTL, FCL
> > > and LCL, which seems next to impossible to me.
> > Why ?
> There is OOP code in those libraries. The slightest code modification will
> change the layout of the VMT.
> > Borland does it.
> Borland does not. Each Delphi version has its own BPL packages, for
> example you have vcl50.bpl. The only reason it is workable with Delphi is
> that they don't release very often.
Neither does FPC. Not an offical release, anyway.
We don't release that much more often as Borland.
> > Secondly, there are serious problems with this approach which make it unusable
> > for an IDE like Lazarus.
> > Assume I get a component instance from the plugin (MyObject), then extremely
> > simple and basic statements like
> > If (MyObject is TComponent) then
> > XYZ
> > will fail, even though MyObject is a TComponent, because the VMT of the
> > MyObject TComponent parent resides in the library, and the VMT of TComponent
> > used in the If statement is inside Lazarus, causing the statement to fail,
> > even though it should be true. When using packages, the statement will function
> > correctly.
> I was talking a binary API, and that automatically disallows sending
> classes through the API, because you want to prevent that an internal
> change breaks your external API. Simply design the API in a proper way.
You can't, for Lazarus. You need the classes, that's what you need the
plugins for in the first place: to install additional components on the
component palette. They must descend from the TComponent which is in
There is no way around it.
> > The only option are packages, and packages need an RTL in a dynlib.
> > That this requires a strict versioning schedule, is part of the deal.
> Indeed, and because this is not a workable solution, just count the
> number of changes in the VCL, a proper designed binary API is what you
I understand that, but this is not usable at all for an IDE based on class
> > Borland's packages are also incompatible between released versions.
> Sure, but above you said Borland keeps them compatible.
With this I mean that they release not so often that it becomes a problem.
if they would release every 3 weeks, it's a problem, this is obvious.
Lazarus will have to do the same if they want to have dynamically loadable
More information about the fpc-devel