Каким образом создается COM-сервер?

← →
Пит (2013-05-29 16:25) [0]

Хочется понять с точки зрения работы Windows / Delphi

Вот имеем стандартный вызов для работы с word"ом:

CreateOleObject("Word.Application");

Который разбивается приблизительно на два вызова: CLSIDFromProgID и CoCreateInstance.

Как же это работает с точки зрения Windows?
Допустим, по "Word.Application" можно найти такую запись в реестре:

[HKEY_CLASSES_ROOT\Word.Application] @="Microsoft Word Application" [HKEY_CLASSES_ROOT\Word.Application\CLSID] @="{000209FF-0000-0000-C000-000000000046}" [HKEY_CLASSES_ROOT\Word.Application\CurVer] @="Word.Application.14"

Ок, нашли GUID {000209FF-0000-0000-C000-000000000046}, ищем опять в реестре, находим:

[HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046}] [HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046}\InprocServer32] "Assembly"="Microsoft.Office.Interop.Word, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" "Class"="Microsoft.Office.Interop.Word.ApplicationClass" "RuntimeVersion"="v2.0.50727" [HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046}\InprocServer32\14.0.0.0] "Assembly"="Microsoft.Office.Interop.Word, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" "Class"="Microsoft.Office.Interop.Word.ApplicationClass" "RuntimeVersion"="v2.0.50727"

Вот и все! Где путь, по которой надо грузить DLL или запускать EXE с com-сервером? Как-то нету...
Раньше в XP помню было более понятно, там в параметрах стояло что-то типа: "...word.exe /automation" - я хоть понимал, что Windows могла делать.

А это пример из Win7 с офисом 2010, как же тут работает? Есть мысль поискать по "Microsoft.Office.Interop.Word" - но поиск в реестре что-то особо ничего не находит.

← →
Rouse_ © (2013-05-29 16:34) [1]

http://support.microsoft.com/kb/185126

← →
megavoid © (2013-05-29 16:42) [2]

Может вот это поможет: http://progtutorials.tripod.com/COM.htm

← →
icWasya © (2013-05-29 17:20) [3]

Ну путь находится в
HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046}\LocalServer32 "LocalServer32"=
в котором стоит сылка на последний установленный оффис.

← →
Пит (2013-05-29 18:38) [4]

> http://support.microsoft.com/kb/185126

Розыч, а это здесь причем,я тебя не понимать.

Вопрос в том, что все работает. А вот почему работает - смысл вопроса.
И уж NT 4.0 тут нету никак.

> Может вот это поможет: http://progtutorials.tripod.com/COM.
> htm

может быть. Я почитал по диагонали - ничего не понял, причем тут сабж.

> Ну путь находится в
> HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046}\LocalServer32
> "LocalServer32"=

кажется, я выше выложил всю ветку HKEY_CLASSES_ROOT\CLSID\{000209FF-0000-0000-C000-000000000046}, нет там никакого LocalServer32.

В WinXP и офисе XP да, можно наблюдать LocalServer32 и значение по-умолчанию:
C:\PROGRA~1\MICROS~2\Office10\WINWORD.EXE /Automation

Но в топике я привел пример компьютера, где стоит Win7 64-битная, также установлен Office 2010. Вот и возник вопрос - а как там все работает.

← →
Rouse_ © (2013-05-29 18:44) [5]

> Розыч, а это здесь причем,я тебя не понимать.

При том что исполняемые файлы пишутся в LocalServer32, а в InprocServer32, где ты зачем-то искал, пишутся библиотеки.

> кажется, я выше выложил всю ветку HKEY_CLASSES_ROOT\CLSID\{000209FF-
> 0000-0000-C000-000000000046}, нет там никакого LocalServer32.

у меня есть

← →
Rouse_ © (2013-05-29 18:47) [6]

У тебя кстати винда 64 бита а офис какой? Если 32 - то он в роаминг подветке будет прописываться.
В случае 32 и 32 - все ровно.
И вообще поиск "word.exe /automation" по реестру и все увидишь где как и зачем.

