Tenth chapter-Dynamic Link library Programming (i) (1)

Dynamic link library (DLLs) is developed from the concept of C language function library and Pascal Library unit. All C language standard library functions are stored in a library of functions, and users can also use Lib program to create their own library of functions. In the process of linking the application, the linker copies the function code called by the program from the library file and adds the function code to the executable file. This method is the same as storing functions only in the compiled. The obj file is more useful for code reuse than it is in.

But with the advent of a multitasking environment such as windows, the method of functional libraries is cumbersome. If every program has its own function to complete screen output, message processing, memory management, dialog boxes, and so on, then Windows programs will become very large. The development of Windows requires allowing several simultaneous programs to share a single copy of a set of functions. This is where the dynamic-link library occurs. Dynamic link libraries do not need to be compiled or linked, and once loaded into memory, the DLLs function can be used by any running application software in the system without having to load another copy of the DLLs function into memory.

How the 10.1.1 dynamic link library works

The words "dynamic link" indicate how DLLs works. For a regular library, the linker copies all the library functions it needs and passes the exact function address to the program that calls the functions. For DLLs, functions are stored in a separate dynamic-link library file. When you create a Windows program, the link process does not link the DLLs file to the program. The program does not require the address of this function until the program runs and calls a function in the DLLs. At this point, Windows looks for the called function in the DLLs and sends its address to the calling program. In this way, DLLs reaches the limit of the reusable code.

Another convenience of a dynamic-link library is that modifying a function in a dynamic-link library can automatically propagate to all programs that invoke it without having to make any changes or processes to the program.

DLLs not only provides the mechanism of function reuse, but also provides the mechanism of data sharing. Any application can share a block of memory resources managed by the DLLs that is loaded into memory. DLLs, which contains only shared data, is called a resource file. such as the font files for Windows.

10.1.2 Dynamic link Libraries for Windows systems

Windows itself is supported by a large number of dynamic link libraries. This includes Windows API functions (Krnlx86.exe,user.exe,gdi.exe, ...), various driver files, various with. Font resource files for Fon and. Fot extensions. Windows also provides a dedicated DLLs for a feature, such as Ddeml.dll for DDE programming, Ver.dll for program installation, and so on.

While writing a Windows program is bound to involve DLLs, using Delphi, users will not notice this most of the time. This is partly because Delphi provides a rich set of functions so that users do not have to use the Windows API directly; On the other hand, by using the Windows API, Delphi organizes the API functions and other Windows DLLs functions into several library units. Therefore, you do not have to use a special calling format. So the focus of this chapter is on writing and invoking user-defined DLLs.

Using traditional Windows programming methods to create and use a DLLs is a headache, just as the traditional Windows programming approach is inherently daunting. Users need to make a series of modifications to the definition files and engineering files to suit the needs of creating and using DLLs. The advent of Delphi in this regard, as in many other ways, has eased the burden on developers. What is more exciting is that Delphi uses DLLs to realize the reuse mechanism of the form. A user can store a form that he has designed in a DLLs, and can call it whenever it is needed.

compilation and invocation of 10.2 DLLs

Preparation of 10.2.1 DLLs

In the Delphi environment, writing a DLLs is not much different from writing a generic application. In fact, as the DLLs of the main body DLL functions, in addition to the memory, the management of resources are different, do not need other special means. The real difference is in engineering documents.

In most cases, the user is almost unaware of the existence of a project file because it is not normally displayed on the screen. If you want to view a project file, you can open the View menu and choose Project Source, where the code for the project file appears in the Code Editor (the coding editor) of the screen.

The format of general engineering documents is:

Title of program Project;

Uses clause;

Program Body

The format of the DLLs project file is:

Library project title;

Uses clause;

Exprots clause;

Program Body

The main differences are two points:

1. General engineering documents for the head of the program keyword, and DLLs engineering document header with the Library keyword. Different keywords tell the compiler to generate a different executable file. An. exe file is generated with the program keyword, and a. dll file is generated with the Library keyword;

2. If DLLs is to output functions or procedures for use by other applications, these functions or procedures must be listed in the EXPORTS clause. These functions or procedures themselves must be compiled with export compilation directives.

According to the functions completed by DLLs, we divide the DLLs into three categories as follows:

1. Complete the general function of the DLLs;

2. dlls for data interchange;

3. DLLs for form reuse.

In this section we will discuss only the DLLs that complete the general functionality, and the rest in the next two sections.

10.2.1.1 the process of writing general DLLs

The steps for writing general DLLs are as follows:

1. Use the Delphi Application template to establish a DLLs program framework.

For Delphi 1.0 users, because there is no DLLs template, so:

(1). Establish a general application and open the engineering document;

(2). Remove the form and the corresponding code unit;

(3). In the engineering document, change the program into a library, remove the forms in the uses clause, and add the appropriate library unit (general Sysutils, classes is required), and delete all the code between begin...end.

2. Keep the file with the appropriate filename, and the library name will be changed automatically;

3. Input procedure, function code. If procedures, functions are ready for other applications to call, then the process, the function after the head plus export compilation instructions;

4. Create a exports clause that contains functions and procedure names that are called by other applications. The standard can be used to instruct name, Index, resident to facilitate and expedite the process/function invocation;

5. Input library Initialization code. This step is optional;

6. Compile the program to generate the dynamic link library file.

10.2.1.2 Standard instructions in a dynamic link library

In the output section of the dynamic link library, three standard instructions are used: Name, Index, resident.

1.name

Name followed by a string constant as the output name of the procedure or function. Such as:

Exports

InStr name Myinstr;

Other applications will call the procedure or function with the new name (MYINSTR). If the original name (INSTR) is still being used, a system error is raised when the program executes to the reference point.

2.Index

Index indicates that a sequence number is assigned to a procedure or function. If you do not use the index indicator, the compiler assigns it sequentially.

The range of digits after index is 1 ... 32767. Use index to speed up the call procedure.

3.resident

With resident, the specific output information is always kept in memory when the DLLs is loaded. This allows you to reduce the time overhead when other applications call the procedure, rather than by using the name to scan the DLL entry.

For those processes or functions that other applications often invoke, it is appropriate to use resident instructions. For example:

Exports

InStr name Myinstr resident;