How to build DLL Files for Windows Desktop ?

[paule32]

@rvk

Yes this is okay.
Under Windows, the Loading of DLL Files have different State of "load", and "un-load".

So (I don't sure at current Time) DLL has 3 or 4 Functions:
- at load
- attach
- de-tach
- un-load

And since FPC create the global Symbol PASCALMAIN (for .EXE, and .DLL), I simply could created a Wrapper .o(bject) File, that includes the Entry Function for loading DLL's under Windows, that call the PASCALMAIN global Symbol.

The file, I used for, is sources\fpc-rtl\RTL_crt.o

You can follow the build.bat - which is the Creation Batch-File for Win32 Command Line Interface (CLI).

[srvaldez]

it seems that lazarus ignores the export section and doesn't build a proper dll but FPC does.

[paule32]

Lazarus was develop with FPC.
So, FPC is the Motor under the Hub of Lazarus.
So, FPC is a stand alone Application.
So, Lazarus is a stand-alone Application, that Create Pascal-Code, which is compiled with FPC.
So, Lazarus has (indirekt) nothing to do with FPC (written naively).

[marcov]

Lazarus was develop with FPC.
So, FPC is the Motor under the Hub of Lazarus.
So, FPC is a stand alone Application.
So, Lazarus is a stand-alone Application, that Create Pascal-Code, which is compiled with FPC.
So, Lazarus has (indirekt) nothing to do with FPC (written naively).

No. Lazarus just calls the FPC commandline compiler. Projects even have an option to show the synthesised commandline.  Lazarus projects do default to a different mode, mode objfpc, and thus pass -S2 unless you change it (like I do to $mode Delphi)

[paule32]

@marrov

funny.
That is what I write: The Motor under the Lazarus Hub is FPC 

[rvk]

Under Windows, the Loading of DLL Files have different State of "load", and "un-load".
So (I don't sure at current Time) DLL has 3 or 4 Functions:

So your dllmain is called 4 times.
Great... it works... 

https://learn.microsoft.com/en-us/windows/win32/dlls/dllmain

[marcov]

(I'm not sure why the winmain variants are still in the DLL code. Aren't those for win9x, which we haven't supported for 9 years ?)

[paule32]

WinMain is for Windows GUI ExEcutables
DlllMain is for Windows DLLibraries
main is for CRT - Console Application's

FPC produce Code with PASCALMAIN, which is besides _mainCRTstartup the main Symbol - not only for .ExE, but for .DLL, too.

So, it is easy to call a LD (Linker) Script.

[marcov]

WinMain is for Windows GUI ExEcutables
DlllMain is for Windows DLLibraries
main is for CRT - Console Application's

I mean (from rtl/win64/sysinit.pp:

Code: [Select]

    procedure _FPC_DLLMainCRTStartup(_hinstance : qword;_dllreason : dword;_dllparam:Pointer);stdcall;public name '_DLLMainCRTStartup';
    begin
      IsConsole:=true;
      sysinstance:=_hinstance;
      dllreason:=_dllreason;
      dllparam:=PtrInt(_dllparam);
      SetupEntryInformation;
      DLL_Entry(SysInitEntryInformation);
    end;

    procedure _FPC_DLLWinMainCRTStartup(_hinstance : qword;_dllreason : dword;_dllparam:Pointer);stdcall;public name '_DLLWinMainCRTStartup';
  // same code as above


FPC produce Code with PASCALMAIN, which is besides _mainCRTstartup the main Symbol - not only for .ExE, but for .DLL, too.

I was refering to the _DLLWinMainCRTSTartup  vs the _DLLMainCRTStartup. The win9x thing was a guess. If you know why there are two similar symbols, let's here it. (Probably I should read Rik's link :-)

So, it is easy to call a LD (Linker) Script.

Using LD.exe is atypical. Windows users have used the internal linker since its emergence in 2007.

[paule32]

The first Potential of FPC is, to {$define macro}, which let me decide - when I would like compile a .ExE or .DLL.
The second Potential of FPC is (based on the first Advantage), that I can so modularize/outsource Code from .ExE to a shared .DLL.

They are different _mainCRT... , and _DLLMain ... , yes.
But I can use the above described Macros, to create a (Header "interface" where the Function's/Procedure's Signatures resides, and a Body "implementation" where the Code for the "pre-defined" Function's/Procedure's stay).

I can see, that the original Implementation of FPC_DLLMain is wrong.
Because the Entry (Procedure should be a Function that return BOOL).

[PascalDragon]

I was refering to the _DLLWinMainCRTSTartup  vs the _DLLMainCRTStartup. The win9x thing was a guess. If you know why there are two similar symbols, let's here it. (Probably I should read Rik's link :-)

_DLLWinMainCRTStartup is used for GUI libraries, _DLLMainCRTStartup is used for Console libraries (for libraries it arguably makes not that much of a difference (except for initializing the error I/O), but it at least allows to check whether the library had been compiled as the one or the other).