← →
Пит (2013-05-29 19:34) [7]

> При том что исполняемые файлы пишутся в LocalServer32, а
> в InprocServer32, где ты зачем-то искал, пишутся библиотеки.
>

откуда мнение, что я искал в InprocServer32? Я искал по всему реестру, в топике я выложил полный экспорт ветки: "{000209FF-0000-0000-C000-000000000046}"

> у меня есть

а у меня нету. И при этом стандартная конструкция CreateOleObject("Word.Application"); работает.
В общем, читаем нулевой пост...

Вопрос - как оно работает?

> И вообще поиск "word.exe /automation" по реестру и все увидишь
> где как и зачем.

эт ты толково придумал!
Поискал... нашлось вот что:

> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-
> C000-000000000046}]
> @="Microsoft Word Application"
>
> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-
> C000-000000000046}\InprocHandler32]
> @="ole32.dll"
>
> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-
> C000-000000000046}\InprocServer32]
> "Assembly"="Microsoft.Office.Interop.Word, Version=14.0.
> 0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
> "Class"="Microsoft.Office.Interop.Word.ApplicationClass"
> "RuntimeVersion"="v2.0.50727"
>
> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-
> C000-000000000046}\InprocServer32\14.0.0.0]
> "Assembly"="Microsoft.Office.Interop.Word, Version=14.0.
> 0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
> "Class"="Microsoft.Office.Interop.Word.ApplicationClass"
> "RuntimeVersion"="v2.0.50727"
>
> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-
> C000-000000000046}\LocalServer32]
> @="C:\\PROGRA~2\\MICROS~1\\Office14\\WINWORD.EXE /Automation"
> "LocalServer32"=hex(7):78,00,62,00,27,00,42,00,56,00,35,
> 00,21,00,21,00,21,00,\
> 21,00,21,00,21,00,21,00,21,00,21,00,4d,00,4b,00,4b,00,
> 53,00,6b,00,57,00,4f,\
> 00,52,00,44,00,46,00,69,00,6c,00,65,00,73,00,3e,00,62,
> 00,69,00,24,00,54,00,\
> 21,00,56,00,21,00,30,00,5a,00,3d,00,7b,00,50,00,6b,00,
> 30,00,76,00,6d,00,7e,\
> 00,41,00,5a,00,75,00,20,00,2f,00,41,00,75,00,74,00,6f,
> 00,6d,00,61,00,74,00,\
> 69,00,6f,00,6e,00,00,00,00,00
>
> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-
> C000-000000000046}\ProgID]
> @="Word.Application.14"
>
> [HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{000209FF-0000-0000-
> C000-000000000046}\VersionIndependentProgID]
> @="Word.Application"

итак... что я могу предположить.

Если винда 64 бита видит, что приложение 32-ух битное и лезет в HKEY_CLASSES_ROOT\CLSID, то реально винда подставляет ему ветку: HKEY_CLASSES_ROOT\Wow6432Node\CLSID\

Есть вопросы:

1) если предположение верное - а зачем вообще такое разделение? Типа 64-битный com-сервер не может быть запущен для 32-ух битного приложения? А почему?
Тем более, com-сервер в виде exe"шника.

2) А если рассмотреть com-сервер в виде DLL - интересно, можно ли грузить 64-битные DLL в адресное пространство 32-ух битного процесса? Видимо, нет... А вот наоборот - 32ух битные com-сервера в 64-битный процесс, в чем проблема?

← →
Rouse_ © (2013-05-29 19:39) [8]

Битность разная. Это ответ на оба вопроса.

← →
Anatoly Podgoretsky © (2013-05-29 19:55) [9]

Давай адрес, пришлю статью Тенцера по созданию СОМ серверов.

← →
Пит (2013-05-29 20:02) [10]

> Anatoly Podgoretsky

piterm@gmail.com

