Quick start manual

Libraries and packages 9-9
Writing dynamically loadable libraries
Exceptions and runtime errors in libraries
When an exception is raised but not handled in a dynamically loadable library, it
propagates out of the library to the caller. If the calling application or library is itself
written in Delphi, the exception can be handled through a normal try...except
statement.
Note Under Linux, this is only possible if the library and application have both been built
with the same set of (base) runtime packages (which contains the EH code) or if both
link to ShareExcept.
On Windows, if the calling application or library is written in another language, the
exception can be handled as an operating-system exception with the exception code
$0EEDFADE. The first entry in the ExceptionInformation array of the operating-system
exception record contains the exception address, and the second entry contains a
reference to the Delphi exception object.
Generally, you should not let exceptions escape from your library. On Windows,
Delphi exceptions map to the OS exception model; Linux does not have an exception
model.
If a library does not use the SysUtils unit, exception support is disabled. In this case,
when a runtime error occurs in the library, the calling application terminates.
Because the library has no way of knowing whether it was called from a Delphi
program, it cannot invoke the application’s exit procedures; the application is simply
aborted and removed from memory.
Shared-memory manager (Windows only)
On Windows, if a DLL exports routines that pass long strings or dynamic arrays as
parameters or function results (whether directly or nested in records or objects), then
the DLL and its client applications (or DLLs) must all use the ShareMem unit. The
same is true if one application or DLL allocates memory with New or GetMem which
is deallocated by a call to Dispose or FreeMem in another module. ShareMem should
always be the first unit listed in any program or library uses clause where it occurs.
ShareMem is the interface unit for the BORLANDMM.DLL memory manager, which
allows modules to share dynamically allocated memory. BORLANDMM.DLL must
be deployed with applications and DLLs that use ShareMem. When an application or
DLL uses ShareMem, its memory manager is replaced by the memory manager in
BORLANDMM.DLL.
Note Linux uses glibc’s malloc to manage shared memory.