VC6.0 how to create and invoke dynamic link library instances
- 2020-04-01 21:28:03
- OfStack
The responsibilities of my younger brother in the company have been briefly introduced in the last blog. This blog mainly introduces the application of technology rather than the principle. Because the company's project is in a hurry, the results are important, and we are not focused on research, so, after the basic understanding of the principle, directly get to work, make a demo to the best.
As for the company's work situation, today we will skip over, of course, is not one or two sentences can be expressed clearly. A summary of the work will follow, please look forward to...
Now, cut the crap and get to the point - creating dynamic link libraries in VC6.0.
As the intermediary between the customer and the background, in order to better adjust the relationship between the two parties, I wisely chose webservice and dynamic link library. In c++ with the customer makes the dynamic link library way, while with the background Java, USES the webservice to communicate.
Now that you have a dynamic link library, you definitely think of a static link library. Well, this is relative. So what's the difference? So for What chose the dynamic link library?
Statically linked library: is to package the lib file into the exe file.
Dynamic link library: do not package the lib file into the exe file, if used, directly load and unload the corresponding DLL file.
Also, static link libraries are not allowed to contain static link libraries and dynamic link libraries, while dynamic link libraries are allowed to contain static link libraries and dynamic link libraries. Because the DLL that the younger brother encapsulates is the DLL that calls the client, and may contain its own dynamic link library.
In view of this, the younger brother chose dynamic link library.
The other thing is that dynamic link libraries are also divided into three cases. One is a non-mfc DLL (that is, the console DLL), two is the regular MFC DLL (which is divided into static dl and Shared DLL), and three is the extended MFC DLL. And the DLL of MFC can be called by MFC program or console program.
Because the younger brother of the DLL package, need to call the MFC program, so I chose to use MFC general DLL. And use the console program to do the test.
First, select the MFC AppWizard (DLL) in the new project
And then in the header. H file, declare the function that was called by the outside
After the declaration, in the CPP file, implement this function.
Compile, build build. OK, generate the corresponding DLL under Debug, so the dynamic link library is generated. Then the program can use the DLL file directly.
And then what. Copy the DLL file to the corresponding test DLL program (the program that calls the DLL). Usage:
I test DLL program, is the use of the console program, so simple and convenient, of course, using MFC program can also.
For example, let's create a new console program, and then in the main method, write as follows:
The function of each sentence has been clearly expressed in the comments. If you don't understand, you can contact me and communicate with each other.
In fact, dynamic link library, similar to the DLL in our VS, only, as long as the DLL reference to the corresponding program, and then directly can be used. In this case, we manually load, connect, and release the DLL. With a dynamically linked library in this way, we are free to use the functions we want to call anywhere in our program.
As long as we follow the "load, LoadLibrary -- GetProcAddress -- FreeLibrary" principle. It is quite convenient to use. The coupling between the two can be freed from the trouble, and can be loaded and released easily.
Here's how to call the statically linked library :
First: the lib file and DLL file both under the client, call dynamic link library, only need DLL file.
Second: in the client side needs to create a new header file, similar to the DLL exported function header file.
Third: in the client call DLL file (CPP file), add preinstruction, that is, the lib file explicitly loaded in.
For example: #pragma comment (lib," iprocessin.dll ")
Fourth: directly invoke the corresponding method under the button event.
Such as: cout< <" The result: "< < QueryFunctionByFID (the corresponding parameter);
In short, calling the static link library is relatively simple, as long as the corresponding file is loaded in, directly call the method. But calling dynamic link library is relatively, more flexible, when to use when to load, do not use direct unloading can.
Everything has its advantages and disadvantages, and we just make full use of their advantages and use them in different ways in different situations and different needs.
We just used the Debug version of the DLL when generating the DLL, since we can choose the Debug version, according to our thinking, will think that there is another version. In the next blog post, we'll look at the differences between the Debug version of the dynamic link library and the Release version of another version, and when and where to choose which version.
As for the company's work situation, today we will skip over, of course, is not one or two sentences can be expressed clearly. A summary of the work will follow, please look forward to...
Now, cut the crap and get to the point - creating dynamic link libraries in VC6.0.
As the intermediary between the customer and the background, in order to better adjust the relationship between the two parties, I wisely chose webservice and dynamic link library. In c++ with the customer makes the dynamic link library way, while with the background Java, USES the webservice to communicate.
Now that you have a dynamic link library, you definitely think of a static link library. Well, this is relative. So what's the difference? So for What chose the dynamic link library?
Statically linked library: is to package the lib file into the exe file.
Dynamic link library: do not package the lib file into the exe file, if used, directly load and unload the corresponding DLL file.
Also, static link libraries are not allowed to contain static link libraries and dynamic link libraries, while dynamic link libraries are allowed to contain static link libraries and dynamic link libraries. Because the DLL that the younger brother encapsulates is the DLL that calls the client, and may contain its own dynamic link library.
In view of this, the younger brother chose dynamic link library.
The other thing is that dynamic link libraries are also divided into three cases. One is a non-mfc DLL (that is, the console DLL), two is the regular MFC DLL (which is divided into static dl and Shared DLL), and three is the extended MFC DLL. And the DLL of MFC can be called by MFC program or console program.
Because the younger brother of the DLL package, need to call the MFC program, so I chose to use MFC general DLL. And use the console program to do the test.
First, select the MFC AppWizard (DLL) in the new project
And then in the header. H file, declare the function that was called by the outside
extern "C" _declspec(dllexport) char* queryFunctionByFID(char* funcId);
After the declaration, in the CPP file, implement this function.
char* queryFunctionByFID(char* funcId)
{
................................................
Concrete operation implementation }
Compile, build build. OK, generate the corresponding DLL under Debug, so the dynamic link library is generated. Then the program can use the DLL file directly.
And then what. Copy the DLL file to the corresponding test DLL program (the program that calls the DLL). Usage:
I test DLL program, is the use of the console program, so simple and convenient, of course, using MFC program can also.
For example, let's create a new console program, and then in the main method, write as follows:
//The declaration function pointer specifies the number of function arguments, parameter types, and return value types
typedef char* (* queryFunctionByFID)(char*);
//Loads the dynamic link library and returns a handle to the DLL file
HINSTANCE hDLL=NULL;
//Load the dynamic link library with the same DLL name as the one you just generated.
hDLL=LoadLibrary("IProcessInstIn.dll");
queryFunctionByFID saveProcess=NULL;
//Load the corresponding function in the dynamic link library
saveProcess=(queryFunctionByFID)GetProcAddress(hDLL,"queryFunctionByFID");
//The actual function is called
cout<<" The result is: "<<saveProcess("dd");
//The resource is released after the invocation
FreeLibrary(hDLL);
The function of each sentence has been clearly expressed in the comments. If you don't understand, you can contact me and communicate with each other.
In fact, dynamic link library, similar to the DLL in our VS, only, as long as the DLL reference to the corresponding program, and then directly can be used. In this case, we manually load, connect, and release the DLL. With a dynamically linked library in this way, we are free to use the functions we want to call anywhere in our program.
As long as we follow the "load, LoadLibrary -- GetProcAddress -- FreeLibrary" principle. It is quite convenient to use. The coupling between the two can be freed from the trouble, and can be loaded and released easily.
Here's how to call the statically linked library :
First: the lib file and DLL file both under the client, call dynamic link library, only need DLL file.
Second: in the client side needs to create a new header file, similar to the DLL exported function header file.
Third: in the client call DLL file (CPP file), add preinstruction, that is, the lib file explicitly loaded in.
For example: #pragma comment (lib," iprocessin.dll ")
Fourth: directly invoke the corresponding method under the button event.
Such as: cout< <" The result: "< < QueryFunctionByFID (the corresponding parameter);
In short, calling the static link library is relatively simple, as long as the corresponding file is loaded in, directly call the method. But calling dynamic link library is relatively, more flexible, when to use when to load, do not use direct unloading can.
Everything has its advantages and disadvantages, and we just make full use of their advantages and use them in different ways in different situations and different needs.
We just used the Debug version of the DLL when generating the DLL, since we can choose the Debug version, according to our thinking, will think that there is another version. In the next blog post, we'll look at the differences between the Debug version of the dynamic link library and the Release version of another version, and when and where to choose which version.