Вопросов на эту тему было уйма. Моя трабла - то же самое, вид сбоку. Если у кого есть этот момент - вникните, плиз.

VC98
Два проекта
Dll + вызывающее консольное приложение.

1. Если в dll объявлять экспортируемую функцию func как __cdecl и посмотреть
затем в мап-фале - называться она будет _func, но GetProcAddress в вызывающем приложении работает с именем "func". Все счастливы.

2. Если экспортируемую функцию объявить как __stdcall, то в мапфайле ее обнаруживаешь как _func@x, где x размер аргументов в байтах. Соответственно,
GetProcAddress работает по этому кривому имени, например _func@8

3.Соответственно, если _cdecl функцию пытаться вызвать по __stdcall указателю
получим эксцепшн.

Возникла идея проверить как оно работает с виндовыми длл-лями. Понять как определены функции в том же kernel32.dll - не могу в студии есть хедеры только для либов (другие и не нужны).Однако радость в том, что как ни описывай указатель на получаемую через GetProcAddress (указатель на) функцию - хоть __stdcall, хоть __cdecl - никаких эксцепшенов нет и все работает (проверял). Для последнего случая, возможно, компилятор молча устраняет ошибку (бред, но ничего другого в голову не пришло).

К вопросу, зачем все эти пляски с бубном.
Дело в том, что консольное приложение служит исколючительно для тестирования, а работать с ДЛЛ придется из некоего рантайма, где, впроде как, функции из DLL импортируются будучи _stdcall. Поэтому перспектива получать адрес длл-ой функции по имени _func@8 - не очень впечатляет.

И еще вопрос -
__stdcall, WINAPI, PASCAL соглашения не есть ли одно и то же? Буду признателен, если ткнете носом в доку.

Айл би бэк.

Нет, не в этом.
Вопрос о справедливости - ибо не верится мне, что так и задумано было - звать _hhh@8 - это есть неверный путь. Сдается мне, что я просто что-то не учел.

С помощью деф-файла уверен, что можно, но
1. Не делал и не пробовал и (поправьте меня, если я не заметил) в студии это не есть стандартный тул - т.е. подразумевается возможность нормальной работы и без них. А вот, не получается.

2) если Вы грузите НЕ ЯВНО, то для этих целей служит ашничек и либ файл, который в принцепе и делает связывание имён при загрузке (не обязательно) Вашего экзешничка. В данном случае экспортируемое-импортируемое имя до фонаря и чтоб не налететь на конфликт имён компилятор генерит бла-бла-бла-собака-имя типа того...

Не интересно. Вопрос не про это. По-моему по первому посту было ясно, что явная загрузка.

3) деф файл - стандартный способ указания ЯВНЫХ имён ЯВНЫМ функциям-классам-переменным...пример выше был приведён корректно и описывал этот подход.
(круглый)
Где в 98 студии работа с дефами? И, вообще, это немного в сторону.

4) В добавок при описании вашего экспорта-импорта декларируется правило работы с передаваемыми параметрами (кто чистит вызывающий или вызываемая, в случае с функциями и методами)...

Повторю вопрос. Студия умеет собирать ДЛЛ без дефов (или же делает вид, что без дефов). Не суть - требуется только сурс и ключик компайлера. Однако же,
при явной загрузке получаемой ДЛЛ получить указатель на экспортную функцию для ее варианта не __cdecl по ее указаному имени не получается. Приходится использовать кривые имена, что для меня означает одно - что я что-то криво сделал на этапе сборки длл. Однако, что же?

В качестве отдельного размышления - привел пример явной загрузки функций из стандартных виндовых длл - оказывается пофигу, какой тип соглашения указать для указателя. Что, по меньшей мере, странно.

И, кажется, все это я уже писал выше.

Вам, коллега, спасибо за участие. Но, к сожалению, ответ несколько не туда.

White Owl T800что я что-то криво сделал на этапе сборки длл. Однако, что же? Не использовал def-файл при сборке dll.


Сенкс.

Однако, не понял ваши слова по поводу стандартных виндовых длл. Если функция описана как __cdecl, то при использовании указателя __stdcall - я вылечу с ошибкой, и вайс верса.

Смущает меня (как в свое время древнего человека молния) то, что для одно и той же (подчеркиваю - одной и той же) функции из, например kernel32.dll можно использовать для хранения адреса указатели для разных типов соглашений.

Поясните, пожалуйста.

Спасибо

Летсгоу.

Из Вашего поста лично мне показалось, что Вы не до конца понимаете происходящее...
Ну, раз так выглядит со стороны..

T800Где в 98 студии работа с дефами?[/quot ]

[quot]Может подвести память, но на дереве проджекта правая клавиша крыски и добавить новый файл (искать Module-Definition file). Даже в последних студиях не убрали - что косвенно подтверждает СТАНДАРТИЗАЦИЮ данного подхода.
Ну, там есть вообще *.* маска :) Проблема не в том, чтобы деф добавить, вопрос о том, что деф инструмент, как минимум необязательный.. Только, вот, как показывает практика - без него не работает.
Ну и студия, например при создании ДЛЛ проекта про деф молчит. При создании симпл длл проекта дефа нет. Т.е. я расценил это как предложение работать без оного.

