Какви са лесните начини за използване на 32-битов in-proc COM сървър от 64-битови приложения?

Имам 32-битов собствен C++ ATL in-proc COM сървър, който зависи от огромен набор от наследени 32-битови библиотеки. Трябва да го използвам от 64-битово приложение с възможно най-малките промени.

Единият вариант е да го поставите в COM+ приложение. Какви са другите лесни опции?


person sharptooth    schedule 09.11.2009    source източник


Отговори (1)


Създайте 32-битово помощно приложение, което зарежда inproc server dll, но действа като локален сървър.

Компилирайте кода на прокси сървъра за 64 бита.

След това, когато 64-битово приложение се опита да зареди вашия ActiveX, вместо да използва 32-битов inproc (който не може да зареди), то ще зареди 32-битовия локален сървър - отделен процес - което е законно.

Проксито, което е автоматично генериран код от вашия IDL, трябва да се изгради за 64 бита съвсем добре.

person Chris Becke    schedule 09.11.2009
comment
Това звучи като много работа. Ще трябва да създам отделен .exe, да разбера как да го регистрирам и проксито/пъна в системния регистър. - person sharptooth; 09.11.2009
comment
Все пак това са стандартни неща. Алтернативата е рефакторинг на вашия COM dll за изграждане - и работа - в 64 бита. Вие просто не можете да заредите 32-битов dll в 64-битов процес, така че измислянето как да го хоствате в 32-битов процес наистина е единственият начин да избегнете повторното изграждане на контролата като 64-битова. - person Chris Becke; 09.11.2009
comment
Да, разбирам това. Само решението, което предлагате, звучи като много работа в сравнение с простото въвеждане в COM+ - и това са само няколко кликвания с мишката. - person sharptooth; 09.11.2009
comment
ако няма нужда от 64 бита, лесният начин е този, който вече сте отхвърлили. Компилирайте новото приложение като 32-битово, докато не конвертирате 32-битовия код в 64-битов. . . Винаги е трудно да се правят тези преобразувания... Помогнах на 16-битово (преди ANSI) c към 32-битово c/c++ преобразуване преди около десетилетие... това беше дълъг проект. - person Jason D; 05.12.2009