[Lazarus] RE : Forms in DLL

Marco van de Voort marcov at stack.nl
Wed Aug 17 16:06:09 CEST 2011


On Wed, Aug 17, 2011 at 11:11:01AM +0200, Michael Schnell wrote:
> The Plus is that it just works, the Minus is that the interface between 
> the program and the SO always needs to be "flat" (just using simple C 
> compatible types, no Objects no Pascal Strings etc.)

This is not entirely true. _ANY_ RTL state is duplicated. This means that
other process resources like e.g. standard I/O handles are also only usable in a
very limited manner.

This also goes for the thread implementation, though I'm not sure about
this, see below.
 
> A SO can use threads to implement "free running" activities. AFAIK, you 
> can use TThread instances for this, but any normal (portable, 
> LCL-defined) communication with the main Thread (such as 
> TThread.Synchronize and Application.QueueAsyncCall) is not allowed.

I'm not even sure if tthread is allowed. What was your testprogram?
 
> Here it is highly desirable to use a non-flat interface, communicating 
> objects and Pascal stings. This in fact is possible (I did test it with 
> Delphi but AFAIK something similar is provided for Lazarus/FPC as well) 
> by using a memory manager in the SO that hooks into the main program's 
> memory manager.

I've told you already a thousand times that this ONLY fixes the state of the
memory manager, not the rest of the RTL and LCL state. Thus this will solve
nothing, since there are still two different copies of the sysutils state
that handles the message pump. (and the LCL parts that actually implement
it)

So yes, it solves the ansistring problem, no it doesn't solve the
.synchronize problem.

> project prototype that allows for all this in a decently reliable and 
> verified and portable way.

The only safe solution is to avoid any duplicated state, RTL or LCL.

But that is not a matter of project, but of engineering, and a bit of
engineering that is waiting for sb to implement it.

It is not a matter of project, since a project in lazarus can only
instrument the FPC compiler and RTL, and for this to be resolve, massive
changes to those are needed first.
 




More information about the Lazarus mailing list