ответ уже прозвучал помоему. достаточно обьявить о порядке вызова данной функции. В дефе?
В оригинале, (ну, раз мой великий и могучий подвел и все было непонятно) меня интересовал вопрос, возможно ли (без использования дефов) с помощью VС написать длл и явно ее грузить и вызывать функции по имени, при условии, что экспортируемые функции длл определены как __stdcall?
Если вы скажете: "Брателло, ты че, не знаешь, что если в длл экспортируется __stdcall функция, то при явной загрузке библиотеки можно только или звать ее по кривому имени либо юзать деф-файл. И это нормально." - я пойму. Но никто так не сказал.

Я не понимаю, почему, если я объявляю функцию как __cdecl никакой деф нах не нужен. Но если как __stdcall - то обязательно. Или это стандарт такой?
Я просто не знаю.
Вот и спрашиваю - почему __cdecl работает а __stdcall - нет. Если дэф нужен обязательно, почему при экспорте __cdecl функций и без него все хорошо?

Прочитал (то, что выше). Тоже не по-русски. Надеюсь, переведете.


это всё только кажеться... укажите другой порядок очистки стэка вызываемой функции и привет семье обспечен...

Этот вопрос снимаю с повестки, ибо, написав очередной пример, вылетел, дернув kernel32.dll FreeLibrary через __cdecl указатель (чему обрадовался, ибо так быть и должно).. Посмотрю еще разик на других функциях. Странно, если приглючилось. С другой стороны - пусть лучше это меня плющит, чем окажется, что все - матрица.

Спасибо.

MasterZivНа данный момент стандартные соглашения на экспортируемые функции в Win32 - это __stdcall. Его надо использовать.

WINAPI, PASCAL - это макросы, которые преобразуются в нужный модификатор, указывающий на соглашения о вызовах функции.

WINAPI ==> __stdcall
PASCAL ==> __pascal (или __fortran)

Вот если бы не встретил во всякого рода бумажках фразу, что стандартное соглашение для апишных функций - PASCAL ...
__stdcall == WINAPI == PASCAL
Вот что пишут люди. Они правы?

MasterZiv T800
ибо не верится мне, что так и задумано было - звать _hhh@8 - это есть неверный путь. Сдается мне, что я просто что-то не учел.


Так и задумано. Есть имя функции в словаре глобальных ссылок. Это одно имя.
И есть имя функции в словаре импорта и в словаре экспорта. Это второе имя. Эти имена в принципе разные, они не обязаны совпадать. Второго имени вообще может не быть, можно производить импорт и экспорт по номерам. Можно и по номерам, и по именам.

Тогда получается, что товарищи из МАГАКОРПОРАЦИИ предусмотрели, что при сборке DLL для cdecl функции имя в словаре импорта будет таким же, как я определил в коде, а для остальных - как получится. Так?

MasterZiv T800 MasterZiv
Вот если бы не встретил во всякого рода бумажках фразу, что стандартное соглашение для апишных функций - PASCAL ...
[quot ]__stdcall == WINAPI == PASCAL
Вот что пишут люди. Они правы?

Это было давно, в WIN16. Сейчас, в Win32 , -- __stdcall

1. Тогда надо подробнее. Соглашения о вызовах для Win16 и 32 отличаются, т.е. Win16 stdcall не есть Win32 stdcall.
За тупость простите, но это так?

2. Win32 PASCAL соглашение - само по себе - оно не Win32 stdcall.
Оба существуют параллельно.
Так?


Спасибо.

И да и нет. Ты действительно можешь независимо использовать PASCAL или stdcall модификаторы при объявлении функций. Но при компиляции они оба превратятся в одно и тоже.

Не, ну тогда вы меня просто запутали предыдущим постом. А утверждение
WINAPI=PASCAL=__stdcall верно.

Спасибо.

White Owl T800Тогда получается, что товарищи из МАГАКОРПОРАЦИИ предусмотрели, что при сборке DLL для cdecl функции имя в словаре импорта будет таким же, как я определил в коде, а для остальных - как получится. Так?Да.


странная логика, однако.. это, наверное, у них религиозные предпочтения.

А с дрегими компайлерам, борландовским, например та же фигня? Или вы не пробовали, в силу того, что собираете только с дефами?

получаешь в CryptBy.dll два экспортируемых имени CryptByAA и _CryptBy55@4

Кстати. Как я понял, в мап-файле указаны экспортируемые имена. Так для _cdecl функций перед именем стоит андерско, но указатель GetProcAddress возвращает по имени без оного. Кроме того, в дельфевском (или басиковском) форуме я видел, что людям приходится звать _cdecl функции в виде _fname..
Так что, похоже, здесь нам помогает невидима рука Билли-Воротчика.

White Owl
Идем в windef.h и видим там такой кусок:
...


Спасибо.

В голове представилась предыстория, результатом которой стал этот хедер.

Стало грустно.