Question

我遇到以下问题：

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>


int main() {

HANDLE handle;
DWORD dw;

handle = LoadLibrary("C:\\Folder\\mydll.dll");

dw = GetLastError();

printf("Loading Library: %d", dw);

FreeLibrary(handle);

return 0;
}

使用Netbeans / MinGW进行编译时，一切正常，DLL已加载，输出为＆＃34;加载库：0＆＃34;。

但是当使用Visual C ++ 2008 Express在完全相同的机器上编译完全相同的代码时，我得到臭名昭着的126错误：＆＃34;加载库：126＆＃34;。

DLL显然存在于指定的位置，加载它也可以正常工作 - 当我使用Netbeans和MinGW时。但是为什么使用Visual C ++时它不起作用？

这只是概述我的问题的示例代码。它是一个更大的项目的一部分，当使用Netbeans / MinGW编译时它完全正常，但是在使用Visual C ++编译时它不会加载DLL ...

感谢所有答案！

Answer 1

因为你的答案不完整而且错过了真正的问题，我将在这里详细说明。

您正在编译定义了UNICODE的MSVS版本，这使得LoadLibrary之类的内容被定义为LoadLibraryW的宏，它带有const wchar_t*个参数。相反，在使用GCC进行编译时，您无法定义它，并且它可以正常工作。

UNICODE版本实际编译的原因有点像MSVS中的错误/功能，允许您在没有任何消息的情况下将char*传递给wchar_t*（您确实打开了警告，不是吗？）。这导致一些错误解释的字符串被传递给Win32 API函数，该函数无法找到乱码文件名。

这就是为什么我总是直接调用*W版本的函数，而不必担心所有有趣的UNICODE内容。

Answer 2

我现在已经找到了解决方案。 FreeLibrary（“mystringpath.dll”）显然不起作用。但是当我使用LPCWSTR调用该函数时，它可以工作。所以：

handle = LoadLibrary("C:\\Folder\\mydll.dll");

使用Visual C ++编译时生成ERROR_MOD_NOT_FOUND，但在使用MinGW编译时可以正常工作。

但是当使用Visual C ++编译时，以下工作：

LPCWSTR path = L"C:\\Folder\\mydll.dll";

handle = LoadLibrary(path);

并返回ERROR_SUCCESS（0）。

所以依赖沃克指出的所有据称缺失的dll确实不是问题所在。

有趣的是，使用Netbeans / MinGW中的修复程序导致Netbeans .exe返回126.在编译时，gcc抱怨从不兼容的指针类型传递参数。

因此第一个代码仅适用于MinGW，仅适用于Visual C ++ ......

经过进一步研究，我意识到这个修复是不必要的。显然，问题是我的Visual C ++项目默认使用Unicode字符集。在项目属性中将其更改为多字节字符集后，原始问题中粘贴的代码在Visual C ++中也能正常工作......

LoadLibrary：使用Visual C ++编译时出错126，但与NetBeans / MingW一起正常工作？

2 个答案: