Алексей Пахунов

Всему свое время: время разбрасывать грабли и время наступать на них…

Первое, к чему привыкаешь, работая на 64-битной версии Windows это то, что 32-битные и 64-битные приложения разнесены по разным каталогам: первые используют «Program Files (x86)» и «%windir%\SysWOW64», тогда как вторые – «Program Files» и «%windir%\System32». Более того, все (за небольшим исключением) обращения из 32-битных приложений к «%windir%\System32» перенаправляются в «%windir%\SysWOW64», защищая тем самым систему от засорения 32-битными компонентами.

Логично было бы ожидать, что точно также все обращения из 32-битных приложений к «Program Files» перенаправляются в «Program Files (x86)», однако это не так. На самом деле ничего не мешает 32-битным приложениям использовать каталог «Program Files». Иными словами, приложения должны сами заботиться о корректной работе с путями. И, как выясняется, это поле густо усыпано граблями.Помимо элементарных вещей вроде hard-coded путей попадаются и сложные случаи. Например Windows shell использует одинаковый идентификатор CSIDL_PROGRAM_FILES как для «Program Files», так и для «Program Files (x86)». Это может стать проблемой если путь сначала приводится к «каноническому» виду, а затем используется 32-битными и 64-битными компонентами одновременно. Вы скажете что так никто не делает? Гм. Я тоже так думал.

Еще более запутанный вариант той же проблемы – неверные предположения о том, как может измениться название каталога «Program Files» в будущем. Например одна программа упорно отказывается устанавливаться в «Program Files (x86)» только потому, что считает скобки запрещенными символами в имени каталога. Попытки же установить это приложение в «Program Files» оканчиваются плачевно, потому как один из компонентов не говоря ни слова заменяет «Program Files» на «Program Files (x86)», считая, что 32-битным приложениям нечего делать в каталоге для взрослых 64-битных приложений.

Какой из этого всего вывод? Я не знаю. Видимо – набившее оскомину «не делайте неверных предположений».