вызов чужого COM-32бита из 64-битного приложения

[Malaja]

Господа, проблема выглядит следующим образом:
когда-то было написано 32-битное приложение, вызывавшее в процессе выполнения 32-битый же COM (COM  чужой, единственное, что у нас есть - его GUID, с помощью которого можно вытащить CLSID, и интерфейс, в котором прописаны все параметры функций через marshal). Все работало, пока не возникла необходимость переставить приложение на 64 бита...
Вот тут-то я с коллегой и выиграли бесплатный билет на эту карусель Самое прискорбное - мы обы никогда под с# со всем этим не работали...
После того, что мы все переставили, выяснилось, что теперь невозможно связаться с COM -ом... Ага, конечно логично.
Все поиски по инету дают в основе своей заключение : "mission impossible". Но - в принципе можно попытаться  обойти ситуацию, использовав:
1)  компиляцию на платформе х86
2) wow64
или
3) создать 64-битную обертку для интерфейса, из которой уже вызывать COM , все это - в отдельном процессе, который должен через RPC связываться с нашим приложением

Вариант 1 - провалился с грохотом ;-(
Третий  вариант выглядит для меня очень заумно, поэтому я попыталась найти инфу об использовании wow64 в наших целях.
Но нашла только общие слова без описания примеров... Подозреваю, что в связи с незнанием предмета задавала неверный запрос.

Посему вопросы:
1) может кто-то в принципе сталкивался с проблемой вызова чужого 32- битного COM-а из 64-битного приложения и знает способ решения проблемы
2) если нет - может, кто-то сталкивался с wow64 и смог бы подсказать, с чем его едят и как им пользуются.

Сразу оговорюсь, что рыла инфу полпятницы, но поняла, что чем дальше в лес, тем меньше ясности. Посему решила запросить помощи.
Заранее благодарна за любую инфу!

[RXL]

Нельзя в рамках одного процесса запустить код разной разрядности.
Wow — это запуск 32-битных процессов в 64-битной ОС. По сути, две винды в одной, два набора библиотек, и т.п.
По моему сработает только вариант 3. Отдельный 32-битный DCOM процесс, включающий в себя сторонний COM. Stub должен быть 64-битный.

[Malaja]

Ром, так именно поэтому я и хотела попробовать WOW! Ты же говоришь: "Wow — это запуск 32-битных процессов в 64-битной ОС". Я именно из-за этого и хотела попробовать. Раз у меня загружены обе винды, значит, я могу использовать 32-битный процесс в моем приложении. Или я что-то не так не понимаю?

[Джон]

Хм... сразу скажу, я таким не занимался. Какой смысл портировать что-то на 64, чтобы потом из него работать с 32? Ну да ладно.
Мишн не совсем импосбл, но попотеть придётся (а оно тебе надо?).

Первый же поиск дал такое, или ты уже там смотрела?

зы Да, ещё раз для уточнения. WOW это для запуска 32-битныйх приложений на 64-битной ОСи!

зы зы В первом линке есть интересная ссылка
Чувак сделал!

Ну и чтобы ты примерно представляла, что тебя ожидает:

The current implementation of Windows does not provide loading of 32 bit dlls into a 64 bit process.
Even this is not entirely correct because the WOW64 basic dlls ( e.g. SYSWOW64\ntdll.dll ) is a 32 bit dll which is loaded in a 64 bit
Process ( which is marked then as a 32 bit process )

I have developed a special 64 bit dll which provides a few functions ( LoadModule32, GetProceAddress32 ).
This allows to load 32 bit dlls into a 64 bit process without using the WOW64 layer so it works also on Systems where
the WOW64 layer isn't installed.
I call my implementation a 64 bit - 32 bit Gate. I managed to use quite complex 32 bit DLLs in a 64 bit process like VirtualMachine's for Smalltalk
which uses thousands of Window calls ( LSWGVM) .

The 32 Bit / 64 bit gate can be thought as a complex marshaller which handles all special cases like Callbacks, 32-64 Structure
bidirectional marshalling & others.

It is developed under Windows 10 & handles UCRT & the new core dlls ( api-ms-*.dll )

The gate provides also accesss from 32 Bit to 64-Bit by loading a special dll into the 32 bit dll.

the gate is far fro to be ready - but it already wraps nearly 100 system dlls.

[RXL]

WOW позволяет вообще запускать приложения, рассчитанные на 32-битную винду, в 64-битной винде. Этот никак не относится к стыковке 32 и 64-битных приложений. Т.е. ты не можешь включать в свои 64-битные процессы 32-битные библиотеки, к которым относится и COM in-process. Женя привел ссылки с решениями, идентичными твоему варианту 3: пишется 32-битное приложение, включающее себя эту 32-битную COM библиотеку; это приложение как-либо общается с твоим 64-битным приложением, выполняя роль прокси.

The current implementation of Windows does not provide loading of 32 bit dlls into a 64 bit process.

Никакая версия никакой ОС не позволит это сделать. Процессор x86/amd64 не позволяет смешивать в одном контексте 32 и 64-битный код.

Мне больше нравится эта статья: https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/

[Джон]

Ага, мне тоже. Это собственно самое интересное в превом линке. Плюс линки на матчасть в её конце.

зы Я вот думаю, неужели этот СОМ настолько сложней? Не проще ли написать новый на 64 бита?

[RXL]

Если он чужой...

[Malaja]

Джон, нас поставили в правильную позу, галантно предложили вазелинчику и послали на амбразуру..
Старый проект компилировался на ДотНет 4.0 (был создан на визуал студии 10.0). Проект содержит микс из c# и managed c++.
5 Лет назад всех все устраивало. Сейчас нам выставили требование, переставить проект на ДотНет > 4.6, т.к. в старом дотнете нашли security leaks (прошу прощения, я не знаю правильного названия по-русски).
Переставить - не проблема, но тут выяснилось, что на build - серверах можно построить только 64-битный вариант... 32-битную версию для нас никто ставить на будет, т.к. основной продукт выпускается только в 64-битном варианте... Все! Они нас загнали в угол - нам пришлось все перевести в 64 бита. А с com-ом мы ничего не можем сделать - это продукт клиента...

Так мы и работаем на 64-битной ОСи (согласно данных разведки в лице продукт-менеджера у клиента стоит 10-я винда). ПОэтому я и зацепилась за этот WOW.

первый линк видела - там они собственно тоже упирают в wow. А по поводу х86 - я попробовала скомпилировать тестовое  приложение таким образом и загрузить объект, но это ничего не дало (в нескольких форумах говорилось о том, что этого должно быть достаточно).

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

[RXL]

Стоит начать с разбора архитектуры этого COM. Что он делает? Он самодостаточный или работает с DCOM сервером?

[Malaja]

Ром, поняла - спасибо! Я думала, что раз у меня грузятся обе винды, то снимается ограничение... Не повезло однако...
как реализован этот com - понятия не имею... у нас нет ничего...

Жень, у меня нет к нему никакого доступа! Есть TCI - протокол, каждая фирма реализует его по-своему.
Стандарт - 32 бита. Поэтому мы ничего сделать не можем...
В понедельник попытаемся выяснить, есть ли 64-битный вариант этого протокола и возможно ли просить клиента в этом случае сделать свою реализацию в виде 64-битного приложения. Если нет - нам надо будет искать пути решениай проблемы.

упс, а ссылку я проглядела... спасибочки!
но то, что я читаю, меня совсем не радует... я достаточно плохо понимаю, как это все сделать по его схеме...

[zubr]

Кстати, осел в 64-битной винде так и работает - линк на 64-битный процесс, который запускает 32-битный с его комом.

[HandKot]

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

[Malaja]

