Reading-the first day of Windows core programming in Delphi

Technical Exchange, DH explanation.

This idea suddenly exists at night, so I should read all the books in a down-to-earth Manner. Well, be steadfast.
I only have an electronic version of this book. You can go to the box, garden, and my online storage.

Chapter 1 DLL and data sharing
First, create a DLL project:


Two Methods for exporting functions:

 
Function export1 (): integer; export; begin // Add code hereend;
 

WriteExport.

 
Function export1 (): integer; begin // Add code hereend; function export2 (): Cardinal; stdcall; begin // Add code hereend; exports export1, export2;
 

InExportsWrite the names of all functions to be exported.
There are two methods for calling DLL by EXE:
Explicit call:

Function export1 (): integer; External 'project2. dll '; Implementation
 

Define a function, and external explains which DLL the function comes.
Implicit call:

 
Type texport2 = function: Cardinal; stdcall; Procedure tform1.formcreate (Sender: tobject); var hlib: Cardinal; export2: texport2; begin hlib: = loadlibrary ('project2. dll '); export2: = texport2 (getprocaddress (hlib, 'export2'); // execute the function export2; freelibrary (hlib); end;
 

First load the DLL with loadlibary and then getprocaddress to get the function pointer, then execute it, and finally release the DLL handle. Remember.
Now that the call is made, the call conventions are as follows:
The register function uses registers (eax, EDX, ECx) first from left to right, and then stacks
Pascal functions are transferred from left to right through Stack
Cdecl callers pass through stacks from right to left (compatible with C \ c ++ default call conventions)
Stdcall function from right to left, passed through stack (compatible with _ stdcall in VC)
The safecall function is passed through Stack from right to left (same as stdcall)

We can see that the parameters are different. If I call different methods, the parameters may be incorrect. The final result of the function must be different.
What if we want to do something during DLL initialization and at the end?

 
// Begin in the middle of the begin end at the end of the DLL project file // write it hereCodeIt is initialized, but it can only initialize the end of the task.
 

Only initialization... what should I do?
There are two more solutions, haha:
First, We add a reference unit, and initialize and finalization the unit initialization and finalization.

 
Uses unit2 in 'unit2. pa'; // DLL
 

Unit unit2; interfaceuses sysutils; implementationvar L: tobject; Initialization L: = tobject. Create; // initialize the finalization L. Free; // end the work.
 

Second, Call the main function. Yes, dllmain (), but this is not called in Delphi. It is called dllproc ().

Procedure mydllmain (N: integer); begin case n of dll_process_attach: Begin // end when the process loads the DLL; dll_process_detach: Begin // end when the process uninstalls the DLL; dll_thread_attach: begin // end when the thread loads the DLL; dll_thread_detach: Begin // end when the thread uninstalls the DLL; end; begin dllproc: = mydllmain; mydllmain (dll_process_attach); end.
 

After a DLL is loaded by a process, the space of the DLL variable is in the process. that is, if two processes load a DLL, the global variable of the DLL will have two backups, which are irrelevant to each other, right.
What should I do if multiple DLL files share a global variable? Next we will talk about using memory ing files.

Type tdata = record a: integer; // other data end; pdata = ^ tdata; var hmap: Cardinal; Data: pdata; Procedure mydllmain (N: integer ); begin case n of dll_process_attach: Begin hmap: = openfilemapping (file_map_all_access, false, 'name'); If hmap = 0 then // if no begin // memory ing exists, the first parameter must be $ ffffffff, and the file ing parameter is the file handle // The second parameter: Secure, generally nil // The third parameter: the attributes of the ing file, we need to read, write, and the fourth parameter: 4 bytes high to map the data size // The Fifth parameter: 4 bytes lower to map the data size // The sixth parameter: unique name: hmap: = createfilemapping ($ ffffffff, nil, page_readwrite, 0, sizeof (tdata), 'name'); If hmap = 0 then // creation failure exit; end; // ing data: = mapviewoffile (hmap, file_map_all_access, 0); // All ing out if data = nil then // exit ing failure exit; end; dll_process_detach: begin if Boolean (data) then begin unmapviewoffile (data); closehandle (hmap); end;

Now the ing is ready. As long as data is operated, it will be written to the shared memory zone. because multiple DLL files may be written back, we need to obtain a mutex object for synchronization. I will not demonstrate it. there will be in the code in this book.
There is also a place where only one variable has a struct during ing. There should be no pointers in the struct, that is, strings, because the addresses pointed by pointers are in the process space. if multiple structs need to be shared, you must first define multiple structs as one struct.

Other data sharing methods:
1. sendmessage or postmessage is passed by lparam and wparam, but lparam and wparam are only two integers, that is, only two numbers of transmitted data. The address and pointer are useless, because your pointer is still in the process space and is not mapped out.
2 wm_copydata messages can be sent with a pointer.

 
Function sendcopydata (H: hwnd; s: ansistring): integer; var P: pansichar; bufsize: integer; Data: tcopydatastruct; begin bufsize: = length (s) + 1; p: = allocmem (bufsize); strcopy (p, pansichar (s); with data do begin cbdata: = bufsize; dwdata: = 12315; // define lpdata: = P; end; Result: = sendmessage (H, wm_copydata, 0, INTEGER (@ data) end;
 

Okay, the first chapter is like this. You are going to bed. You cannot be late tomorrow...