RTL: export/import WriteLn ?

[paule32]

Hello,
how can I export/import WriteLn from a DLL ?

[MarkMLl]

You mean export it from the DLL to the main program? You can't, because it's a "special" with an indeterminate number of parameters of indeterminate types.

What are you trying to do (and usual things: what OS, what version FPC and so on).

MarkMLl

[cdbc]

Hi
The 'Read(Ln)' and 'Write(Ln)' are fpc 'intrinsics' - to you "Magic"

how can I export/import WriteLn from a DLL ?

IMHO the closest you can come, is to emulate them with 'Args: array of const'.
Regards Benny

[paule32]

@Mark
I try to implement a own RTL with Classes, not only Functions/functional programming...
At least, to save disk space.

Currently, the DLL is 111.000 KB.
Currently, the EXE is   50.000 KB.

With UPX,
the DLL is 42.000 KB.
the EXE is 20.000 KB.

All rounded Values, to simplyfied the demonstration there.

[MarkMLl]

Right, so for the moment at least the OS etc. doesn't matter.

You can't describe Write(), WriteLn(), Read() and ReadLn() from J&W Pascal as standard functions, because (as CDBC says) they require compiler "magic" to handle their parameters both because of the imprecise number/types and the : suffix used to indicate precision (which also obviously affects Str() in later implementations).

All highly regrettable, but as I've previously said Pascal was a rush job to preempt ALGOL-68.

Format() in Object Pascal has similar vagueness in the type of the parameters, but at least that requires that they are specified as an uncounted list and specifies the precision in an FORTRAN/ALGOL/C-style format string.

I suspect that System (as distinct from the remainder of the RTL) can't be linked dynamically, but it would be interesting to see what Sven (or another local compiler guru) has to say about it.

MarkMLl

[marcov]

Writeln calls helpers. Simply export all helpers from the DLL, and call them from stubs  in the non DLL rtl(*).  But of course for any dynamically allocated type you must somehow join the memory managers.

(*) This because I assume the compiler won't suddenly start generating DLL calls.

[cdbc]

Hi
When @marcov says

But of course for any dynamically allocated type you must somehow join the memory managers.

I think he means, if on winders - take a look at 'ShareMem' from the winders section of the source-code, you need to compile the dll, or if on Unices / Linuces, take a look at 'cmem'.
They'll help you to work with a shared memory-manager.
Regards Benny

[paule32]

I waste many times with Fibonacci, and came to the conclusion, that is it not a good idea to code from scratch.
Because I stuck into Problems with wrong Function Import Headers, which results into a crash of the Application - the good know 0x7b thing.

So, I see, that it is better to start with ground base.
But I can see, that some Start-Parameters for fpc does not take in effect.

So, when I use -CD, I have a smaller DLL as without this Parameter, but the DEF file will not generate.
My way is then, to write the EXPORT DEF File and the Functions per Hand and create a import .A file with dlltool.exe.

The current thing what I do is, to export the CLASS Create CTORS and DTORS with global functions, and procedures.
Functions for CTORs, and procedures for DTORs.
Then in a second step, I import these Functions/Procedures into a seperate Import Class.

This results then into smaller files.

I have not a Roadmap or anything of this, so all is alpha testing  ...

[PascalDragon]

I suspect that System (as distinct from the remainder of the RTL) can't be linked dynamically, but it would be interesting to see what Sven (or another local compiler guru) has to say about it.

Well, with dynamic packages it's possible, however it's not dynamic linking, but shared linking then. Though the RTL package is bigger, because it can't smartlink away unused functions as some other program might import a function that the program might not use.

[paule32]

does FPC distinguish between dynamic packages, and dynamic libraries like .so or dll ?
what are the differences ?

I know packages from BORLAND Delphi as resource DLL.

[PascalDragon]

does FPC distinguish between dynamic packages, and dynamic libraries like .so or dll ?
what are the differences ?

I know packages from BORLAND Delphi as resource DLL.

If you have a program and a library that both use unit A then both will contain a copy of that unit. If unit A is part of a dynamic package and both the program and the library use the package then they will not contain the unit at all and it will instead only reside in the package. Also packages contain metadata for retrieving the contained units so that the correct units can be initialized when the package is dynamically loaded. A dynamic package is based on shared libraries, but it's more than just that. And the same is true for Delphi, they are not just a "resource DLL".