[fpc-devel] Discussion about "Dynamic packages"

[Sven Barth]

Am 13.04.2017 08:44 schrieb "Bishop via fpc-devel" <
fpc-devel at lists.freepascal.org>:
> At first I would like to designate a circle of tasks which in principle
can effectively decide by means of system of dynamic packets. Lets remember
for what DLL`s and SO`s was be created. It was for memory saving (by
sharing code and static conts parts from many applications in memory). Now
there is so many memory even on phones, that this almoust have no sence
(its still work for things like LibC, ZLib and so.). But this kind of
libraries better make with C-style interface (or use COM/CORBA interfaces
like in DirectX if it`s realy needed). Yes, sometimes someone make
libraries for C++ only, but it because of a dominant position of this
language. Pascal didn`t have it. So, as i think, dynamic packages can be
usefull only for something like plugin system in editors like 3Ds Max,
Photoshop and etc.
The intended purpose of dynamic packages (and libraries in general) is not
to save memory (in fact a binary plus packages would be much larger than
the statically compiled binary), but to share *binary* code so that this
code does not need to reside in multiple executables.

> But Sven Bart wrote that "Package libraries can however only be used by a
binary compiled with the same compiler as they rely on quite a bit of
compiler magic.", so they be usefull only for projects that target to have
plugins writed in pascal only. I try to say, that there is not so many
situations that we realy need this system. I dont say that we dont need it
at all, no. But disadvantages from this system must no effect on all other
projects. This why i have some propositions.

Yes, they are specifically for Pascal code and more specifically only FPC
code as you can't use a Delphi dynamic package with FPC or the other way
round.
Plugin systems are indeed one of the uses of dynamic packages (with the
main benefactor probably being Lazarus), but as I wrote above sharing of
binary code is also an important point. Especially if your own "product"
consists of multiple executables that share the same code.

> Во время моего общения с Sven Barth он писал "With dynamic packages you
can share classes, strings, memory, etc. between the modules (the main
binary and the different package libraries)". Let's look at the most
widespread operating systems. This will be Windows and Unix-family. In
Windows every application starts from ntdll.dll and walk via kernel32.dll
and only after that go to "main"-function in EXE file. So kernel32.dll
always loaded. And its already have not bad memory manager (Process heap
functions group). Why dont use it? It allow share memory with C code too
(and strings with pascal code). Its already exist in application memory. In
Linux if application use shared libraries it use libdl.so witch need
libc.so. So we already have libc heap. As i know in FreeBSD and Solaris
situation same.

It isn't merely the memory management. The Object Pascal RTL exists of much
more than just memory management: there is exception handling, the RTTI,
resource strings, unit initialization and finalization. This are all thing
that other languages either have no clue about (e.g. C) or have their own
implementations anyway.
Also while using the memory manager of the system (which you can by the way
by using the "cmem" unit) will allow you to share strings (and other
allocated memory) between libraries it doesn't magically allow C or C++
code to understand Pascal strings.

> And the second of my proposal it make dynamic packages like 2nd way in
compiler (like it maked in MSVS where we can select link CRT staticaly or
dunamicaly). Add some switch to compiler (and have 2 compiler variants of
RTL, now we have this in RTL source with {$IFDEF FPC_3_0_0} macro) that
will allow generate or not generate compiler magic for dynamic packages.
They need in not so many cases, but all this indirect memory accesses make
all applications slow (memory, first of all memory latency, in bottleneck
of all today computers).

Units are compiled in a way that they can be used inside a package and (as
it is now) outside of it. Whether your executable uses dynamic packages or
not is determined merely by a compile time option of your executable
(namely if you specify to use a dynamic package using -FP, e.g -FPrtl).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20170413/d23e8ff1/attachment.html>