Ещё вопрос по длл.
Т.е. и выхывать я её должен тоже с этим именем.
т.е вместо LoadLibrary("SomeFunc") писать LoadLibrary("_SomeFunc@NN").
Можно как нибудь обойти эту хрень? Изменять DEF файл?
---------------
Цитата:
Originally posted by Lucefer
При объявлении функции как __stdcall ей присоваивается имя вида _SomeFunc@NN (NN - размер в байтах суммы размеров аргументов, в оригинале SomeFunc)
Т.е. и выхывать я её должен тоже с этим именем.
т.е вместо LoadLibrary("SomeFunc") писать LoadLibrary("_SomeFunc@NN").
Можно как нибудь обойти эту хрень? Изменять DEF файл?
---------------
При объявлении функции как __stdcall ей присоваивается имя вида _SomeFunc@NN (NN - размер в байтах суммы размеров аргументов, в оригинале SomeFunc)
Т.е. и выхывать я её должен тоже с этим именем.
т.е вместо LoadLibrary("SomeFunc") писать LoadLibrary("_SomeFunc@NN").
Можно как нибудь обойти эту хрень? Изменять DEF файл?
---------------
extern "C"
Цитата:
Originally posted by Green
extern "C"
extern "C"
Именно так и написано:
extern "C" __declspec(dllexport) LRESULT CALLBACK KeyLLFilterFunc(int nCode, WPARAM wParam, LPARAM lParam);
А получаю: _KeyLLFilterFunc@12
Цитата:
Originally posted by Lucefer
Именно так и написано:
extern "C" __declspec(dllexport) LRESULT CALLBACK KeyLLFilterFunc(int nCode, WPARAM wParam, LPARAM lParam);
Именно так и написано:
extern "C" __declspec(dllexport) LRESULT CALLBACK KeyLLFilterFunc(int nCode, WPARAM wParam, LPARAM lParam);
Это объявление функции, а в определении?
Цитата:
Originally posted by Lucefer
А получаю: _KeyLLFilterFunc@12
А получаю: _KeyLLFilterFunc@12
Получаешь где? Как определяешь?
Цитата:
Originally posted by Green
Получаешь где? Как определяешь?
Получаешь где? Как определяешь?
Началось с того, что после компиляции экзешник не смог работать, так как функция GetProcAddress не смогла найти процедуру. Пришлось воспользоваться старой и провереной утилитой: ShowDep
Во вложении. Желательно проверить на вируси. Ибо может быть всякое...
Цитата:
Have you ever seen a message box wich told you that “The dynamic link library XXX.DLL could not be found in the specified path....” ? Suppose you are an advanced user and you found somewhere that XXX.DLL and copied it to the proper folder. You ran your application again and had been told about “... YYY.DLL could not be found in the specified path....”. And so on. We call it “trial and error” approach.
Suppose you are a developer. Have you ever call LoadLibrary(XXX.DLL) and get an error ERROR_DLL_NOT_FOUND (1157)? Do I hit a nerve? And you scanned your hard drive for XXX.DLL, found it in your system directory and stared at it trying to understand what was wrong. Of course, if you are a real developer, you ran DUMPBIN or QuickView to check its imports, then scanned for imported modules, ran DUMPBIN again, scanned for imported modules...
Suppose you are working for a big company and you must certify some new software that should be installed on your 2,000 client machines. Certification requires a complete list of all modules used by that software including all version/copyright information about those modules. And it would be nice to do it from your administrator’s machine.
ShowDep can help you. It tracks down all DLLs implicitly linked to a given 32-bit module. It shows you entire module hierarchy including missing/invalid modules and the following information about each item of this hierarchy:
· detailed module version information, including VS_FIXEDFILEINFO structure and following string entries
· Original Filename
· Internal Name
· File Description
· File Version
· Product Name
· Product Version
· Company Name
· Legal Copyright
· Legal Trademarks
· Comments
· Private Build
· Special Build
· all fields of PE Header and PE Optional Header
· module sections information
· all module imports
· all module exports including forwards
· import-export conflicts
· export-forward conflicts
The results can also be written to a text or RTF file.
Тоже самое делает стандартная утилита, поставляемая вместе с VC - Dependency Walker.