Взаимодействие 64-х битного приложения с 32-х битной библиотекой

← →
Германн © (2012-03-30 01:41) [0]

Имеется чьё-то чужое 64-х битное приложение и "не совсем чужая" библиотека созданная в 32-х битной Дельфи как (я так понимаю) "ActiveX library". Правы ли создатели того приложения, что создателям библиотеки нужно обязательно перекомпилировать библиотеку в 64-х битной Дельфи?
P.S. В технологии СОМ я не силён.

← →
Дмитрий С © (2012-03-30 01:51) [1]

http://msdn.microsoft.com/en-us/library/windows/desktop/ms693716%28v=vs.85%29.aspx

Тут что-то про это расписано, но в 2 ночи не могу понять нерусский.

← →
Германн © (2012-03-30 02:50) [2]

> но в 2 ночи не могу понять нерусский.

В третьем часу вечера я не могу понять как связан сей документ с моим вопросом. Даже зная "нерусский" :)
Но мне не к спеху. :)

← →
DVM © (2012-03-30 07:29) [3]

> Правы ли создатели того приложения, что создателям библиотеки
> нужно обязательно перекомпилировать библиотеку в 64-х битной
> Дельфи?

Тут COM даже как бы и не причем. Какая разница COM или не COM - так или иначе COM это лишь надстройка над WinAPI, т.е это определенные правила игры.
Ну вот сам смотри. Внутри 64 бит приложения указатели имеют размер 64, внутри dll - 32. Как следствие, типы HANDLE, HMODULE, HWND и т.д. тоже меняют размерность. Если такие типы смотрят наружу, явно или косвенно то ответ очевиден. Но это не единственная причина несовместимости.

← →
Anatoly Podgoretsky © (2012-03-30 08:49) [4]

> Германн © (30.03.12 02:50) [2]

Там сказано, что теперь COM не требуется в двух версиях, а может быть два в одном 64 и 32 бита. Этого достаточно для ответа на твой вопрос и понять к чему это относится.

← →
han_malign (2012-03-30 09:17) [5]

> Тут COM даже как бы и не причем.

- COM-обвязка, с out-of-process маршалингом - по словам Реймонда Чена - единственный способ подружить 32 и 64 бита...

COM - вроде как умеет загружать CLSCTX_INPROC_SERVER - в отдельный proxy-процесс и маршалить - но умен ли он настолько, чтобы делать это автоматом при 64.vs.32 не знаю(смутно вспоминается что-то связанное с CLSCTX_INPROC_HANDLER и дефолтным InprocHandler = ole32.dll)...

З.Ы. Чтобы не писать свои заглушки - нужно использовать в интерфейсе только "автоматизированные" типы(OLE Automation), но для Delphi(и С#) - это как раз норма...

← →
han_malign (2012-03-30 09:25) [6]

> ActiveX library

- а блин, не заметил - ActiveX с окнами - означает, что это исключительно CLSCTX_INPROC_SERVER - без всяких маршалингов - никакие заглушки не прокатят...
(32-битный IE оставлен в 64-битных системах из-за того, что 99% существующих ActiveX-приблуд никогда не станут 64-битными)

> - COM-обвязка, с out-of-process маршалингом - по словам
> Реймонда Чена - единственный способ подружить 32 и 64 бита.
> ..

Это вообще-то логично. Даже 1С клиента х64 не поставляет по этим причинам. А add-in-ы теперь аж в четырех вариантах.

← →
знайка (2012-03-30 10:25) [8]

> Правы ли создатели того приложения, что создателям библиотеки
> нужно обязательно перекомпилировать библиотеку в 64-х битной
> Дельфи?
Правы.

> tesseract © (30.03.12 10:13) [7]
>
>
> > - COM-обвязка, с out-of-process маршалингом - по словам
> > Реймонда Чена - единственный способ подружить 32 и 64
> бита.
> > ..
>
>
> Это вообще-то логично. Даже 1С клиента х64 не поставляет
> по этим причинам.

Можешь пояснить своё высказывание? Ибо мой вопрос действительно имеет отношение к 1С.

Взаимодействие 64-х битного приложения с 32-х битной библиотекой Найти похожие ветки