[Lazarus] LCL and DLLs, initializing the widget set safely?

[Marco van de Voort]

On Wed, Dec 09, 2009 at 10:01:22AM +0100, Mattias Gaertner wrote:
> > On Tue, Dec 8, 2009 at 11:39 PM, Marco Alvarado <cronodragon at gmail.com> wrote:
> > > I'm really happy to inform that I solved the bug, and now I have a
> > > working version of LCL 0.9.28.2 in DLL. It seems the fix might not be
> > > difficult for someone who understands the LCL's internals. I'll
> > > explain what I did hoping someone could work on it.
> > >
> > 
> > Am I wrong or this cannot be really fixed unless a Delphi-like package
> > system is implemented?
> 
> Delphi like packages makes many things easier like calling the
> initialization/finalization sections in the right order and only once.
> You can emulate this.

(one can emulate pascal in asm :-)

> The most important thing is sharing the VMTs and global variables.
> This can not be emulated.
> The shared VMTs and global variables are needed, when you
> want to use a LCL form of a DLL in a LCL application.

Well, all kinds of mix forms are possible and parts can be emulated. They
either require a lot of handcoding, manualy project management, flattening
etc. 


If you take the basic premise that any symbol only exists once in all
binaries (.exe+dll), then a VMT is just an external symbol, just like
vars, procedures and functions.  

So you need all symbols that should be externally callable, and need to
generate export sections for every binary format for them. Also possibly
deal with schemes that make sets of symbols somewhat version independant
(all kinds of late binding)

However you are likely to get stuck if you really try to scale up the minor
experiments one platform that people echo from time to time. You need a bit
of luck here, not too complicated usage there, and only one platform since
that other platform needs an indirection for a certain symbol kind to make
it exportable etc.

The experiments are interesting though (specially the recent very long
shared library bugreport with lots of packages) since they make a clearer
picture of what _details_ need to be done for packages (even though the big
picture is clear).

> I didn't try, but it should be possible to put an LCL application into
> a dynamic lib on all platforms and accessing it only via pointers.
> And with various hacks it is possible to share more.
> 
> The main problem is, that the guys knowing the compiler and linker
> issues, thinks that the disadvantages of packages outweighs the
> advantages, so it is not worth implementing.

Packages are something awfully magical to many people. But the base
principles of (non dynamical loadable) packages are not that dramantic:

- A symbol only exists once.   Takes care of duplicate RTL state and 
       VMT problems.
- one clear initialization sequence, possibly as close as possible to the
  undivided binary. Additional tables need to be generated for this.
- enough meta info and project files to make the whole process compiler
   controlled instead of hand crafted. The compiler oversees the entire
   process of .bpl (.fpl?) and .exe, and thus has .ppu's for the .fpl's.
- (FPC extra requirement) solution must be portable

Cutting corners by working around explicit compiler support will only result
in an unsupportable mess.