How can I create dynamic libs of the RTL and FCL units under Linux?
Mattias
Mailing lists / fpc-devel / 2007-02
FPC dynamic libraries
26 messages · 8 people · –
- George Birbilis 6
- Michael Van Canneyt 6
- Daniël Mantione 5
- Mattias Gaertner 3
- Jonas Maebe 2
- Marco van de Voort 2
- +2 more
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Mattias Gaertner wroteHow can I create dynamic libs of the RTL and FCL units under Linux?
In principle you should be able to do it with "make shared" in the respective directories. But I would strongly recommend against doing that, since the interface is by no means stable and consequently programs compiled against both newer and older rtl/fcl's are very likely to break if they use a different rtl (and possibly fcl, since the fcl also uses rtl functionality).
Jonas
Show quoted text 11 lines
On 07 Feb 2007, at 19:51, Mattias Gaertner wrote:
> How can I create dynamic libs of the RTL and FCL units under Linux?
In principle you should be able to do it with "make shared" in the
respective directories. But I would strongly recommend against doing
that, since the interface is by no means stable and consequently
programs compiled against both newer and older rtl/fcl's are very
likely to break if they use a different rtl (and possibly fcl, since
the fcl also uses rtl functionality).
That's a general problem with libs, isn't it?
We need a version system.
Mattias
Mattias Gaertner wrote 8 lines
> In principle you should be able to do it with "make shared" in the
> respective directories. But I would strongly recommend against doing
> that, since the interface is by no means stable and consequently
> programs compiled against both newer and older rtl/fcl's are very
> likely to break if they use a different rtl (and possibly fcl, since
> the fcl also uses rtl functionality).
That's a general problem with libs, isn't it?
Yes, but especially with libraries where the developers have not committed to maintaining backwards compatibility with a particular interface and which are often changed in an ad hoc fashion. The main problem is probably that we mix both general and compiler-specific stuff in the system unit. It should probably be split into something like gcc's libgcc.a (which contains compiler-specific helper routines) and the system's libc dynamic library (system and generic C language support) before the rtl is ever distributed as a shared library.
We need a version system.
That's not something "we" need, but which most OS'es need (and don't provide, except for hacks like symlinks or different filenames). Moreover, it doesn't really solve much unless you like having 20 different versions of the same shared library on your system (which would more or less defeat the purpose of saving space, although it could still save memory if more than one FPC program is running at the same time).
What problem do you want to solve with having a shared library? The complaint that Lazarus programs are too large? Personally, I think switching to shared libraries will at this time introduce a lot more complaints that it will solve (and not because of a lack of a versioning system, but simply because the interface isn't anywhere near stable enough imho).
Jonas
Show quoted text 10 lines
> We need a version system.
That's not something "we" need, but which most OS'es need
(and don't provide, except for hacks like symlinks or
different filenames).
Moreover, it doesn't really solve much unless you like having
20 different versions of the same shared library on your
system (which would more or less defeat the purpose of saving
space, although it could still save memory if more than one
FPC program is running at the same time).
If I understand well what you mean, Vista has versioning of that kind, you can ask to see older versions of any file and restore the one you want. A small caveat is that for files that don't exist currently anymore (deleted) there's no GUI to get them (or one I haven't spotted yet) and you need to make a dummy file with same name, then right click it and go to Properties, then ask for the older versions (there's a special tab for that on the dialog). Not sure if the Basic version of Vista has this functionality available (I tried it with Vista Ultimate)
----------------
George Birbilis ()
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
Show quoted text 22 lines
> > We need a version system.
>
> That's not something "we" need, but which most OS'es need
(and don't
> provide, except for hacks like symlinks or different filenames).
> Moreover, it doesn't really solve much unless you like having 20
> different versions of the same shared library on your system (which
> would more or less defeat the purpose of saving space, although it
> could still save memory if more than one FPC program is
running at the
> same time).
If I understand well what you mean, Vista has versioning of
that kind, you can ask to see older versions of any file and
restore the one you want. A small caveat is that for files
that don't exist currently anymore (deleted) there's no GUI
to get them (or one I haven't spotted yet) and you need to
make a dummy file with same name, then right click it and go
to Properties, then ask for the older versions (there's a
special tab for that on the dialog). Not sure if the Basic
version of Vista has this functionality available (I tried it
with Vista Ultimate)
If you meant having many libs of different version exist side-by-side, .NET runtime supports it, but Win32 itself doesn't
George Birbilis wrote 25 lines
> > > We need a version system.
> >
> > That's not something "we" need, but which most OS'es need
> (and don't
> > provide, except for hacks like symlinks or different filenames).
> > Moreover, it doesn't really solve much unless you like having 20
> > different versions of the same shared library on your system (which
> > would more or less defeat the purpose of saving space, although it
> > could still save memory if more than one FPC program is
> running at the
> > same time).
>
> If I understand well what you mean, Vista has versioning of
> that kind, you can ask to see older versions of any file and
> restore the one you want. A small caveat is that for files
> that don't exist currently anymore (deleted) there's no GUI
> to get them (or one I haven't spotted yet) and you need to
> make a dummy file with same name, then right click it and go
> to Properties, then ask for the older versions (there's a
> special tab for that on the dialog). Not sure if the Basic
> version of Vista has this functionality available (I tried it
> with Vista Ultimate)
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.
Michael.
Yes, but especially with libraries where the developers have not committed to maintaining…
Show quoted text 33 lines
On 07 Feb 2007, at 21:45, Mattias Gaertner wrote:
>> In principle you should be able to do it with "make shared" in the
>> respective directories. But I would strongly recommend against
>> doing that, since the interface is by no means stable and
>> consequently programs compiled against both newer and older
>> rtl/fcl's are very likely to break if they use a different rtl
>> (and possibly fcl, since the fcl also uses rtl functionality).
>
> That's a general problem with libs, isn't it?
Yes, but especially with libraries where the developers have not
committed to maintaining backwards compatibility with a particular
interface and which are often changed in an ad hoc fashion. The main
problem is probably that we mix both general and compiler-specific
stuff in the system unit. It should probably be split into something
like gcc's libgcc.a (which contains compiler-specific helper
routines) and the system's libc dynamic library (system and generic
C language support) before the rtl is ever distributed as a shared
library.
> We need a version system.
That's not something "we" need, but which most OS'es need (and don't
provide, except for hacks like symlinks or different filenames).
Moreover, it doesn't really solve much unless you like having 20
different versions of the same shared library on your system (which
would more or less defeat the purpose of saving space, although it
could still save memory if more than one FPC program is running at
the same time).
What problem do you want to solve with having a shared library?
Plugins. For example installing a design time package. Contrary to normal apps an IDE has the advantage to recompile if needed. So Lazarus has only a subset of the normal dyn lib problems. But I know, that as soon as the IDE can load packages as dynamic libs, programmers will use dyn libs for their apps too and probably use them as shared libs. And then FPC+Lazarus bug tracker will get new trouble. So although I only want plugins, I ask about libs in general.
Show quoted text 6 lines
The
complaint that Lazarus programs are too large? Personally, I think
switching to shared libraries will at this time introduce a lot more
complaints that it will solve (and not because of a lack of a
versioning system, but simply because the interface isn't anywhere
near stable enough imho).
Mattias
Op Thu, 8 Feb 2007, schreef Mattias Gaertner:
Show quoted text 8 lines
Plugins. For example installing a design time package.
Contrary to normal apps an IDE has the advantage to recompile
if needed. So Lazarus has only a subset of the normal dyn lib problems.
But I know, that as soon as the IDE can load packages as dynamic libs,
programmers will use dyn libs for their apps too and probably use
them as shared libs. And then FPC+Lazarus bug tracker will get new
trouble. So although I only want plugins, I ask about libs in
general.
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.
Daniël
Daniël Mantione wrote 20 lines
Op Thu, 8 Feb 2007, schreef Mattias Gaertner:
> Plugins. For example installing a design time package.
> Contrary to normal apps an IDE has the advantage to recompile
> if needed. So Lazarus has only a subset of the normal dyn lib problems.
> But I know, that as soon as the IDE can load packages as dynamic libs,
> programmers will use dyn libs for their apps too and probably use
> them as shared libs. And then FPC+Lazarus bug tracker will get new
> trouble. So although I only want plugins, I ask about libs in
> general.
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 ? Borland does it.
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
XYZwill 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.
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. Borland's packages are also incompatible between released versions.
Michael.
Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
Show quoted text 9 lines
> 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.
Show quoted text 14 lines
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.
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 need.
Borland's packages are also incompatible between released versions.
Sure, but above you said Borland keeps them compatible.
Daniël
Daniël Mantione wrote 16 lines
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.
Yes.
Show quoted text 6 lines
> 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.
Exactly.
Neither does FPC. Not an offical release, anyway.
We don't release that much more often as Borland.
Show quoted text 18 lines
> 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 the IDE.
There is no way around it.
Show quoted text 6 lines
> 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
need.
I understand that, but this is not usable at all for an IDE based on class components.
> 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 packages.
Michael.
Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
Show quoted text 25 lines
> > 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
the IDE.
There is no way around it.
Yes, there is, we should not forget we have a facility in the language to solve this problem: interfaces. Both components in the IDE as in the plugin can implement the same interface, event though they have different VMT layouts.
So, a component that you place in the component palette implements some kind of "palette" interface, providing the IDE with the communications it needs to work with the component.
Daniël
Daniël Mantione wrote 38 lines
Op Thu, 8 Feb 2007, schreef Michael Van Canneyt:
> > > 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
> the IDE.
>
> There is no way around it.
Yes, there is, we should not forget we have a facility in the language
to solve this problem: interfaces. Both components in the IDE as in the
plugin can implement the same interface, event though they have different
VMT layouts.
So, a component that you place in the component palette implements some
kind of "palette" interface, providing the IDE with the communications it
needs to work with the component.
Nice idea, but I think you'll end up creating a set of interfaces which describes completely TCollection/TCollectionItem TPersistent and TComponent, plus you'll need to completely redesign streaming from the ground up, and that's not possible for Delphi compatibility. You would loose all existing Delphi components out there.
Not to mention that you cannot insert a non-tcomponent in the tComponent tree. And any 'component' from a package will be regarded as a non-tcomponent by the code from classes, so: no component on form, no streaming.
Delphi's IDE uses interfaces everywhere, but still assumes TComponent/TPersistent as the base classes.
Michael.
Why ? Borland does it. Secondly, there are serious problems with this approach which make…
On Thu, 8 Feb 2007, Dani?l Mantione wrote: > and LCL, which seems next to impossible to me. Why ? Borland does it.
Borland releases 13 versions in say 12 years, and no inbetween.
Most unixes also have it. The point is that it kind of defeats the purpose. Having 20+…
Michael Van Canneyt wrote 40 lines
On Thu, 8 Feb 2007, George Birbilis wrote:
>>>> We need a version system.
>>> That's not something "we" need, but which most OS'es need
>> (and don't
>>> provide, except for hacks like symlinks or different filenames).
>>> Moreover, it doesn't really solve much unless you like having 20
>>> different versions of the same shared library on your system (which
>>> would more or less defeat the purpose of saving space, although it
>>> could still save memory if more than one FPC program is
>> running at the
>>> same time).
>> If I understand well what you mean, Vista has versioning of
>> that kind, you can ask to see older versions of any file and
>> restore the one you want. A small caveat is that for files
>> that don't exist currently anymore (deleted) there's no GUI
>> to get them (or one I haven't spotted yet) and you need to
>> make a dummy file with same name, then right click it and go
>> to Properties, then ask for the older versions (there's a
>> special tab for that on the dialog). Not sure if the Basic
>> version of Vista has this functionality available (I tried it
>> with Vista Ultimate)
> 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.
Michael.
Is that so hard to use version system for rtl libraries ? I think that most of Lazarus end users will work with one fpc version and no other.
Lazarus developers still need fpc SVN and here is required a way to fast rebuild lazarus with fpc rtl which is nothing more that we are doing all the time now ;-) End users sometimes will need to rebuild lazarus and fpc also if some critical bugs are fixed in fpc but : is it something extraordinary ?
Am I missing something ?
Regards
Boguslaw Brandys
Borland releases 13 versions in say 12 years, and no inbetween.
Marco van de Voort wrote 5 lines
> On Thu, 8 Feb 2007, Dani?l Mantione wrote:
>> and LCL, which seems next to impossible to me.
> Why ? Borland does it.
Borland releases 13 versions in say 12 years, and no inbetween.
If Lazarus releases libs for every official FPC release wouldn't that be almost the same ?
Marc
Marc Weustink wrote 9 lines
Marco van de Voort wrote:
> > On Thu, 8 Feb 2007, Dani?l Mantione wrote:
> > > and LCL, which seems next to impossible to me.
> > Why ? Borland does it.
>
> Borland releases 13 versions in say 12 years, and no inbetween.
If Lazarus releases libs for every official FPC release wouldn't that be
almost the same ?
I think it would, yes. I think that is the way you should go.
If someone decides to use a custom version of FPC, he's on his own anyway.
Michael.
Is that so hard to use version system for rtl libraries ? I think that most of Lazarus…
Bogusław Brandys wrote 43 lines
Michael Van Canneyt wrote:
>
> On Thu, 8 Feb 2007, George Birbilis wrote:
>
> > > > > We need a version system.
> > > > That's not something "we" need, but which most OS'es need
> > > (and don't
> > > > provide, except for hacks like symlinks or different filenames).
> > > > Moreover, it doesn't really solve much unless you like having 20
> > > > different versions of the same shared library on your system (which
> > > > would more or less defeat the purpose of saving space, although it
> > > > could still save memory if more than one FPC program is
> > > running at the
> > > > same time).
> > > If I understand well what you mean, Vista has versioning of that kind,
> > > you can ask to see older versions of any file and restore the one you
> > > want. A small caveat is that for files that don't exist currently
> > > anymore (deleted) there's no GUI to get them (or one I haven't spotted
> > > yet) and you need to make a dummy file with same name, then right click
> > > it and go to Properties, then ask for the older versions (there's a
> > > special tab for that on the dialog). Not sure if the Basic version of
> > > Vista has this functionality available (I tried it with Vista Ultimate)
> > 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.
>
> Michael.
Is that so hard to use version system for rtl libraries ? I think that most of
Lazarus end users will work with one fpc version and no other.
I also tend to think so.
Show quoted text 8 lines
Lazarus developers still need fpc SVN and here is required a way to fast
rebuild lazarus with fpc rtl which is nothing more that we are doing all the
time now ;-) End users sometimes will need to rebuild lazarus and fpc also if
some critical bugs are fixed in fpc but : is it something extraordinary ?
Am I missing something ?
No. Your reasoning seems correct to me. Like I said: you need a versioning system. No big deal, we don't release official versions so often.
It just means you cannot mix the latest FPC with an 'official' lazarus release so easy. But my guess is that end users will not be so adventurous... :-)
I also don't upgrade my Delphi so often, exactly for this reason.
Since recompiling and loading custom packages will use the installed version of the libraries, there is no problem whatsoever: the versioning will be correct out of the box, since the IDE will point to the correct LCL packages...
Michael.
Most unixes also have it. The point is that it kind of defeats the purpose. Having 20+…
Show quoted text 20 lines
> 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 ()
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
Why ? Borland does it. Secondly, there are serious problems with this approach which make…
That this requires a strict versioning schedule, is part of the deal. Borland's packages are also incompatible between released versions.
Which is very bad practice for a commercial IDE (makes third-party commercial components support only some versions of Delphi [had suggested to Borland to sell a special bundle with all Delphi versions from 2 and up in it for component developers, but haven't seen this happen yet unfortunately]). Some people had used Delphi trial versions in the past to build resulting in their apps showing expiration messages later on (the RTL had this built in as it seems)
----------------
George Birbilis ()
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
Yes. Exactly. Neither does FPC. Not an offical release, anyway. We don't release that…
Show quoted text 6 lines
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 the IDE.
There is no way around it.
If you had an immutable Icomponent interface it could be. The IDE would talk to the components only using immutable (not-changeable once published) interfaces (Icomponent, IComponent2, IComponent3 etc.)
Show quoted text 12 lines
> > 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 packages.
don't take Borland as an example in this case, it's a very bad practice what they did...
----------------
George Birbilis ()
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
Nice idea, but I think you'll end up creating a set of interfaces which describes…
Show quoted text 19 lines
> So, a component that you place in the component palette implements
> some kind of "palette" interface, providing the IDE with the
> communications it needs to work with the component.
Nice idea, but I think you'll end up creating a set of
interfaces which describes completely
TCollection/TCollectionItem TPersistent and TComponent, plus
you'll need to completely redesign streaming from the ground
up, and that's not possible for Delphi compatibility. You
would loose all existing Delphi components out there.
Not to mention that you cannot insert a non-tcomponent in the
tComponent tree. And any 'component' from a package will be
regarded as a non-tcomponent by the code from classes, so: no
component on form, no streaming.
Delphi's IDE uses interfaces everywhere, but still assumes
TComponent/TPersistent as the base classes.
Could have some mechanism for TComponents that don't implement the IComponent to inject that functionality in them (maybe dynamically plug-in [best via the VMT, else partically via a special cast used only by the IDE] to the class an automatic IComponent interface implementation that implements IComponent by calling into Tcomponent.
Such components would have to be rebuilt with the same version as the IDE, but others that implement IComponent (or IComponent2 etc.) themselves could be shipped as binary ones (say for commercial or free components that give no source [say have option to buy the source]), as long as they only use interfaces to access the IDE and don't use any RTL functionality that has objects. Such objects could also embed (and static link) to their own (tried) RTL version instead of linking to the IDE's latest RTL (the 2nd case needs RTL to be available as package I suppose - but even then could have both a static RTL and a dynamic package for it [also such components could ship their own RTL package maybe and it could be used only by them inside the same process if some versioning and namespace mechanism is used])
Speaking of namespaces, Borland added concept (to support .NET) in latest Delphis I think, has FPC done similar yet? Could help in this case
----------------
George Birbilis ()
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
Op Fri, 9 Feb 2007, schreef George Birbilis:
Speaking of namespaces, Borland added concept (to support .NET) in latest Delphis I think, has FPC done similar yet? Could help in this case
It is on the "not to be supported" list (unless we have to decide to be Delphi .NET compatible). It won't help since namespaces have nothing to do with binary interfaces.
Daniël
Could have some mechanism for TComponents that don't implement the IComponent to inject…
Speaking of namespaces, Borland added concept (to support .NET) in latest Delphis I think, has FPC done similar yet? Could help in this case
We already have units, with etc? Maybe you want internal units ?
If you had an immutable Icomponent interface it could be. The IDE would talk to the…
Op Fri, 9 Feb 2007, schreef George Birbilis:
don't take Borland as an example in this case, it's a very bad practice what they did...
I wouldn't go that far; solving OOP binary compatibility is hard and Borland did contribute to the solution by including interfaces into the language, but after Delphi got big and there were tons of components out there.
However, if Lazarus can solve it, they should do so.
Daniël