The Windows Dynamic Library has several areas to be aware of, because there are too many places to set up compared to the dynamic libraries of Linux.
1, the first thing to note is the operation of the library mode selection must be consistent!
The reason is that the heap manager for each DLL library is based on a copy of the runtime library CRT, and each library must have a copy of the runtime library. Here are a few choice questions.
First, the question of whether to choose MT or MD,
1) MT represents the Mutilt-thread single, which represents the multi-threaded static runtime library. If you choose this mode, it is important to note that the data that each dynamic library uses while the program is running and that the heap is based on a copy of its own runtime library, in other words, uses its own heap memory, so that each library uses its own memory to be laosi, only if the memory allocated by the non-dynamic library is used (That is, the memory allocated by the program principal) to truly communicate and access. If anyone crosses the border, there may be a risk, for example, if there is a usage: the interface provided by Dynamic Library A is used not only for dynamic library B, but also for the program body, and if the interface in dynamic Library A provides an address for a memory block allocated in its heap, then it is passed to Dynamic library B. However, the release is released in the main function of the dynamic Library B passed to the program body, because the copy of the runtime library of the dynamic library A used by main is inconsistent with the copy of the runtime Library of dynamic library A that dynamic library B relies on, so the illegal use of pointers, the improper memory block addresses are freed, Cause heap corruption. A more subtle error usage of this usage is that it does not return a pointer to dynamic library A, but instead provides a series of function interfaces that can manipulate the internal memory heap blocks, but there is still the error that allocating memory using the interface that calls Dynamic library A in the dynamic library B above to do some operations and store the data , and in the main function of the program body to invoke the interface of dynamic library A to read the data that has been stored and then manipulate the data overwrite, but at this time due to the two interface calls of the replica inconsistent!!! So the expected consensus is that the data, in fact, is inconsistent!!! The result is memory access out of bounds, wild pointer caused by errors can be strange!!!
2) MD represents the Multi-thread DLL, which represents a multi-threaded dynamic Runtime library. If you choose this mode, then the same dynamic library will use a copy of the same runtime library. In the example above, the dynamic library B and the program body main function call the interface in dynamic Library A, using the same heap memory, so there is no such problem.
Second, MDD or MD? Or MTD or MT?
The more MDD and MTD D here is Debug. Because the two different libraries of MDD and MD can compile links normally, as with the MT and MD mentioned above, what are the risks? The key is to select a different runtime library debug version and release version, you can see the different modes of the runtime Library of the Lib file and has been different, follow the instructions provided by Microsoft MSDN, These lib files are linked to the obj file in the run-time library to indicate how the program resolves to find external function symbols, since it is debug, there are obviously a lot of protections, in addition to the above-mentioned analytic symbols related, There are also memory operations and allocation protections that allocate more bytes each time the memory is allocated to store the currently allocated information, which can result in runtime differences. There is also a question on stackoverflow about the risk of mixed use, without specifying a clear risk, but this memory operation check and memory leak check is clearly likely to cause memory inconsistencies. In addition, it is doubtful if the use of different modes of the runtime library, is not also indicated may appear before the difference between MT and MD, because they are mapped into memory is obviously not the same dll!!!
So the best way to do this is if MDD is all about MDD, or all MD, debug? Who told you that this release version of MD can not be added to build debugging information, yes, and then continue to the hard-pressed debugging, Pit Dad's Microsoft Ah, do so much to do.
2, the compiler version must be consistent. vs2005 or vs2008 or vs2010 or vs2013 a compiled dynamic library?
That means all the libraries are compiled with a consistent compiler, why? Because the version of the runtime library for each compiler is inconsistent, there is a problem, and the runtime libraries compiled by different compiler versions actually share different versions of the runtime library. If the runtime is up, there is a good chance that the interface is compatible and that it will compile the link normally when the program eventually generates the package. But at runtime, different libraries are using different runtime libraries to cause compatibility problems, as will make your library appear inexplicable compatibility problems, yes, that's the pit dad. I have read an English document that you can save the runtime library at compile time and publish it with the library, so that each subsequent use of the library to compile links using this runtime library, but this will not be too much nonsense, when the library, when involved in the third party giant, estimated that you cry, Anyway, I think the management should still be very difficult. However, this method I also did not find where to put the runtime library in the IDE fixed down, we still honestly in the program compile time check the password consistent with a compiler on the good!!!
3. The number of bits in each library should be consistent. 32-bit or 64-bit library?
Yes, now a lot of memory, we are beginning to everyone 64 migration, it seems that the money of memory ah, anyway, is the customer, hem. However, the 32-bit and 64-bit are likely to be ignored, and a careless turn becomes the 32-bit library and the 64-bit library Fei Qi. Because a variety of deviations may compile the link can still pass smoothly, but after running up you will wait to cry. How to view? There is a command, with Linux on the file command can see whether the DLL is 32-bit, if the 32-bit library will have a hint 80x86 32-bit display typeface. However, the Lib file is temporarily not found to see the place.
4, the function symbol table lib file and the dynamic library DLL file is consistent (not only the outside name is consistent, internal also must be consistent, to say what)
A problem occurred during debugging the Lib and DLL filenames are identical except for the file suffix name. But when the program Sahuan running, every time when the dynamic library is loaded, the corresponding dynamic library is not found. For example, the Libdependmd.lib and Libdependmd.dll runtimes always say that Libdepend.dll cannot be found. The last reason to find out is that because the load is libdependmd.lib, and the compiled output of the generated file is actually Libdepend.lib but to the library when a small partner heard to distinguish between MD and MT to change the name of the library, but the library name changed is not a problem, in fact, Lib library file will be the name of the DLL is also in the inside, link to use the Lib is so to tell other to use the library, it corresponds to the library name. In particular, you can open the Lib file with the Ultra tool, see the file at the end of its corresponding ASSCII code will have the corresponding DLL name, no longer have to worry about Lib and DLL name inconsistent!!!
The above five steps can basically put the dynamic library in the various patterns caused by the problem of exclusion, follow-up work on your own!
Problem debugging for Windows Dynamic Library
