[Lazarus] Updating an app "on the fly"

[Marco van de Voort]

On Sat, Jun 19, 2010 at 12:34:34PM +0000, Mark Morgan Lloyd wrote:
> > For example, Packages share the same memory space and class inheritance 
> > tree.
> > Libraries do not.
> 
> Thanks both. So if I understand things correctly:
> 
> * A package uses the same LCL as the rest of the app.

Yes. Both code and state. The code part also contains the VMTs, which must
be the same to make IS and AS work.
 
> * A library (standard dll/so) has a distinct LCL.

Yes. Both code and state. (iow they can have different LCL versions)

Some people think that state is only the heapmanager, but it is also
localisation, threadvars etc.
 
> * Static package loading is currently supported.

Static packages are nothing more than a fancy word for groups of units.

> * Package loading under control of the app (i.e. to implement plugins 
> etc.) is not currently implemented.

Correct.
 
> I believe that I've dynamically-loaded (Linux) libusb under program 
> control before now but I'd need to look closely at my code to be 
> absolutely certain (and to work out how I did it). Somebody on CIX 
> contributed a Win-32 dynamic-library object which can be trivially 
> subclassed to describe e.g. the WinSock DLL.

FPC loads foreign libraries externally all the time. But you also don't
communicate on Pascal level between with them, and keep the RTL/libc states
totally apart.

I refer to this as the "manual" solution. (which is btw not as easy as many
people think, specially for large complicated frameworks like LCL)

The clue from packages (on the Pascal level) is (from
http://wiki.freepascal.org/packages ):

that packagesallows to split up a program into modules by just grouping units,
and satisfying unit dependancies. Not by reengineering the interface between
modules. IOW it is transparent, and there are relative few things that can
go wrong.