Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2009.06.28;
Скачать: [xml.tar.bz2];

Вниз

Даже и не думайте пользоваться функцией Wow64DisableWow64FsRedire   Найти похожие ветки 

 
Кто б сомневался ©   (2009-04-24 18:51) [0]

Раскритикуйте пожалуйста статью.:

Даже и не думайте пользоваться функцией Wow64DisableWow64FsRedirection!

Просто удивительно, насколько опасной может быть функция Wow64DisableWow64FsRedirection. Эта функция позволяет временно отключить перенаправление файловой системы в Wow64. Еще более удивительно, что лишь малая доля разработчиков соглашается менять свой код, даже после подробного объяснения, в чем, собственно, проблема.

В чем состоит опасность? Во-первых, при отключенном перенаправлении файловой системы не работает загрузка 32-х битных системных библиотек. Они, как правило, загружаются из system32 и только перенаправление ввода/вывода спасает ситуацию. Во-вторых, и это самое главное, разработчик очень редко полностью контролирует весь ввод-вывод на участке между Wow64DisableWow64FsRedirection и Wow64RevertWow64FsRedirection.

«Как это возможно?» - спросите вы, «ведь все три строчки кода – вот они, как на ладони». Очень просто. Вот неполный список случаев, когда может происходить неявная загрузка кода:
Неявный вызов LoadLibrary. Многие функции Win32 вызывают LoadLibrary. Один из примеров – Multimedia API. То же самое делают и другие библиотеки, особенно те, что поддерживают плагины.

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

Так называемые «DLL import forwarders» позволяют сказать загрузчику, что функция «Foo», экспортируемая из «Foo.dll», на самом деле реализована в «Bar.dll». В результате при попытке получить адрес функции «Foo», загрузчик попытается загрузить «Bar.dll».
Взаимодействие с COM объектами очень часто приводит к загрузке дополнительных библиотек. К примеру, это быть вызов QueryInterface или любой другой вызов возвращающий указатель на COM интерфейс.
Внедрение кода в другой процесс – обычное дело в Windows. Внедренный код может вызвать LoadLibrary в самый неподходящий момент. В этом случае виноват не ваш код, но с точки зрения пользователя упадет именно ваше приложение.
и т.д. и т.п.

Проблема еще и в том, что код, использующий Wow64DisableWow64FsRedirection, в общем-то, работает в большинстве случаев. Так что разработчик не видит проблемы до тех пор, пока код не будет запущен в незнакомом окружении на машине заказчика. Или пока не выйдет новая версия ОС, используемой библиотеки или клавиатурного шпиона, которая вдруг начала загружать код в том месте, где раньше ничего такого не происходило.

PS. А когда можно использовать Wow64DisableWow64FsRedirection? Единственный поддерживаемый сценарий – вызов CreateFile, обернутый в Wow64DisableWow64FsRedirection и Wow64RevertWow64FsRedirection.


 
Кто б сомневался ©   (2009-04-24 18:57) [1]

Автор слишком категорично заявляет об этом.
вот что он предлагает в замен:

1. Иногда за таким “ТРЕБУЕТСЯ” скрывается баг в дизайне. Если это исправить, то “ТРЕБУЕТСЯ” не возникает.
2. Используйте 64-х битный код для доступа к system32.
3. Используйте sysnative


 
guav ©   (2009-04-24 21:07) [2]

Бяка этот FS redirector. И registry rediretor, который не через глобальное состояние, тоже бяка. И вообще собирайте тру 64битные бинарники.


 
Кто б сомневался ©   (2009-04-24 21:24) [3]

Между прочим, я не пойму зачем MS так намудрили?

system32 - это папка в которой лежат x64 файлы.
почему нельзя было сделать System64?


 
Кто б сомневался ©   (2009-04-24 21:25) [4]


> И вообще собирайте тру 64битные бинарники.


Ага, которые кстати не будут работать на x32 - на которых сидит большинство юзеров.


 
Городской Шаман   (2009-04-24 21:26) [5]

Удалено модератором


 
Городской Шаман   (2009-04-24 21:30) [6]


> Кто б сомневался ©   (24.04.09 21:25) [4]
>
> > И вообще собирайте тру 64битные бинарники.
>
> Ага, которые кстати не будут работать на x32 - на которых
> сидит большинство юзеров.


И тебя вылечат (c) шутка :)

Дизайн для поддержки 32 и 64 бит довольно прост. Пишется 32-битный стартер который который по Wow64 проверяет поддерживает ли система 64 бита и запускает нужный бинарник. Проблем нет. Главное иконки одинаковые подпихнуть для стартера и бинарников и 99,9% процентов юзеров не заметят разницы.


 
Городской Шаман   (2009-04-24 21:31) [7]


> Кто б сомневался ©   (24.04.09 18:51)  


Если использовать


Wow64DisableWow64FsRedirection
try
...код
finally
Wow64EnableWow64FsRedirection
end;


То все нормально.

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

Тоесть функция не рекомендована для использования новичками, но позволяет обойти в некоторых случаях 32-битные костыли Delphi.


 
Городской Шаман   (2009-04-24 21:36) [8]

Да и еще.

Я требую нормально поддержки компилятором Delphi 64-бита!!! А то позорище.


 
Кто б сомневался ©   (2009-04-24 21:57) [9]


> Я требую нормально поддержки компилятором Delphi 64-бита!
> !! А то позорище.


Дык компилятор Turbo Pascal поддерживает x64 . у нас в конторе требовалось использовать x64 - мы юзали для этой проги Turbo Pascal (для диспетчера задач).


 
Кто б сомневался ©   (2009-04-24 22:00) [10]

Удалено модератором
Примечание: Не в пивной


 
Кто б сомневался ©   (2009-04-24 22:17) [11]

Не турбо паскаль, а FPC конечно.


 
guav ©   (2009-04-24 23:01) [12]


> Между прочим, я не пойму зачем MS так намудрили?

Видимо, множество 32битных приложений, в которых захардкодено system32, портили жизнь себе и/или системе, например, "обновляя" файлы до 32битных версий. Может майкрософт не хотели чтобы многие из таких приложений перестали работать.
В любом случае, они решив проблемы прошлого, обеспечили нас и себя граблями на будущее.


 
Кто б сомневался ©   (2009-04-25 00:15) [13]


> Видимо, множество 32битных приложений, в которых захардкодено
> system32, портили жизнь себе и/или системе, например, "обновляя"
> файлы до 32битных версий.


Нет ну dll hell уже решен. Но даже если поменялись бы файлы в system32 - файлы операционки лежали  бы  в system64, так ведь?


 
guav ©   (2009-04-25 00:33) [14]

Да. Более того, в 9х не было много файлов в system32, все они были в system или в windows. Не понятно.



Страницы: 1 вся ветка

Форум: "Прочее";
Текущий архив: 2009.06.28;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.49 MB
Время: 0.005 c
15-1240061523
@!!ex_
2009-04-18 17:32
2009.06.28
У меня глюкнул DMClient.


3-1222849323
Александр999
2008-10-01 12:22
2009.06.28
Проверка на существование БД перед запуском приложения


15-1240846100
Маэстро
2009-04-27 19:28
2009.06.28
F.A.Q. по описанию программы


2-1242196813
Альф
2009-05-13 10:40
2009.06.28
Когда освободиться TStrings ?


2-1241544934
DmitriyR
2009-05-05 21:35
2009.06.28
Перевести String в LongWord





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский