On Wed, Dec 09, 2009 at 10:01:22AM +0100, Mattias Gaertner wrote: > > On Tue, Dec 8, 2009 at 11:39 PM, Marco Alvarado <cronodra...@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. -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus