How to: create DLL file for Windows 10 64-Bit Pro

[paule32]

The following will crash the application ( WriteFile  Lines: 86 ):

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

1. ...
2. function CreateFile(
3.     lpFileName            : LPCSTR;
4.     dwDesiredAccess       : DWORD;
5.     dwShareMode           : DWORD;
6.     lpSecurityAttributes  : PSECURITY_ATTRIBUTES;
7.     dwCreationDisposition : DWORD;
8.     dwFlagsAndAttributes  : DWORD;
9.     hTemplateFile         : THandle): THANDLE;
10.     stdcall; external 'kernel32.dll' name 'CreateFileA';
11.  
12. function SetFilePointer(
13.     hFile                : THandle;
14.     lDistanceToMove      : Longint;
15.     lpDistanceToMoveHigh : Pointer;
16.     dwMoveMethod         : DWORD): DWORD;
17.     stdcall; external 'kernel32.dll' name 'SetFilePointer';
18.    
19. function WriteFile(
20.     hFile          : THANDLE;
21.     const lpBuffer ;
22.     nBytesToWrite  : DWORD;
23.     nBytesWritten  : DWORD;
24.     lpOverlapped   : POverlapped): BOOL;
25.     stdcall; external 'kernel32.dll' name 'WriteFile';
26.    
27. function CloseHandle(
28.     hObject: THANDLE): BOOL;
29.     stdcall; external 'kernel32.dll' name 'CloseHandle';
30. ...
31.  
32. function PutToFile(const AFileName: LPCSTR; AData: LPCSTR): Boolean;
33. var
34.     hFile    : THandle ;
35.     count    : Cardinal;
36.     dataSize : Integer ;
37.    
38.     overlap  : POverlapped;
39.     dummy    : DWORD;
40.     error    : DWORD;
41. begin
42.     result   := false;
43.     dataSize := strlen(AData);
44.  
45.     hFile := CreateFile(
46.         AFileName,              // name of the file
47.         GENERIC_WRITE,          // open for writing
48.         FILE_SHARE_READ or FILE_SHARE_WRITE,
49.         nil,                    // default security
50.         OPEN_EXISTING,
51.         FILE_ATTRIBUTE_NORMAL,  // normal file
52.         0);
53.  
54.     if hFile = INVALID_HANDLE_VALUE then
55.         hFile := CreateFile(
56.         AFileName,
57.         GENERIC_WRITE,
58.         FILE_SHARE_READ or FILE_SHARE_WRITE,
59.         nil,
60.         CREATE_NEW,
61.         FILE_ATTRIBUTE_NORMAL,
62.         0);
63.  
64.     if hFile = INVALID_HANDLE_VALUE then begin
65.         MessageBox(0,
66.         'file: fpc_rtl.$$$ could not be write.',
67.         'Error', 0);
68.         ExitProcess(1);
69.     end else begin
70.         dummy := MessageBox(0,
71.         'CreateFile() success',
72.         'Information', 0);
73.         dummy := SetFilePointer(hFile, 0, nil, FILE_END);
74.         error := GetLastError;
75.        
76.         if ((dummy = INVALID_SET_FILE_POINTER) and (error = NO_ERROR)) then begin
77.             dummy := MessageBox(0,
78.             'SetFilePointer() failed.',
79.             'Information', 0);
80.             ExitProcess(1);
81.         end else begin
82.             dummy := MessageBox(0,
83.             'SetFilePointer() success.',
84.             'Information', 0);
85.  
86.             // next step will crash the app ...            
87.             dummy := WriteFile(hFile, adata, dataSize, 0, overlap);
88.             error := GetLastError;
89.            
90.             if error <> 0 then begin
91.                 dummy := MessageBox(0,
92.                 'WriteFile() failed.',
93.                 'Information', 0);
94.                 ExitProcess(1);
95.             end else begin
96.                 dummy := MessageBox(0,
97.                 'WriteFile() success.',
98.                 'Information', 0);
99.             end;
100.         end;
101.     end;
102.     if CloseHandle(hFile) = 0 then begin
103.         MessageBox(0,
104.         'CloseHandle() failed.',
105.         'Information', 0);
106.         ExitProcess(1);
107.     end else begin
108.         MessageBox(0,
109.         'CloseHandle() success.',
110.         'Information', 0);
111.     end;
112.     result := true;
113. end;

