Re: импорт из dll в VC6

From

Andrey Voitenkov ()

To

Boris Rudakov ()

Date

2003-10-21T16:56:42Z

Area

CARBON.COPY

 * Forwarded from area 'SU.WINDOWS.PROG'
From: Andrey Voitenkov <mccloud@vimas.com>

Boris Rudakov wrote:

[...]

>  AV> Нет, я про Powersoft Watcom 11.0B. Вышел он где-то в 98-99 годах, если
>  AV> мне память не изменяет.
> 
> Ааааа, тооот...
> Не, тот мне как-то не особо понравился. Чувствовалось что пакет подыхает, все
> какое-то неопрятное, странное, устаревшее...

Ага, похоже было, что они из последних сил склепали оболочку для Win32,
сами компиляторы там очень даже ничего, хотя тоже были глюки, даже
скорее недоделки, нежели глюки.
Но в сочетании с MultiEdit 8 получалась вполне комфортная среда
разработки (IMO) :)

> 
> А вот на OpenWatcom я хочу посмотреть сильно.

Поставил качаться, через пару дней сольется, гляну что оно такое.

[...]

>  AV> У них(ватком), в их конвенции register использовалось больше
>  AV> регистров, чем у микрософта и использовались они не совсем совместимо
>  AV> в __fastall.
> 
> Давай не будем забывать что порядок использования регистров у компайлеров
> разный ? У Борланда с мелкософтом они тоже отличаются, хотя декларация одна -
> __stdcall. Я же не зря упомянул что Борланд ввел еще одну модель - __msfastcall
> которая полностью эквивалентна мелкософтовскому __fastcall. Так что не надо
> удивляться что у Ваткома их __fastcall с Мелкософтом тоже несовместим.
> 
> Кстати, нисколько не удивлюсь если узнаю что борландовский и ваткомовский
> __fastcall между собой совместимы.
> 

Вот этого не знаю, врать не буду.
Я весьма слабо знаком с Борландом, работал только в 3.1 для ДОСа.
Когда вышел 5.0, я был в ужасе и перелез на Ватком :)

[...]

>  AV> Там можно было извратиться сделать такой трюк: указать конвенцию
>  AV> register для проекта и проэкспортировать функцию без указания
>  AV> конвенции в декларации.
> Это грубая ошибка - не указывать модель вызова.
> 

К сожалению, не только грубая, но и очень распространенная :/
Потому я и проверяю вызовы функций библиотек сторонних производителей,
которых я не знаю.

[...]

> 
> Угу. Достаточно грубая и распространенная ошибка - не указывать модель вызова.
> Точно такая же ошибка - забывать про pragma pack. Этим грешит огорчительно
> много разработчиков и именно по вниманию к этим деталям оформления можно
> отличить опытного профессионала от среднего программера.
> 

Ага, я как раз о том же :)

>  AV> Ну так в том и дело, что я не считаю наличие .h полным описанием
>  AV> интерфейса.
> 
> И делаешь ошибку :)
> 
> Инклуд содержит ПОЛНОЕ и ИСЧЕРПЫВАЮЩЕЕ описание интерфейса функций. Если этого
> описания достаточно компайлеру чтобы создать их, то о чем вообще можно говорить
> ?! :):):)
> 
> Даже если в связи с неопрятностью программера забыты модели вызова и
> определение выравнивания - есть дефолты.
> 
> .h - совершенно исчерпывающее определение.
> 

Так должно быть, не спорю, но вот на практике приходится иметь дело с
людьми, и пресловутым человеческим фактором.
И даже не с "забыл", а с "не знал"; вот это и есть основания для моей
паранойи, о которой я и говорил тут:

>  AV> В большинстве случаев хедера достаточно, но у меня уже есть паранойя,
>  AV> потому и проверяю, если речь идет не об академических экспериментах.
> 
> Это именно паранойя, причем - не имеющая под собой никаких оснований :)
> 

Основания чуть выше описаны. Я с надеждой смотрю на C#, там микрософт
очень жестко рамки расставил, компилятор не позволит экспортировать
что либо, если это что-либо не соответствует стандарту платформы CLR.

[...]
>  AV> Инициатору треда можно предложить создать в VC пустую dll с тем же
>  AV> именем, и с теми же экспортами, что описаны в имеющемся хедере и
>  AV> получить библиотеку импорта непосредственно от линкера.
> 
> Совершенно нормальный вариант :)
> 
> Я так поступаю иногда, когда лом с impdef/lib возиться :)
> Это бывает когда либа большая и вусмерть лениво править def под сраный
> мелкософтовский мэнглинг. Тогда и вправду быстрее сделать .c, определить в нем
> болванки функций и компилльнуть с целью получить .lib :)
> 

Я извращался в Perl'ом в таких ситуациях... и похоже, что таки быстрее
действительно написать .c

> Что, кстати, еще раз демонстрирует что мелкософт - сволочи и уроды: вынуждать
> устраивать на ровном месте из-за совершенно несущественной мелкой задачки такой
> геморрой !
> 
Ну с этим я никогда не спорил :)))

>  AV> По моему это самый удачный вариант будет.
> 
> Увы, этот вариант - ровно настолько же неудачный и кривой как и все остальные
> :( И ровно настолько же "надежный", в плане твоей необоснованной паранои. Чтобы
> сбацать dummy-dll (с целью получить лишь ее .lib) тебе все-равно нужен .h
> который у тебя или есть, или все о чем мы говорим - отменяется даже не
> начинаясь :) Этот .h либо правильный, либо опять все отменяется. А в таком
> разе, глубоко пофигу будешь ли ты создавать .lib с помощью левой .dll или же
> через .def
> 

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

> Все эти варианты одинаково кривы и геморройны. За всех за них - огромное
> "спасибо" драному мелкософту.
> 
> Идинственно-прямой вариант - утилита implib:
> 
> implib libname.lib libname.dll
> 
> Бо нехер устраивать гемор там, где его быть не должно.
> 
Зато они теперь громогласно заявляют, что решили эту проблему .NET,
правда скромно молчат о том, кто ее создал.

-- 
mccloud@

--- ifmail v.2.15dev5
 * Origin: Datacom (2:5020/400)