| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Системное программирование и WinAPI > проблема с переносом на 64 бита |
| Автор: ksili 14.9.2009, 09:33 | ||
Есть 32-разрядное Windows-приложение, которое внедряет dll-ку в другие процессы. При использовании в 64-битной виндах обнаружилась такая проблема. Dll внедряется только в 32-разрядные приложения, т.е. те, которые, как и оно, выполняется внутри WOW64. Вот в этой http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx, обнаружил информацию, что оказывается 32-битные могут загружать только 32-битные библиотеки, а 64-битные только 64-битные.
Получается, что в 64-битной Винде надо иметь 2 запущенных процесса, чтобы иметь возможность внедряться во все процессы? Но интерфейс-то один, значит надо запускать какой-то суррогатный 64-битный процесс, который будет внедрять 64-битную библиотеку? Или есть другие варианты решения проблемы? |
| Автор: GremlinProg 14.9.2009, 10:01 |
| чтобы такое сделать, пришлось бы по крайней мере сменить формат PE относительно секции импорта, + усложнять логику переходов из/в 64- 32-битное адресное пространство, а это огромная нагрузка на все существующие наработки: там, где раньше использовались макросы, должны теперь будут работать функции и т.п., тут нужен уже какой-нибудь анализатор посложнее, чтобы эмуляция была динамической вобщем, эмуляцию 32-битных процессов в таком ключе проще уж тогда вообще сменить на конвертацию 32 в 64, но за это врят ли кто возьмется, хотя кто знает |
| Автор: ksili 14.9.2009, 10:46 |
| GremlinProg, что-то вы пространно выражаетесь, я почти ничего не понял. Отсюда я сделал вывод, что я непонятно задал вопрос. Сейчас попробую по-другому. 32-битное приложение (своё, исходники есть) внедряет dll в другие 32-битные процессы. Потом общается с ней посредством сообщений. Мне надо чтобы она также общалась и с 64-битными приложениями. Я вижу такой вариант решения (но прежде чем реализовать, хотел бы услышать критику, а-то вдруг он изначально нерабочий). 1) Создается 64-версия той самой dll (это уже сделано) 2) Исходное приложение (32-битный процесс) внедряет 32-битную dll. 3) Исходное приложение запускает невизуальный 64-битный процесс, который внедряет 64-битную dll. Я предполагаю такие грабли: чтобы общаться сообщениями, 64-битная dll должна знать HWND исходного приложения. Его я ей как-нибудь передам. Вот только я не уверен, что HWND, взятый внутри WOW64 будет корректным вне его. Другими словами, я не уверен, сообщения, посланные извне WOW64, будут проходить внутрь WOW64. Может быть есть проблемы и при посылке сообщений в другом направлении, от 32-битного приложения к 64-битному? |
| Автор: GremlinProg 14.9.2009, 11:30 |
| почему пространно, вопрос касался "суррогатного 64-битного процесса, который бы внедрял 64-битную длл во все, включая 32-битные процессы", вот я и объясняю, почему это нереально, по крайней мере сейчас а теперь уже выплыли сообщения :) HWND должен быть корректным, иначе какой был смысл поддерживать эмуляцию 32 на 64, другое дело - обмен данными между разноразрядными процессами, сообщения скорее всего тут проходят, как обычно, но, возможно, эффективнее будет взаимодействие на уровне файлов, filemapping'а и объектов синхронизации, т.е. максимально отвязаться от взаимодействия адресаций |
| Автор: jonie 14.9.2009, 11:45 |
| тут можно подчерпнуть много инфы по wow32 http://not-a-kernel-guy.com/ |