The Windows Event-Manager informations:

Code: Text  [Select][+][-]

1. Name der fehlerhaften Anwendung: test1.exe, Version: 0.0.0.0, Zeitstempel: 0x00000000
2. Name des fehlerhaften Moduls: KERNELBASE.dll, Version: 10.0.22000.2538, Zeitstempel: 0x06aca232
3. Ausnahmecode: 0xc0000005
4. Fehleroffset: 0x00000000000436a6
5. ID des fehlerhaften Prozesses: 0x126c
6. Startzeit der fehlerhaften Anwendung: 0x01da918f7f387e6f
7. Pfad der fehlerhaften Anwendung: E:\Projekte\fpc-qt\src\tests\test1.exe
8. Pfad des fehlerhaften Moduls: C:\Windows\System32\KERNELBASE.dll
9. Berichtskennung: 49a6db74-6df0-48a3-826e-e91fa755d3ed
10. Vollständiger Name des fehlerhaften Pakets:
11. Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

Code: Text  [Select][+][-]

1. Fehlerbucket 1618690818384502278, Typ 4
2. Ereignisname: APPCRASH
3. Antwort: Nicht verfügbar
4. CAB-Datei-ID: 0
5.  
6. Problemsignatur:
7. P1: test1.exe
8. P2: 0.0.0.0
9. P3: 00000000
10. P4: KERNELBASE.dll
11. P5: 10.0.22000.2538
12. P6: 06aca232
13. P7: c0000005
14. P8: 00000000000436a6
15. P9:
16. P10:
17.  
18. Angefügte Dateien:
19. \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.5c5edd71-2b2b-4832-8c5b-b2cf4f035be0.tmp.mdmp
20. \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.faae124b-6e7f-42c6-a17a-f01d67568972.tmp.WERInternalMetadata.xml
21. \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.8fc3d2a3-2465-4bfe-af8a-bc15652b274c.tmp.xml
22. \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.004145ae-92e1-4c88-b286-846b8a8b58bc.tmp.csv
23. \\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.e0cab7c6-f5a0-41f4-9732-ffe854851d5f.tmp.txt
24. \\?\C:\Users\Jens Kallup\AppData\Local\Temp\WER.1184a3db-b2c7-4500-9e00-9a0535dd23a9.tmp.appcompat.txt
25.  
26. Diese Dateien befinden sich möglicherweise hier:
27. \\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_test1.exe_394953599d258270cfaf83e132644a308f9bc680_2464b88d_7dcbcb3f-6da5-4e11-88e7-191298723d04
28.  
29. Analysesymbol:
30. Es wird erneut nach einer Lösung gesucht: 0
31. Berichts-ID: 49a6db74-6df0-48a3-826e-e91fa755d3ed
32. Berichtstatus: 268435456
33. Bucket mit Hash: 390f7a4d1c943737e676beb91efe9e06
34. CAB-Datei-Guid: 0

[KodeZwerg]

The following will crash the application ( WriteFile  Lines: 86 ):

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

1. ...
2. function PutToFile(const AFileName: LPCSTR; AData: LPCSTR): Boolean;
3. ...
4.             // next step will crash the app ...            
5.             dummy := WriteFile(hFile, adata, dataSize, 0, overlap);

From time to time you should just swallow what is given and not modify.

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

1. procedure PutDataToFile(const AFileName: string; AData: PAnsiChar);
2. ...
3.           if WriteFile(hFile, AData^, DataSize, cnt, nil) then

I hope you see the differences and for what reason you try play now with overlapped? That was never planned in.

[KodeZwerg]

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

1.         if ((dummy = INVALID_SET_FILE_POINTER) and (error = NO_ERROR)) then begin

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

1.       if ((dummy <> INVALID_SET_FILE_POINTER) and (error = NO_ERROR)) then

Why in the world you change it like that? Do you even understand the meaning of that comparision?
I do not check for more modifications made by you but a simple question remain, lets assume you truly copy and paste my example, letting each single char untouched, no "paule32 optimizations", just like I showed it, will it run successful or not?

[marcov]

Afaik it was always key to do as little as possible in the dll main event.

If you move the code to a separate procedure, does it work then?

[paule32]

Thank You for your feedback.

The comparison itself is not the problem - I fix this.
The problem is, that the "write" give Windows access denied error $c0005 - see attachment.
I log the Events of Windows, and the Application seems to raise a silent exception.

$c0005 mean, that the application tries to access memory, where is protected.

This come to me in mind, that something else is going on there.
A virus scanner ? - I have to check...

[paule32]

@marcov:

I had written a little test case .c file based test.dll - it will also fail on the write line.
Here the code:

Code: C  [Select][+][-]

1. // note: this code will fail with FILE*, and PFILE, too ...
2. # include <stdio.h>
3. # include <stdlib.h>
4. # include <string.h>
5.  
6. struct _PFILE {
7.     char *    _ptr;
8.     uint64_t  _cnt;
9.     char *    _base;
10.     uint64_t  _flag;
11.     uint64_t  _file;
12.     uint64_t  _charbuf;
13.     uint64_t  _bufsiz;
14.     char *    _tmpfname;
15. }
16. PFILE;
17.    
18. PFILE * my_fopen(char *filename, char *filemode)
19. {
20.     PFILE *tmp = fopen(filename, filemode);
21.     if (tmp == NULL) {
22.         printf("fopen() failed.\n");
23.         return 0;
24.     }   return tmp;
25. }
26.  
27. int my_fwrite(char *filename, char *filemode, PFILE *fhandle)
28. {
29.     if (!fhandle) {
30.         printf("file is nulll.\n");
31.         return 0;
32.     }
33.     char * buffer = (char *) malloc(200);
34.     strcpy(buffer, "Mallo Wallo");
35.    
36.     printf("write string...\n");
37.     fwrite(buffer,strlen(buffer),1,fhandle);
38.    
39.     printf("string written.\n");
40.     free(buffer);
41.    
42.     return strlen(buffer);
43. }

compiled with:

Code: Bash  [Select][+][-]

1. gcc -O2 -fPIC -c test.c
2. gcc -shared -fPIC -o test.dll test.o
3.  
4. # optional:  strip test.dll

all done.
The printf text's till fwrite will be display on screen.
Then app crashes.

[KodeZwerg]

Thank You for your feedback.

The comparison itself is not the problem - I fix this.
The problem is, that the "write" give Windows access denied error $c0005 - see attachment.
I log the Events of Windows, and the Application seems to raise a silent exception.

$c0005 mean, that the application tries to access memory, where is protected.

This come to me in mind, that something else is going on there.
A virus scanner ? - I have to check...

Because you call WriteFile() wrong, as I already shown to you but you did not realized.
You try to write a memory address with a non-sense length instead of the data where it points to.

[440bx]

@paule32

you need to realize that you _cannot_ call WriteFile as it is documented in MSDN.  In MSDN, WriteFile is defined as:

Code: C  [Select][+][-]

1. BOOL WriteFile(
2.   [in]                HANDLE       hFile,
3.   [in]                LPCVOID      lpBuffer,
4.   [in]                DWORD        nNumberOfBytesToWrite,
5.   [out, optional]     LPDWORD      lpNumberOfBytesWritten,
6.   [in, out, optional] LPOVERLAPPED lpOverlapped
7. );

The Pascal definition is NOT semantically equivalent because the "lpBuffer" parameter is _untyped_ and an untyped parameter is nowhere near what a "pointer" parameter is.  The Pascal definition is _wrong_/_incorrect_, what makes it that way is that if you call WriteFile as it is documented in MSDN then you'll get an access violation because the Pascal definition is, again!, wrong!.

Either you correct the parameter by assigning it a type (which is the way it should be) or you call it in a way that can make that incorrect definition work properly. 

The one thing you _cannot_ do is call the current Pascal definition as WriteFile is defined in MSDN.  That will _never_ work.

By the way, if you want to call WriteFile the way it is documented in MSDN then you can use the definition I provided you a few posts back.  Not only that would work, it's as easy as copy and paste (and define a constant for "kernel32".)

