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.
Will do, but not today. I'll report back.
but you can not build an application that can be used also as a
dynamic library, because as I already wrote the entry point signatures
are different and thus if you would e.g. use the DLL's signature for
the program your code would expect parameters (aHinstance, aDLLReason
and aDLLParam) where the OS did not pass you anything ( => stack
corruption).
Although the called code might be able to determine that the parameters
aren't valid and react accordingly, and being stdcall (unless my
understanding is outdated) it's the caller that restores the stack state.
In cdecl it's the caller, because of varargs functions which are not
possible with e.g. stdcall as there the callee is responsible.
Thanks for refreshing my memory.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