← →
Пит (2013-05-29 20:03) [11]

> Битность разная

ты сча выступил как математик))

- где мы находимся?
- на воздушном шаре!

← →
Rouse_ © (2013-05-29 21:43) [12]

> Пит (29.05.13 20:03) [11]

Блин, Миш, ну а как по другому? 32 битный и 64 битный код в одном адресном пространстве смешать можно, но очень затратно. Загрузчик будет обслуживать только изначальный режим приложения. Т.е. если ты в 32 битном приложении переключишься в контекст 64 бит через WOW регистр, тебе никто не запретит подгрузить 64 битную библиотеку, только есть нюанс - а как ты ее подгружать то будешь? Ведь LoadLibrary то у тебя 32 битная, стало быть тебе придется реализовать аналог того что делает загрузчик только для одной маленькой цели - выйти на 64 битную библиотеку. Это геморой, реализуемый и у меня есть даже код, но геморой.

← →
Пит (2013-05-29 22:54) [13]

Rouse_, хочешь ли ты сказать, что поставив 32-ух битный офис (а я слышал, что сама MS рекомендует ставить именно 32-ух битный) - им нельзя управлять из 64-битных приложений?

То есть, вот это простейшее OLE-встраивание в свою формы нельзя будет осуществить?

← →
Rouse_ © (2013-05-29 22:56) [14]

> Пит (29.05.13 22:54) [13]
> Rouse_, хочешь ли ты сказать, что поставив 32-ух битный
> офис (а я слышал, что сама MS рекомендует ставить именно
> 32-ух битный) - им нельзя управлять из 64-битных приложений?

Конечно можно, у них-же полноценный шлюз есть соответствующей битности.
Т.е. если ты 32 бита - ты будешь работать с 32 битной библиотекой, то же верно и для 64 бит.

← →
Пит (2013-05-30 00:39) [15]

Rouse_, можно поподробнее?

Мы рассматриваем ситуацию, что винда 64-бита, я в ней сделал приложение 64-ех битное и вот я вызываю:

CreateOleObject("MyParamPamPam");

А DLL, реализующая COM-объект "MyParamPamPam" только 32-ух битная в системе. Значит, все, приплыли?
Только что же шла речь о том, что 32-ух битную DLL в пространство 64-битного процесса просто так не впихнешь.

← →
Rouse_ © (2013-05-30 10:23) [16]

> Значит, все, приплыли?

Значит приплыли.
Есть конечно мудреные способы, наподобие: http://rakafon.blogspot.ru/2009/04/32-bit-dll-64-bit.html

← →
Kerk © (2013-05-30 10:30) [17]

> Пит (30.05.13 00:39) [15]

Твой шанс - это запустить COM-сервер в отдельном процессе. COM обычно это поддерживает.

Вот с DLL все плохо. Если ситуация такова, то лучше просто забей. Я наверно месяца три убил с редкими перерывами, чтобы прикрутить 64битный клиент Oracle к 32битному приложению. И намерен теперь года три этим фактом гордиться.

← →
Kerk © (2013-05-30 10:31) [18]

А, ну да. Про COM как раз по ссылке в [16] есть.

← →
Kerk © (2013-05-30 10:37) [19]

А нет, похоже был не прав. С COM не намного менее муторная фигня.

← →
Anatoly Podgoretsky © (2013-05-30 10:58) [20]

> Kerk (30.05.2013 10:30:17) [17]

Сколько осталось?

← →
Kerk © (2013-05-30 11:05) [21]

> Anatoly Podgoretsky © (30.05.13 10:58) [20]
>
> > Kerk (30.05.2013 10:30:17) [17]
>
> Сколько осталось?

Что осталось?
Делать? Так все - завтра RTM. Поздравления принимаются :)
Гордиться? Долго еще :)

← →
Rouse_ © (2013-05-30 11:26) [22]

> И намерен теперь года три этим фактом гордиться.

