It is necessary to introduce the debugging and viewing methods of the library files before entering into the detailed elaboration of various kinds of DLLs, because we will face a large number of examples from the next section.
Because the library file cannot be executed separately, it pops up the dialog shown in Figure 3 when F5 (Start debug mode execution) or CTRL+F5 (run) executes, requiring the user to enter the path of the executable file to start the execution of the library function. This time we enter to call the library's EXE file path can be debugging the library, its debugging skills and general application engineering debugging.
There is usually a better way to debug than the above approach, that is, the library engineering and application Engineering (call Library Engineering) placed in the same VC work area, only to the application engineering debugging, in the application project call library functions in the statement to set breakpoints, after the execution of press F11, so that one step into the library function. The Libtest and Libcall works in section 2nd are in the same working area, and their engineering structure is shown in Figure 4.
The above debugging methods are consistent with the static link library and the dynamic link library. So all the source code that this article downloads contains the engineering of library engineering and call library, both of which are included in a workspace, which is the author's intention to provide this package download.
The export interface in the dynamic link library can be viewed using the Depends tool in Visual C + +, so let's open the User32.dll in the system directory with depends, see? The red circle is a few versions of the MessageBox! So it's really here, It's right here!
Of course the depends tool can also display the hierarchy of DLLs, and if you open an executable file with it, you can see which DLLs the executable called.