Почему Wow64 использует перенаправление реестра и файловой системы?

Понимаешь, до сих пор мне никто не может внятно сказать, почему нельзя было 64х приложения пихать в новый ключ Регистра, вместо перенаправления 32х на новое “место жительства”. Будь ласка, если это твоя специализация, обоснуй!

Итак, почему же Wow64 использует перенаправление реестра и файловой системы вместо того, чтобы просто закрепить старые ключи реестра и “%windir%\system32” за 32-х разрядными приложениями и позволить 64-х битным приложениям определить новые ключи и использовать, скажем, “%windir%\system64” для 64-х битных системных библиотек? Это было бы довольно логично, особенно если учесть, что нечто подобное уже было проделано при переходе с Windows 3.x на Windows 95/NT.

Сначала немного истории. Первый Itanium был выпущен в 2001 году. Тогда же вышла первая версия Windows XP 64-bit Edition for Itanium systems. Первый 64-х битные процессоры от AMD увидели свет на два года позже – в 2003 году. Еще через два года – в 2005 была выпущена Windows XP Professional x64 Edition. Т.е. Itanium был целевой 64-х битной платформой задолго до того, как появились процессоры AMD.

В отличие от x64, на Itanium разница между 32-х и 64-х битным кодом огромна. Выполнение x86 инструкций эмулируется либо самим чипом (так называемый x86 hardware support), либо программным эмулятором – IA-32 EL. В обоих случаях модель выполнения 32-х разрядных приложений очень близка к работе виртуальной машины, что автоматически означает невысокую производительность 32-х битных приложений. В общем Intel явно даёт понять, что 32-х битные приложения поддерживаются только для облегчения процесса перехода на 64-х разрядный софт. При этом процесс перехода не обещал быть долгим, так как в отличие от клиентского десктопа, на сервере крутится одно - два основных приложения, а не сотни программ непонятного происхождения.

Отложим ненадолго Itanium и рассмотрим второй фактор – сложность переноса приложений на 64-х битную платформу. Microsoft постаралась сделать этот переход как можно менее болезненным. По большому счету достаточно было перекомпилировать существующее 32-х разрядное приложение 64-х битным компилятором и всё. На практике это не совсем так просто, конечно. Главным образом потому, что программисты никогда не следуют всем рекомендациям на 100%. Обязательно кто-нибудь “срежет угол”. Впоследствии такая оптимизация выходит боком.

Теперь можно ответить на исходный вопрос. Виртуализация реестра и файловой системы нужна потому, что при перекомпиляции существующего приложения имена ключей реестра и название каталогов на диске, которые использует данное приложение, останутся неизменными. Ведь это просто текстовые константы в коде программы. Правда в случае каталогов на диске всё не так плохо, имена большинства системных каталогов можно (и нужно) получить с помощью функций GetSystemDirectory, GetWindowsDirectory, SHGetFolderPath и т.п. Хотя в случае “System32” ситуация была особенно плоха, так как жёстко заданное “System32” встречалась повсеместно.

В общем, получалось, что простой перекомпиляцией тут не обойтись, а поиск и корректная замена множества строковых констант во всех портируемых приложениях обещала если не влететь в копеечку, то сильно затормозить процесс перехода на новую платформу. Основная сложность тут не поменять код, а убедить производителей программного обеспечения поменять код. Решение этой проблемы малой кровью (т.е. с использованием перенаправления в Wow64) казалось очень привлекательным.

С появлением AMD, а может быть из-за не очень хороших продаж Itanium (по сравнению с прогнозами), переход на платформу, свободную от 32-х разрядных приложений, затянулся. Большинство приложений по прежнему 32-х битные и конца и края этому не видно. :-)

В результате получилось то, что мы видим сейчас. Windows XP x64 и Vista x64 унаследовали архитектуру Wow64 от Windows XP 64-bit Edition for Itanium systems, переход на чистые 64-е бита затянулся, а люди начинают замечать архитектурные несуразности (не смотря на которые, надо сказать, система работает довольно неплохо. :-) ).