[Lazarus] "Running" a library

[Sven Barth]

On 15.09.2012 13:19, Sven Barth wrote:
> On 15.09.2012 13:12, Mark Morgan Lloyd wrote:
>> Sven Barth wrote:
>>> On 15.09.2012 12:36, Mark Morgan Lloyd wrote:
>>>> Sven Barth wrote:
>>>>
>>>>>> /Why/ can't a library be run standalone? We're already at the
>>>>>> position
>>>>>> that an executable can decide whether it's been invoked from a
>>>>>> shell or
>>>>>> the GUI and behave as appropriate, so why can't it decide whether
>>>>>> it's
>>>>>> being run as a program or being initialised as a library?
>>>>>
>>>>> A library and an application have different entry point signatures.
>>>>> Take Windows for example. There the entry point for applications is
>>>>> "procedure EntryPoint; stdcall;" while for DLLs it is "procedure
>>>>> EntryPoint(aHinstance: PtrInt; aDLLReason: Word; aDLLParam: Pointer);
>>>>> stdcall;". Additionally the entry point of a DLL is called multiple
>>>>> times (once the process loads the library, every time a new thread is
>>>>> created and destroyed and once the process unloads the library) while
>>>>> the entry point of an application is only called once. Also AFAIK
>>>>> Windows does not let you run binaries that are flagged as "DLL".
>>>>> That's the reason why there is a program called "rundll32" ;) [though
>>>>> it expects an exported function with a certain signature...]
>>>>
>>>> Assuming for a moment that a binary can be built that is basically an
>>>> executable but also exports library-style entry points, and which could
>>>> be loaded into memory using DynLib or whatever: could the
>>>> initialisation
>>>> function be told to return fast and cleanly if it detected that it
>>>> wasn't being run as a program? In that case, the caller could use
>>>> DynLib
>>>> to load it and then invoke a different entry point explicitly to handle
>>>> initialisation.
>>>>
>>>
>>> You are able to define exports from a program. And you can also load
>>> the program binary using LoadLibrary from a library that is already
>>> loaded from that program (because the entry point is not called then),
>>
>> I'm already calling from a loaded library back into the calling program
>> using that technique. What happens if a library tries to load a
>> /different/ program: is the main entry point called and are the
>> subsidiary entry points available?
>>
>
> I currently only have one answer for that: try it and see what happens.

I have now checked ReactOS' code: if you load an exe that is not the 
main executable then the entry point won't be called at all. So it seems 
that you can load such executables and call functions from them, but in 
the case of FPC you might be screwed (or at least very restricted) as 
the initialization sections of the units won't be run (this includes the 
system unit which initializes the heap, io, etc.).

Regards,
Sven