这要看情况。
据我所知，glibc和msvcrt可以在Windows上的同一进程中共存——Linux上发生的全局函数搜索在Windows上不会发生（每个动态导入都知道它来自哪个DLL，函数不会合并在单个命名空间中）。
但是，某些库可能存在问题。如果库指定“该函数返回一个指针，该指针应在完成后使用free()释放”，则需要使用正确的free释放它，即与分配它的malloc()相对应的free。同样，如果函数声明“参数是将由函数使用free()释放的缓冲区”，那么它必须使用相应的malloc()进行分配。当使用realloc()时也存在类似的问题。
例如，在使用针对不同版本的MSVCRT编译的DLL时（如MSVCRT20.dll vs. MSVCRT40.dll），也会出现此问题。
这就是为什么Windows库总是说明内存应该如何分配的原因。例如，请参见CoTaskMemAlloc/CoTaskMemFree、LocalAlloc/LocalFree、HeapAlloc/HeapFree。文档可能会说明“缓冲区不再需要时必须使用CoTaskMemFree释放”。或者他们可以提供自己的free/alloc对，例如“不再需要返回的缓冲区必须使用SuperLibraryFreeBuffer释放”（其中内部可能仅委托给CRT的free，但至少它将是正确版本的free）。
这是因为Windows始终是一种多语言平台，可以在除C语言之外的其他语言中编写库。今天我们可能习惯于Lisp、Pascal等是C运行时的一层——即使在Pascal的情况下这并不总是正确的，大多数程序员可能认为如此——但它并不总是这样：在C发明之前，Pascal已经在DEC计算机上普及了两年，在Windows的历史背景下，它与DEC有很多共同之处。早期版本的Windows主要使用汇编语言编写，...你知道Windows 3头文件中的“Pascal”调用约定有什么原因...
ld链接器甚至可以处理Microsoft的目标文件和库格式。由于这显然是一个使用C接口的DLL导入库，所以事情可能会顺利进行 - MinGW需要在Windows上通常使用DLL才能有用，因此它与DLL导入很好地配合使用。我认为可能的主要问题是跨运行时库分配/释放内存的一般问题。但我怀疑OCI.dll被设计成避免这种情况（因为这也是VC构建的问题）。 - Michael Burr