Загрузка / взаимодействие с dll COM vb6 из 64-битного приложения

Question

Я работаю над приложением, в котором написано более нескольких dll, написанных на VB6. Код VB6 включает в себя COM dll и ocx control. Остальная часть кода находится на C ++ и C #. Передо мной была поставлена ​​задача сделать код приложения совместимым с 64-битными архитектурами. Для кода C / C ++ доступно множество справочных материалов, так что проблем нет. Но нелегко переписать весь этот код vb6 в .net или другой язык, чтобы сделать его совместимым с 64-битным. Я также не понимаю всю основную логику, поэтому просто предположим, что переписывание не подлежит обсуждению.

С другой стороны, мы все знаем, что dll VB6 не будет работать в 64-битной среде. Итак, каковы мои варианты.

1) преобразовать каждую dll в EXE-файл, который будет загружен в 32-битной версии, и он может взаимодействовать с остальными 64-битными приложениями через COM-интерфейсы. Предвидите ли вы какие-либо проблемы с этим подходом?

2) Я редактирую реестр и загружаю все библиотеки VB6 вне процесса, заставляю их загружаться в dllhost.

3) Создайте один 32-битный exe-файл, отошлите все эти VB6-библиотеки в этот exe-файл и загрузите этот exe-файл в 32-битное адресное пространство, и 64-битная часть моего приложения будет связываться с 32-битным exe.

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

Есть идеи? Если нет новых идей, чем из вышеперечисленных вы предпочтете и почему?

Answer 1

Я перехожу с SQL 2000 x86 на SQL 2008 x64.

Здесь мы сталкиваемся с подобной проблемой. Я решил использовать DCOM.

Как это будет работать?

Сервер 32-битный будет размещать сборку, а 64-битный компьютер будет вызывать с использованием DCOM.

Существует штраф за производительность. Кстати, усилия по сравнению переписать ... безусловно, стоит делать. :)

С уважением, Маркос Лима

Answer 2

Если у вас много существующего кода VB6, который используется для работы в процессе, я бы сначала спросил, действительно ли стоит перейти на 64-битную версию. 64-разрядная версия имеет много преимуществ для серверных приложений, но для настольных приложений 32-разрядных часто вполне достаточно. А поскольку ожидается, что WOW64 будет доступен по крайней мере десять лет, мало кто говорит о запуске 32-битных приложений в 64-битной Windows.

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

Тем не менее, я бы сказал, 2) или 3) будет естественным выбором. 2), конечно, проще в реализации, но 3) дает вам больше контроля над тем, сколько внешних серверов должно быть создано и как управляется их время жизни.