Contact VC Four: COM Component model Basics

It's been another year since the year went by. My VC career has been two years old. Can be quite a celebration yo. Review this year's study (alas, there is no work practice yet.) This year, the work is not easy to find WOW. ), but also learned a lot of good things. Among them, the most important is the COM component model, I personally think this is almost the core of Windows. Many advanced technologies (such as Microsoft's famous Directx,ado, no one will not know) are published in the form of COM components. Now, I'm aiming for another good thing, is the generic programming technology. It is able to write clear, flexible, highly reusable code that can be seen faintly in ATL (there are now a lot of ATL articles on the web and I'll talk about it later). OK, let's talk about generics programming in the future.

According to my previous plan, I should talk about my knowledge of COM component models. One can make a summary of their learning situation. Secondly, ask a master, can help point out the mistakes and omissions. Three might be helpful to beginners. I would like to ask you to correct the master. Thank you here first.

One, dynamic link library:

The dynamic chain State Library is the host object of most COM components (do not mind ocx, it is also a DLL, but only a change of suffix). Of course EXE is also possible (the Texttospeech object in TTS is an example), but in fact it is much less.

In the early days of windows, the emergence of dynamic chain-state libraries was a revolution. It has changed the life of Windows and has laid a solid foundation for the dominance of today's Windows operating system. (I haven't been too clear about the history of Windows.) Please vckbase the relevant historians to write an article as soon as possible ^_^).

Microsoft's explanation for the dynamic link library is this:

A dynamic-link library (DLL) is an executable file that is used as a shared function library. Dynamic linking provides a way for a process to invoke a function that is not part of its executable code. The executable code for a function is in a DLL that contains one or more functions that have been compiled, linked, and stored separately from processes that use them. DLLs also help you to share data and resources. Multiple applications can access the contents of a single DLL copy in memory at the same time.

Well, that's a pretty clear story. The dynamic-link library is an executable file first (Microsoft explains that the EXE is called a direct executable), which contains a set of functions that need to be shared. When used, dynamic-link libraries (and Windows systems) provide a way for our applications to invoke the functions in them. In addition, dynamic-link libraries also contain resources such as icons, dialog templates, and so on. In MFC, Microsoft has applied some techniques on the basis of existing dynamic link libraries to provide additional functionality, such as the export of MFC classes.

The link mode of dynamic link library is roughly divided into two types: static link and dynamic link.

A static link is also called an implicit link, which allows us to use the code without statements to indicate which dynamic link libraries our application will load. Its static link declarations are placed in engineering properties (or use #pragma comment (lib, "XXX.lib"), which can be put together with #include. When specified, you only need to enter the appropriate import library file (. lib) for its dynamic link library. You can then call the function that exists in the dynamic-link library anywhere in the program, like calling a normal function (and, of course, you need to include its corresponding header file.) In general, the header file is given with the Lib file. The program that is generated by this method is not clear when it runs initialization. But I can be sure it was before the WinMain function ^_^), which automatically loads the dynamic link Kuga in the system environment and maps it to the process of our application. When we call a function that is not defined by our process, the VC runtime locates the function of the corresponding dynamic link library and calls it by looking for information about the Lib file. At the end of the process, the system unloading the dynamic link library.

Dynamic links are also called explicit links, as the name suggests, which allows us to explicitly load the dynamic-link libraries in code by invoking the API. The COM component model is all in this way to load in-process component modules (that is, DLLs). (I think Microsoft's terminology is a bit confusing.) This approach has a number of benefits, it can be at run time to decide which link library to load, which function to call ... This is called dynamic link.

To use a dynamic link library is not difficult, first call LoadLibrary, whose prototype is as follows:

HMODULE LoadLibrary(
　LPCTSTR lpFileName　 // file name of module
);

The parameter lpfilename is the file name of the dynamic-link library to load. If the load succeeds, the handle is returned. Otherwise, NULL is returned.

Paired with this API is FreeLibrary, which has the following prototype:

BOOL FreeLibrary(
　HMODULE hModule　 // handle to DLL module
);

I don't need to tell you this.

When the dynamic link library is loaded by LoadLibrary, the C Run-time Library completes the initialization of the dynamic link library, such as global object (variable), static member variable generation and assignment initial value through _DllMainCRTStartup. The most important thing is that it also calls the DllMain function. Each dynamic link library must have this function, just as an application must have main or WinMain. Its prototype is:

BOOL WINAPI DllMain(
　HINSTANCE hinstDLL,　// handle to the DLL module
　DWORD fdwReason,　　 // reason for calling function
　LPVOID lpvReserved　 // reserved
);