Здравствуйте

Проблема странная, но есть. При подключении DLL с помощью LoadLibrary она возвращает 0, а GetLastError = 126 — "Не найден указанный модуль". Эта ошибка вроде как должна появляться только если не найдены модули от которых зависит моя DLL, но они все рядом! Проверял с помощью Dependency Walker — больше никакие не нужны вроде как (он сказал что нужна msvcr80.dll её и всех похожих на нее я подложил рядом, при этом, vc2005 цепляет ее при запуске сам судя по 'core.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_...\msvcp80.dll', No symbols loaded. ). DLL пробовал цеплять и с абсолютными путями, и с относительным....

Возможно ли что причина в самой DLL-ке? Проверил dllmain — она всегда возвращает true, записи в лог нету — значит dllmain ещё не вызывалась вообще?

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    FILE* f = fopen("log.txt", "a");
    fputs("dll test!", f);
    fclose(f);

    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Сама по-себе длл-ка содержит одну ф-ию отдающую экземпляр класса:

extern "C" __declspec( dllexport ) ISubSys* createSubSys(ICoreSubSys* core) {
...

Длл компиляется без ошибок (варнинги есть), а потом — такая задница....
Могу выложить саму DLL для вскрытия, могу приложить список внешних длл которые положил рядышком... помогите! целый день над этим бьюсь....

Здравствуйте, JumangeeNET, Вы писали:

JNE>При подключении DLL с помощью LoadLibrary она возвращает 0, а GetLastError = 126 — "Не найден указанный модуль".

Указанный модуль — это не только зависимости, но и тот модуль путь к которому вы передаете в LoadLibrary.
Попробуйте в настройках проекта выставить working directory ту в которой все dll лежат, проверьте все пути
посимвольно. Даже не знаю что еще проедложить...

Здравствуйте, eklmn, Вы писали:

E>Указанный модуль — это не только зависимости, но и тот модуль путь к которому вы передаете в LoadLibrary.
E>Попробуйте в настройках проекта выставить working directory ту в которой все dll лежат, проверьте все пути
E>посимвольно. Даже не знаю что еще проедложить...
Пробовал копировать длл на c:\, чтоб не ошибиться — результат тот же... working directory ни на что не повлияла — это и так было понятно т.к. программа перед обращением к длл проверяет файл в текущем каталоге, и лог туда пишет...
Может быть стоит выложить исходники самой длл? наверняка проблема всё-таки в них, я не профи, мог чего-то и наколдовать...

Здравствуйте, JumangeeNET, Вы писали:

Вы случайно не в дотнете все это ваяете?
Есть там такая ботва как assembly file или что-то в этом духе...
Утверждать не буду, что причина именно в этом, но при определенных
настройках проекта и при отсутствии оного файла в директориях в кот.
происходит поиск если этот файл не найден, то dll подгружена не будет
и вывылится ошибка.
Проверьте, может это ваш случай.

Здравствуйте, eklmn, Вы писали:

E>Вы случайно не в дотнете все это ваяете?
Нет, платформа win32. Прозапас скопировал все файлы лежащие рядом со сгенерированной dll — не помогло.

Выкладываю часть исходников и саму dll, в архиве:

TheCore.h — класс загружающий dll, см. "CoreLink* loadDll(const std::string filename)"

Содержимое dll:
VirtualDir_Resources.h
VirtualDir_Resources.cpp
vdr_main.cpp

http://files.rsdn.ru/77021/core_src.rar (23кб)

Здравствуйте, JumangeeNET, Вы писали:

Сорри, в виндовых нюансах не силен, так что могу ошибиться.

У вас вызов такой:

LoadLibrary((LPCWSTR)...);

а, LoadLibrary, судя по мсдн объявлена как

LoadLibrary((LPCTSTR)...);

разницу видите?

Едем дальше, читая мсдн. В зависимости от юникодных
настроек проекта макрос LPCTSTR интерпретируется поразному.

#ifdef UNICODE
   typedef LPCWSTR LPCTSTR;
#else
   typedef LPCSTR LPCTSTR;
#endif

у вас же в любом случае используется LPCWSTR.
Далее, обратите внимание, в том же мсдн, на разницу между std::string и std::wstring

В общем напутали вы с преобразованием, использованием юникода и настройками проекта.
Уберите все лишнее и будет работать, а на юникод заточите когда в ANSI заработает.

Здравствуйте, JumangeeNET, Вы писали:

JNE>Здравствуйте

JNE>Проблема странная, но есть. При подключении DLL с помощью LoadLibrary она возвращает 0, а GetLastError = 126 — "Не найден указанный модуль". Эта ошибка вроде как должна появляться только если не найдены модули от которых зависит моя DLL, но они все рядом! Проверял с помощью Dependency Walker — больше никакие не нужны вроде как (он сказал что нужна msvcr80.dll её и всех похожих на нее я подложил рядом, при этом, vc2005 цепляет ее при запуске сам судя по 'core.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_...\msvcp80.dll', No symbols loaded. ). DLL пробовал цеплять и с абсолютными путями, и с относительным....

Выделенное — разные реально существующие dll.

Здравствуйте, Sergey Chadov, Вы писали:

SC>Выделенное — разные реально существующие dll.
Dependency Walker говорил всё-таки про неё, но для уверенности на 110% рядом с подгружаемой dll лежат:
msvcr80.dll
msvcr80d.dll
msvcrt.dll
msvcm80d.dll
msvcp80d.dll
msvcp80.dll
msvcm80.dll
msvcp60.dll
atl.dll
mfc42.dll
mfc42u.dll
msxml4r.dll
comctl32.dll
msvcirt.dll
rtcdll.dll
vdr.dll

(подгружается — vdr.dll)

Я думаю, что такого запаса должно хватать, но не хватает по-видимому...

Здравствуйте, eklmn, Вы писали:

E>В общем напутали вы с преобразованием, использованием юникода и настройками проекта.
E>Уберите все лишнее и будет работать, а на юникод заточите когда в ANSI заработает.
О великий! СПАСИБИЩЕ!!! Помогло!!!
Не знаю где, но директива UNICODE действительно где-то прописана, заменив LoadLibrary на LoadLibraryA библиотека подцепилась! СПАСИБО!

Здравствуйте, JumangeeNET, Вы писали:

JNE>Не знаю где, но директива UNICODE действительно где-то прописана

Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions.

Здравствуйте, eklmn, Вы писали:

E>Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions.
В том-то и дело, что там UNICODE нету

Здравствуйте, JumangeeNET, Вы писали:

JNE>Здравствуйте, eklmn, Вы писали:

E>>Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions.
JNE>В том-то и дело, что там UNICODE нету

Ну, тогда Configuration Properties -> General -> Character Set.

1. msv*80*.dll — Side-By-Side библиотеки. Одной из их особенностей является то, что они не могут быть "подхвачены", если лежат там же. Их нужно устанавливать дистрибутивом microsoft'а или создавать нужную иерархию директорий (не помню какую).
2. С использованием LoadLibraryA вы погорячились, т. к. потом вы забьете на Unicode и все у вас так и останется (после трех безуспешных попыток "подточить" под UNICODE, конечно). Используйте LoadLibrary и строки в виде basic_string<TCHAR> вместо string (basic_string<char>), а в настройках проекта включите в "Character set" UNICODE.

Здравствуйте, -MyXa-, Вы писали:

MX>Ну, тогда Configuration Properties -> General -> Character Set.
Спасибо, там нашёл

Здравствуйте, bordima, Вы писали:

B>2. С использованием LoadLibraryA вы погорячились, т. к. потом вы забьете на Unicode и все у вас так и останется (после трех безуспешных попыток "подточить" под UNICODE, конечно). Используйте LoadLibrary и строки в виде basic_string<TCHAR> вместо string (basic_string<char>), а в настройках проекта включите в "Character set" UNICODE.
Пока даже не думал подтачивать под юникод, думаю делать только анси

Это вы зря (вы уверены, например, что в пути к вашей .dll не встретится кириллица?), но не мне вас судить. Если так уверены, то просто отключите использование UNICODE в настройках проекта (character set) и используйте функцию LoadLibrary, а препроцессор подставит нужную вам ANSI версию функции (так, хорошего стиля ради).

bordima пишет:
> Это вы зря (вы уверены, например, что в пути к вашей .dll не встретится
> кириллица?), но не мне вас судить. Е

Вообще-то, если всё правильно сделано, кирилица будет работать и без юникода.
В ANSI.

MZ>Вообще-то, если всё правильно сделано, кирилица будет работать и без юникода.
MZ>В ANSI.

Да, и если в ОС текущей кодовой страницей (codepage) является windows-1251. Ссылка по теме.