How to build DLL Files for Windows Desktop ?

[CCRDude]

Your test1.pas declares "test" ("zum") as stdcall. Your test2.pas doesn't export it as stdcall (thus probably using the default, register). Not adhering to calling conventions is always a bad idea.

[rvk]

So my guess is, that FPC does not Handle the EXPORTS keyword correctly.

You mean your rtl code doesn't handle EXPORTS correctly.
You completely cut out the FPC code.

If you compile this with standard FPC it works, doesn't it??

[paule32]

@rvk

hat did you mean with Standard FPC ?
The Original FPC.EXE ?

Yes, it is the Original not patched FPC.EXE (Compiler).

The Code works, except "external" usage.

AND: It should not does make a matter, if the Code come from the Original RTL or not.
I claim, that FPC.EXE could Compile it self - like all other DSL can do this that I know.

[440bx]

Attached are the code snippets you posted with the necessary modifications to make them compile and execute properly.

Basically, it's the same code you posted with the addition of "uses Windows;". Both, the program and dll are included.  Compile them and run them.

HTH.

[rvk]

hat did you mean with Standard FPC ?
The Original FPC.EXE ?

I don't mean the compiler.
I mean that you change all the system files (RTL) which your program uses.
So also the loading of LoadLibrary etc.

If you change the MessageBox to a writeln, compile the dll and the test program with standard RTL from FPC, it works fine.

So the problem is in your own RTL you wrote !!
(probably somewhere around the loadlibrary or dynamically calling of it.)

This works fine in standard FPC.

Code: Pascal  [Select][+][-]

1. {$mode delphi}
2. library test2;
3.  
4. procedure test; export;
5. begin
6.   writeln('test');
7. end;
8.  
9. exports test;
10.  
11. end.

Code: Pascal  [Select][+][-]

1. {$mode delphi}
2. program test1;
3.  
4. procedure zum; stdcall; external 'test2.dll' name 'test';
5.  
6. procedure test;
7. begin
8. writeln('hallo');
9. zum;
10. end;
11.  
12. begin
13.   test;
14. end.

stdcall doesn't make a difference in FPC x64 I thought.

[marcov]

Calling conventions shouldn't matter on x64, but it is symptom of a messy style.

But yes, being consequent in fixing wrongs might help bringing this mess up to spec. Maybe calling convention does matter which mangled name is generated. (decoration and the like).

So at least the windows api functions should be stdcall.

For the rest studying the FPC RTL (that does work) and minimizing bit by bit rather than stuffing a bunch of untested code through an assembler with unknown status, would be the logical way to get further here.

And, as said,  I have sincere doubts about the usage of nasm. That is not something used for production, and with -Anasm*  the source afaik does go through nasm to produce .o's. And the NASM generated files might do something that confused the internal linker (that is meant for FPC internal assembler  generated files)

[Thaddy]

So at least the windows api functions should be stdcall.

On win32, yes.
It is better to uses winapi everywhere.
This is not only for windows as the name would suggest but is applicable anywhere.
winapi chooses the correct calling convention for any ABI.
https://wiki.freepascal.org/FPC_New_Features_3.2.0#Support_for_WinAPI_directive

Saves a hell of a lot  of ifdefs...

[marcov]

So at least the windows api functions should be stdcall.

On win32, yes.
It is better to uses winapi everywhere.
This is not only for windows as the name would suggest but is applicable anywhere.
winapi chooses the correct calling convention for any ABI.
https://wiki.freepascal.org/FPC_New_Features_3.2.0#Support_for_WinAPI_directive

That text is of course wrong. You see the glaring mistake?

[Thaddy]

apart from off -> for? Not immediately, no.
Maybe the claim that everything else is cdecl? (Which it isn't, but the directive behaves correct)

[marcov]

apart from off -> for? Not immediately, no.
Maybe the claim that everything else is cdecl? (Which it isn't, but the directive behaves correct)

Other way around. Not all Windowses are stdcall. Wince is cdecl. Just messing with ya :-)

[rvk]

At least the calling convention doesn't make a difference in this case.
Even with stdcall in the dll it errors on running of test1 (Bad Image: Error status 0xc000007b).
(so there is definitely something wrong in the custom RTL.)

[paule32]

what about Assembly ?
How can I use the Command Line, to generate only Assembly for DLL ?
I tried -Xe but I get Entry Error.
In my system.pas:

Code: Pascal  [Select][+][-]

1. {$ifdef windll}
2. procedure Entry; [public, alias: '_DLLMainCRTStartup'];
3. begin
4. MessageBox(0,'llllllllllloooooooo','11111',0);
5.     PascalMain;
6. end;
7. {$endif}

using to try compile Options:

Code: [Select]

C:\lazarus\x86_64\fpc\3.2.2\bin\x86_64-win64\fpc.exe -Twin64 -Mdelphi -dwindows -dwin64 -v0 -Fi..\fpc-win -O2 -Os -vl -Xe -Anasmwin64 -al -Fu..\units\fpc-rtl -Fu..\units\fpc-sys -Fu..\units\fpc-win -Fu..\units\fpc-qt -dwindll -Fu.\units -FE.\units test2.pas
Free Pascal Compiler version 3.2.2 [2022/09/24] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
2 205/1.248 Kb Used
C:\lazarus\x86_64\fpc\3.2.2\bin\x86_64-win64\ld.exe: warning: cannot find entry symbol _DLLMainCRTStartup; defaulting to 0000000010001000

[marcov]

Use assembly in Pascal source. That is output directly to .o

[paule32]

sane Error, when I try to compile:

Code: Pascal  [Select][+][-]

1. procedure DLLMainCRTStartup; assembler; public name '_DLLMainCRTStartup'; asm ret end;

[rvk]

@paule32 I did a little test.

I created the test2.dll with normal FPC and the test1.exe with your RTL.
That works fine. Test2.dll is loaded fine and executes properly.

Now I created the test2.dll with your RTL and the test2.exe with normal FPC.
And the error also happend.

So it's the test2.dll with your RTL that's the problem.
(probably something with the DLL creation, because Windows also stated bad image, and that's the image of test2.dll it tries to load)

So you need to concentrate on the DLL, not the test1 app which loads the dll.