Ты статью вообще-то обещал по этому делу выпустить :)

← →
Дмитрий СС (2013-05-30 12:02) [23]

> Kerk © (30.05.13 10:30) [17]

Не через COM обертку для клиента?

← →
Kerk © (2013-05-30 12:16) [24]

А я все не знаю с какой стороны об этом писать... Это как "берешь лопату и копаешь несколько недель".

Потому что вся эта история про "сделай нужной битности обертку над другой DLL" - это в общем-то ерунда. Я буквально на коленке распарсил сишные заголовки для OCI.DLL, получил XML-ку с описанием функций (имена, параметры, типы) и смог генерить свою точно такую же DLL. В итоге добиться работы схемы 32bitDLL<=>IPC<=>64bitEXE<=>64bitDLL (где первые три пункта мои, а настоящая DLL в конце) достаточно просто.

В результате в моей сгенерированной DLL код всех функций был практически один и тот же: функция "упаковывала" свои параметры в специальную структуру данных, перекидывала ее с помощью MMF в 64битный процесс, запущенный в фоне, там структура распаковывалась, параметры передавались в соответствующую функцию настоящей DLL, а затем результаты выполнения тем же путем следовали обратно.

Это кажется, что запутано, если немножко подумать, то ничего страшного тут нет.

Трудности начинаются потом. Если функция имеет параметры типа Integer или даже string, то не очень сложно перекинуть все это между процессами и обратно. А что если функция принимает указатель на буфер, который содержит указатели на некие заранее созданные дескрипторы? Как это между процессами передать не поломав? К тому же указатели на дескрипторы (как и все указатели), которые использует приложение 32битные, а на самом-то деле они существуют в неведомом для нашего приложения в 64битном пространстве другого процесса. Что делать с функцией, возвращающей ссылку на дескриптор? А принимающей ссылку на дескриптор? Или, допустим, передается ссылка на callback-функцию. В другой процесс. Ага.

И надо понимать, что функций там что-то типа 300 штук. Не получится каждый случай вручную обработать, нужен кодогенератор.

Короче, если все это реально кому-то интересно, то я как-нибудь могу целую поэму написать. Но веселья тут мало. Все сводится к муторной и скучной возне с деталями. Дьявол, блин, в деталях.

← →
Пит (2013-05-30 14:04) [25]

Хм... Мне теперь интересно просто идеологически.

Вот допустим сама MS рекомендует всем ставить офис 32-ух битный.

И вот тут я такой модный современный решил сделать 64-битное приложение. Допустим, даже в дельфи решил сделать. Сделал.... и? Потерял возможность десятилетней давности встроить OLE-контейнер с Word"ом в свою форму?

← →
Пит (2013-05-30 14:05) [26]

> прикрутить 64битный клиент Oracle к 32битному приложению

а зачем?

32-ух битный клиент прекрасно встает на 64-битные системы...

← →
Kerk © (2013-05-30 14:17) [27]

> Пит (30.05.13 14:05) [26]
>
> > прикрутить 64битный клиент Oracle к 32битному приложению
>
> а зачем?

Потому что продукт коробочный и мы не можем диктовать юзеру какой именно клиент ему установить. Есть общие требования, спорить с которыми мы (коллеги и я) должностями не вышли. Придуманное, предложенное и реализованное мной решение выглядит наиболее выгодным. В долгосрочной перспективе это намного дешевле, чем сборка двух отдельных версий продукта (32 и 64бит).

← →
Дмитрий СС (2013-05-30 14:18) [28]

> И вот тут я такой модный современный решил сделать 64-битное
> приложение. Допустим, даже в дельфи решил сделать. Сделал.
> ... и? Потерял возможность десятилетней давности встроить
> OLE-контейнер с Word"ом в свою форму?

Все будет работать, COM за тебя сделает эту грязную работу.

>это намного дешевле, чем сборка двух отдельных версий продукта

