To sum up the method for exposing the interface of the module (Dll) in C ++:
(1) how to export API functions
This method is the most basic way to call the DLL Interface in Windows. GDI32.dll and User32.dll use this method to expose the system API.
The advantage of this method is that the export function has no language restrictions and can be called in any language;
The disadvantage is that this method is process-oriented. It is not convenient to support multiple instances externally. In addition, the callback function required by this method can only be a common C function, in C ++, we usually use static member functions, which is inconvenient.
Of course, through encapsulation, we can also make this method support multiple instances and use an abstract handle HComponent, for example, the export function HComponent CreateInstance (); VOID DeleteInstance (HComponent h ); the first parameter of other internal export functions is the instance handle, similar to INT SendMessage (HComponent h ,...), this method can be used to simulate the effect of forward object.
In addition, if you use the dynamic loading (LoadLibrary, GetProcAddress) method to call its export function, even if the export function is modified internally, the external program does not need to be re-compiled and is still available. Www.2cto.com
An excellent example of the function export method is the implementation of GDI +, the entire GdiPlus. dll provides common export functions, but it can be conveniently used in object-oriented languages, because on the one hand, it encapsulates objects in the DLL in Handle mode, on the other hand, it uses the C ++ class method to encapsulate the header file and provide it to the user. Therefore, the C ++ program can be called directly in an object-oriented way.
(2) Export class
The export class is used to export the entire C ++ class, And MFC42.dll is used in this way.
The advantage of this method is direct object-oriented.
The disadvantage is that it can only be used for C ++, and it is best to use the same compiler. In addition, when the DLL changes, the external program needs to be re-compiled, and the external program can see the internal implementation of your class through the header file,
Therefore, this method is the least recommended method.
(3) COM
In the COM method, several fixed functions (DllGetClassObject, DllCanUnloadNow, DllRegisterServer, and DllUnregisterServer) are exported, and these functions are used as the entry to call the internal interface implemented by the component.
The COM method combines all the advantages of the above two methods, without language restrictions, object-oriented, multi-instance, only interface visibility, dynamic upgrades, and so on.
Of course, because of its complexity and dependency on the registry, we often do not want to strictly follow the COM standard when encapsulating the module, but we can provide interfaces according to the COM idea.
For example, we can let our module provide only one export function CreateFactory, and then the external can call this interface to create a factory, and finally create various types of objects through the factory. These objects implement some interfaces, externally, you only need the header files of these interfaces to call the object method.
More and more components now provide external interfaces in this way. For example, D2D's external export interface is D2D1CreateFactory, and then other objects can be created through this factory, for example, pD2DFactory-> CreateHwndRenderTarget (...), finally, you can directly call the interface implemented by the object: pRenderTarget-> DrawRectangle (D2D1: RectF (100.f, 100.f, 500.f, 500.f), pBlackBrush );
Of course, the methods for exposing the interfaces of the above DLL files are essentially no different. They all use the export section of the PE file to export data and functions, but according to their usage, there is a big difference for external modules. The recommended order is: COM-> export API function-> export class.