Эх, к сожалению - не наш случай ;-( Это чужой обьект, мы о нем ничего не знаем... Его GUID мы получаем в момент выполнения программы...

[Джон]

Ир, насколько я понял, задача решаемая. Вопрос только "За чей счёт этот банкет? Кто оплачивать будет?" (с)

Чувак ещё не закончил, а уже заврапил почти сотню системных ДЛЛ. Те я хочу сказать, что вашему заказчику (ну или для кого вы там это стряпаете) должно быть понятно, во что это обойдётся.

С другой стороны, логика работы СОМ тебе известна? Известен интерфейс? Не дешевле ли будет сделать нечто подобное? Как вариант разумеется.

[Malaja]

Джон,
тут ситуация вообще патовая. этот тул бесплатен для клиента! Т.е. весь банкет оплачивает наша контора! Дело в том, что на старте это называлось - почти бесплатная переработка существующего кода. Ага, сейчас! Сначала надо было многое в коде подработать и отполировать, потом долетело требование по поводу дотнет >=4.6, что потянуло за собой изменение платформы. Ну а последствие последнего шага имеем сейчас - проблемы с com - ом...

Все, что мы знаем - интерфейс (он находится в нашем проекте) и в момент выполнения (т.е. позднее связывание - кажется так) получаем programm-id, на основании которого ищем в регистре class id. Все! Больше никакой инфы...

[RXL]

А они не могут вам дать дистрибутив этого компонента?

[Malaja]

Ром, ничего не дадут... Я тестирую с аналогичным вариантом, который написала наша фирма.
Чисто теоретически, если оно заработает с нашим приложением, то и с чужим скорее всего будет работать, ибо интерфейс у них одинаковый.

[Джон]

Джон,
тут ситуация вообще патовая. этот тул бесплатен для клиента!

Ир, ну дык, ёлы-палы! Ты в какой стране живёшь? В смысле социально-политического строя. При коммунизме? Что это у вас там за клиент такой? За БЕСПЛАТНО ещё и требует чегойн-то. К примеру у нас, в NRW, ему бы пришлось довольствоваться либо без СОМ-а, либо 32-битной версией. ФСЁ!

Вы же "стартовое" задание выполнили? А если через пару лет появятся 128, 256 512 и тд битные? Вы под них тоже БЕСПЛАТНО всё делать будете?

Чёт вы там в вашем свободном государстве делаете неправильно.

зы И я не понял, почему .NET > 4.6 и обязательно 64-бита?

[Malaja]

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

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

Лет 5 назад тул был написан практикантом, но его никто никогда не использовал.

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

Требование дотнет > 4.6 выставил спец по защите софта (иначе потом наш тул не пройдет проверку на надежность); 64 бита - требование, выставленное ситуацией, т.к. весь наш портал (основной софт) выпускается теперь только как 64-битная версия. На основании этого все сервера, на которых проводится компиляция, содержат инсталляцию только 64-битного framework-а, а для нашего маленького тула никто не будет создавать экстра сервер (это головняк еще тот).

идея начальства - тул должен работать, но поскольку это очень неудобно, клиент скорее всего согласится купить наш портал.

Изначально задание звучало изумительно - все уже есть, надо только чуть-чуть подправить и все! То есть все будет почти бесплатно для нас. Ага, сейчас! проблема на проблеме...

Добавлено через 3 минуты и 32 секунды:
Да - еще одно: к статье https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/  у меня вроде бы появился пример
Я написала одному из тех, кто участвовал в обсуждении, т.к. он сказал, что этоит код у него есть и он с радостью поделится им со страждущими.
Выложить?

23:52: Вот пример к статье:

[RXL]

Конечно клади! Проблема 64/32 - это надолго.

[Джон]

Ир, это всё понятно. У нас примерно аналогичная ситуация с поддержкой Win XP -
на производстве ещё куча цехов именно с ними, и работать надо сейчас.

Новая (MFC 14.0 опять же, по требованию безопасности) Студия  хоть и компилит с поддержой ХРюши, но реально надо дополнительно поставлять 29 dll, чтобы потом такой компилят на ней работал.

Но, при некоторых задачах (см. например мою тему про определение версии драйвера) всё обоюдно (мы и кунды) сводится к тезису: "не фурычит на ХР-Висте, ну хрен бы с ними". Ибо они понимают, что денюшки в такие навороты вкладывать просто неразумно.

[Malaja]

Ром, сделаю из дому.

В процессе поиска я наткнулась на интересную возможность решения проблемы - якобы достаточно внести несколько дополнительных строк в registry. И ву а ля - должно заработать.

Пытаюсь как раз разобраться.
https://techtalk.gfi.com/32bit-object-64bit-environment/
https://www.codeproject.com/Tips/267554/Using-bit-COM-Object-from-bit-Application

Джон,
тут вроде бы клиенту пофиг - он у другого производителя приборы купит...

[RXL]

Надо пробовать. Во всяком случае в роли typelib может прокатить.

[Malaja]

приведенное решение (с registry) работает!!! как минимум я получаю объект!
Будут ли работать вызовы - это уже завтра или послезавтра (нужен тестовый комп, на котором стоит релиз - версия без всяких дополнительных инсталляций). Когда все проверю - напишу!

Огромное спасибо за помощь!

[RXL]

Супер!

[Malaja]

Вторая серия марлезонского балета...

До теста не дошла - сломалась на реестре...

при попытке внести новый ключ в HKEY_CLASSES_ROOT\Wow6432Node\CLSID CreateSubKey() возвращает ошибку доступа

Задача - программно внести пару изменений в реестр:
1) сначала внести новый ключ
2) потом в этот ключ внести атрибут

ПОнятно одно - мне надо как-то разрешить своему приложению доступ:
- либо стартовать с правами админа (можно сделать, используя манифест, но в этом случае будет появляться диалог типа "а Вы точно уверены, что разрешаете?", что недопустимо)
- либо, если я правильно понимаю, с помощью параметра функции CreateSubKey() - System.Security.AccessControl.RegistrySecurity. Но тут пока я не нашла решения..

Буду благодарна за любую помощь.

P.S. Может, это надо делать новой темой?

[RXL]

Попробуй переименуй экзешник в setup.exe

[Malaja]

Издеваешься?
а если серьезно - не могу, есть сверху установленное имя этого ехе...
Если бы это можно было в setup приложения затолкать, было бы изюмительно! Но - не судьба...

нашла вот что, пытаюсь воплотить:
http://stackoverflow.com/questions/6455691/registrysecurity-access-is-denied-c-sharp

[zubr]

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

[Malaja]

zubr,

даже если менять в RegistrySecurity?

Про инжект не слышала... о каких классах идет речь? Насколько это сложно?