Словечко «AppCompat», появившееся в моем лексиконе за время работы над Wow64, обозначает множество вещей. Чаще всего – геморрой. Иногда – великий геморрой. Происходит оно от «application compatibility» – т.е. совместимость OS с приложениями, она же – «обратная совместимость».
Structure Exception Handler (SEH) overwrite – один из популярных способов передачи управления на вредоносный код, внедренный через ту или иную уязвимость (обычно – переполнение буфера). Иными словами, это один из способов подхватить заразу на свой компьютер через непропатченый браузер просто зайдя куда-нибудь с http://www.thehun.net почитать Пушкина на сон грядущий.
Вопрос из почты:
Ты не подскажешь, есть ли hardware acceleration through DirectX for Wow64 processes? В Windows Internals написано, что его нет, но другие источники говорят, что есть (и большинство игр продолжают собирать as 32-bit, и они работают в 64-bit Windows).
Вот несколько ссылок, которые выдает поиск на msdn.microsoft.com: Read more…
Наконец-то обновилась документация в MSDN. Теперь можно спокойно рассказать, что изменилось в Wow64 с выходом Windows 7.
Просто удивительно, насколько опасной может быть функция Wow64DisableWow64FsRedirection. Эта функция позволяет временно отключить перенаправление файловой системы в Wow64. Еще более удивительно, что лишь малая доля разработчиков соглашается менять свой код, даже после подробного объяснения, в чем, собственно, проблема.
На днях свалился в inbox вопрос:
The documentation for QueueUserApc states "an APC cannot be queued from a 64-bit process to a 32-bit process or vice versa."
However on Vista Ultimate x64, we can queue a user APC from a 32-bit process to a 64-bit process. In our test application the 64-bit recipient crashes, we haven’t explored why just yet, but the point is that the operation should not succeed and the 64-bit application’s APC queue should never have the APC inserted.
Is it an OS bug?
Документация к функции QueueUserApc утверждает, что асинхронный вызов процедуры (APC) не может быть запрошен из 64-х битного процесса для выполнения в 32-х битном и наоборот.
Однако на Vista Ultimate x64 мы можем выполнить асинхронный вызов пользовательского режима из 32-х битного процесса в 64-х битном процессе. В нашем тестовом приложении 64-х битный получатель падает и мы еще не выяснили почему, но дело в том, что операция (QueueUserApc) не должна завершаться успешно и асинхронный вызов не должен вставляться в очередь вызовов 64-х разрядного процесса.
Это баг ОС?
Вопрос примечателен тем, что это уже третье письмо на эту тему за последние два месяца, хотя функция QueueUserApc далеко не самая широко используемая функция Win32. Не иначе какой настойчивый клиент эту функцию мучает.
Вопрос:
32-х битный процесс запущен на 64-х битной системе. Почему для некоторых библиотек GetModuleFileName возвращает путь вида “%SystemRoot%\syswow64”, а для других – “%SystemRoot%\system32”, не смотря на то, что и первые, и вторые находятся в “%SystemRoot%\syswow64”?
Ответ:
Потому что загрузчик понятия не имеет о Wow64 и перенаправлении файловой системы в частности. Загрузчик просто сохраняет полное имя модуля во время загрузки и возвращает его копию в GetModuleFileName. Соответственно если библиотека была загружена как “%SystemRoot%\system32\foobar.dll”, то и GetModuleFileName вернёт эту строку.
Это же верно и для других Win32 функций.
Recent Comments