如何可能？

1）lib被编译为使用静态RTL，因此代码不会拉入第二个RTL DLL冲突。

1) the lib is compiled to use static RTL, so the code won't pull in a second RTL DLL that ***es.

2）代码只调用完全在头文件
中的函数（并使用结构等），因此不会导致链接器错误，或
调用仍存在于新RTL中的函数，因此不会导致链接器错误。

2) the code only calls functions (and uses structures, etc.) that is completely in the header files so doesn't cause a linker error, or calls functions that are still present in the new RTL so doesn't cause a linker error,

3）不调用任何具有已更改布局的结构，意义所以它不会崩溃。

3) doesn't call anything with structures that have changed layout or meaning so it doesn't crash.

＃3是一个担心。您可以使用导入来查看它使用的是什么，并制作完整的列表，但没有关于哪些兼容的文档或保证。只是因为它似乎运行并不意味着它没有潜在的错误。

#3 is the one to worry about. You can use imports to see what it uses and make a complete list, but there is no documentation or guarantee as to which ones are compatible. Just because it seems to run doesn't mean it doesn't have a latent bug.

还有

4）驱动程序SDK或其他水平相当低的代码是为了避免完全使用标准库调用。

4) the driver SDK or other code that's fairly low level was written to avoid using standard library calls completely.

DLL可以被隔离并且具有它们自己的RTL并且不在不同的状态之间来回传递（比如存储器分配和释放）。内部COM服务器工作方式。 DLLs 一般来说，如果你仔细考虑你传递和返回的东西，以及你对指针等事情做了什么。 Crypto ++例如使用封装程序的内存例行程序初始化，并且不会从编译的RTL版本暴露malloc的内存。

also (not your situation I think) DLLs can be isolated and have their own RTL and not pass stuff back and forth (like memory allocation and freeing) between different regimes. In-proc COM servers work this way. DLLs can do this in general if you're careful about what you pass and return and what you do with things like pointers. Crypto++ for example is initialized with the memory routines from the enclosing program and doesn't expose malloc'ed memory from the RTL version it was compiled with.