[KodeZwerg]

@440bx I do not want to argue about what is correct or more close to the original, if he calls it wrong with your header(s), the result stay same.
Original I wanted to take a ptrUInt for the buffer but decided to let it full off to be mostest close to void/nothing, just to explain why I do how I do.

no sarcasm but that way of code with similar content/definitions is since years working flawless at a logging mechanic.
on another app i use same definitions but work with tbytes/pbytes instead of pansichar. (also other filemethods with similar headers are used)

[TRon]

The following will crash the application ( WriteFile  Lines: 86 ):

... and (I) thank heavens for that.

It has been pointed out several times now yet somehow expecting a different result.

[440bx]

@440bx I do not want to argue about what is correct or more close to the original, if he calls it wrong with your header(s), the result stay same.

There isn't anything to argue about.  The MS definition is a specification one that the Pascal definition does _not_ meet.  The fact that something that is _wrong_ can be made to work does not make it right. 

When people want to know how a specific Windows API function operates, they don't come here, they don't look at how it is defined in the FPC units, they go to the author, that is MS and read the spec and code the calls as called for the spec.  You're right, there is absolutely nothing to argue about.  The Pascal definition is _wrong_, period.  Proof: code as spec'ed and you'll get a violation.

[TRon]

When people want to know how a specific Windows API function operates, they don't come here, they don't look at how it is defined in the FPC units, they go to the author, that is MS and read the spec and code the calls as called for the spec.  You're right, there is absolutely nothing to argue about.  The Pascal definition is _wrong_, period.  Proof: code as spec'ed and you'll get a violation.

+1

With the sidenote that usually I first check the jedi declaration so that I do not have to do it myself because I'm a lazy as F*.

[paule32]

Hello @all:

I thinking over to came to the problem hot spot.
The RTL compilerproc function's may be give wrong result.
Now, WriteFile will not cause a crash.

And as such, I get in trouble with:

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

1. function  fpc_char_to_ansistr(const c : char): AnsiString; compilerproc;
2. var
3.     dest: PAnsiString;
4. begin
5.     dest := PAnsiString(c);
6.     result := AnsiString(dest^);
7. end;
8.  
9. function fpc_pchar_to_ansistr(
10.     const p: PChar): AnsiString;
11.     compilerproc;
12. var
13.     index: DWORD;
14.     cchr : PChar;
15.     DestS: AnsiString;
16.     SLeng: DWORD;
17. begin
18.     SLeng := 0;
19.     while true do begin
20.         if p[SLeng] = #0 then
21.         break;
22.         SLeng := SLeng + 1;
23.     end;
24.     index :=  0;
25.     DestS := '';
26.     while index >= SLeng do begin
27.         cchr  := PChar(p[index]);
28.         DestS := DestS + cchr;
29.         index := index + 1;
30.     end;
31.     result := DestS;
32. end;

Code: Bash  [Select][+][-]

1. FPC_System.pas(127,26) Error: Wrong number of parameters specified for call to "$fpc_pchar_to_ansistr"
2. FPC_System.pas(110,11) Error: Found declaration: $fpc_pchar_to_ansistr(const PChar):AnsiString;
3. system.pas(75) Fatal: There were 2 errors compiling module, stopping
4. Fatal: Compilation aborted

Question is: how to fix the error above ?

[TRon]

Question is: how to fix the error above ?

Question in return: is there a particular reason to ignore the already existing implementation(s) and invent your own (instead of copy-pasting the bits that you require) ?

Beside that, if you made no modifications to correct the writefile issue reported earlier then you got bigger fish to fry. In that case it does not matter how these compiler procs are implemented as there is fundamentally something wrong with the code as presented (and it will keep crashing, again as it should).

[paule32]

in general, you would not making a question on a question.
That is not gentle.

I can not ask your question's, because I don't know that FPC needs so many compilerproc functions, and procedures.
As such, I would be expect, that FPC sould me let to make/compile my own stuff.
As such, I would be expect, that you can help me with working things.

For me, I can not claim, that you give anything.
But I would expect solutions (so little they are) - and not the things like: "use existing code.".