Я понимаю, что все остальные идиоты, а ты молодец.
Не, серьезно вполне, насчет молодца, впрочем мое мнение тебе..

Но еще более идиоты ваши начальники.

← →
Пит (2013-05-30 14:36) [30]

> Потому что продукт коробочный и мы не можем диктовать юзеру
> какой именно клиент ему установить.

интересная штука. Но по той же логике - вы тогда вообще не имеете права навязывать клиенту устанавливать какие-то сторонние драйвера.
Тогда решение только включать драйвер оракла в свой продукт)

← →
Пит (2013-05-30 14:37) [31]

> Все будет работать, COM за тебя сделает эту грязную работу.

так... Еще одно мнение. Ведь только выше обсуждали, что 32-бита и 64-бита несовместимы. Читал?

> Jeer © (30.05.13 14:36) [29]

За молодца спасибо, конечно. Только я не понял, почему если я молодец, то остальные обязательно идиоты :)

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

> Пит (30.05.13 14:36) [30]
>
> > Потому что продукт коробочный и мы не можем диктовать юзеру
> > какой именно клиент ему установить.
>
> интересная штука. Но по той же логике - вы тогда вообще
> не имеете права навязывать клиенту устанавливать какие-то
> сторонние драйвера.

Это вот, к сожалению, вообще не тот вопрос, который есть смысл со мной обсуждать. Ну вот надо было так и все тут. Может маркетологи какие-нибудь в отчете нарисовали, что есть некоторый объем спроса именно на 64бита, может еще что-то. Сейчас это уже не важно.

> Поздравления принимаются :)

Поздравляю!

>Или тебе описанное мной решение не нравится

Да ну - это как раз все в порядке.

Большинство же выпускает разнобитные версии и не парится реверсинжинирингом и спариванием мухи и кита.

> Jeer © (30.05.13 16:22) [34]
>
> >Или тебе описанное мной решение не нравится
>
> Да ну - это как раз все в порядке.
>
> Большинство же выпускает разнобитные версии и не парится
> реверсинжинирингом и спариванием мухи и кита.

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

> Kerk © (30.05.13 16:30) [35]

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

> Eraser © (30.05.13 16:38) [36]
>
> > Kerk © (30.05.13 16:30) [35]
>
> хм, а что там за продукт такой, что такая сильная зависимость
> от битности? в принципе сейчас написание "кросс-битного"
> кода фактически не отличается от обычного.

Да нет особой зависимости. Но ты же понимаешь, что, например, нельзя тестировать только одну версию, а на вторую забить. То есть как минимум объем тестирования уже автоматически в два раза увеличивается. Программистам тоже работы прибавится, врядли много, но тем не менее.

Плюс к этому нельзя же сказать, что сам переход на "разнобитность" не потребует никакой работы. Типа "вот ты 64битный Оракл прикручивал, время тратил, а так бы перекомпилил приложение под 64бита и все пучком". Нет, перевод старого кода на "разнобитность" тоже бы потребовал определенного объема работы.

В рамках существующего бюджета принятое решение было оптимальным.

← →
Пит (2013-05-30 21:50) [38]

Дык коллеги!

Нифига не понял - если мы имеем 32-ух битный COM-сервер, можно ли его использовать в 64-битном приложении?

> Пит (30.05.13 21:50) [38]
> Дык коллеги!
>
> Нифига не понял - если мы имеем 32-ух битный COM-сервер,
> можно ли его использовать в 64-битном приложении?

Ты не определился - какой именно (тип реализации сервера).
Можно ли его использовать и как - описано выше.

← →
Алканавт расправил плечи (2013-05-30 22:17) [40]

> Пит (30.05.13 21:50) [38]
Резюмирую Rouse: Inproc-сервер (dll) — низя, Outproc-сервер (exe) — можно. Outproc может быть обёрткой над Inproc, мы так юзаем MS"овский OWC, коего в 64-битном варианте нет в природе.

Каким образом создается COM-сервер? Найти похожие ветки