Stan :
повторюсь, то что предлагаете вы, создаcт еще больше ошибок и проблем, особенно у тех, кто пользуется Delphi.

А никто и не говорил, что будет легко. Исправление ошибок дизайна – это практически всегда дорого.

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

Во-вторых, альтернативный вариант реальности, в котором Wow64 никогда бы не виртуализировала system32 – это тоже ошибка в дизайне с точки зрения тех, кто был бы вынужден исправлять множество программ.

В-третьих, нежелание и невозможноть разработчиков перейти на x64 – это тоже баг в дизайне, который они закладывают в свои приложения. Он может добавить проблем, а может и пронесет. Я могу только порекомендовать не закладывать мину в дизайн.

да и не будет ни кто это делать, о чем вы и говорите в статьте (а чему вы удивляетесь?).

С каждым разом я удивляюсь все меньше и меньше. Такого насмотрелся…

(в большинстве случаев пускается допольнительный поток для обработки данных).

Вашими бы устами, да мед пить. Разное бывает. Кроме того, для обработки данных код тоже нужен.

К чему я это все говорю, – к тому что это не так критично, как вы говорите.

Я вполне подробно расписал когда именно случаются неприятности. Вы полагаете, что такие ситуации возникают крайне редко? Ну так разработчики, у которых таки возникли проблемы тоже так считали. Более того, в некоторых случаях все вообще печально, так как код, запрещающий перенаправление, они не контролируют. Приходится изворачиваться.

Это второй – Используйте 64-х битный код для доступа к system32.
Проще обойти и сделать безопасную работу, чем писать и поддерживать второй экземпляр программы.
А ведь программа в моем случае поддерживает все Win от 98 в одном экзепляре.
поэтому это не так категорически критично для большинства людей, как вы заявляете.
вариант с sysnative отходит по понятной причине.

>>Ну вот это и есть пример бага в дизайне. Такие вещи нужно делать из 64-х битного кода, а не из виртуальной песочницы Wow64. Вы же не будете пытаться показать список драйверов хоста, если ваша программа крутится в гостевой виртуальной машине под VM Ware?

Коммерчески это не выгодно поддерживать 2 версии.
Пусть если бы там действительно были множественные изменения, а из за подобной мелочи в одну строку, никто не будет делать подобное.
+ Здесь нужно отходить от Delphi компилятора, и переходить на FPC. Что создаст массу трудностей и ошибок.
Тот кто понимает к чему это может привести, просто сделает так, что бы исключить такую возможность – это правильный и логичный путь, а не компиляция в x64 – тем более в моем случае.

>>Я прекрасно понимаю что Вам так проще. Однако >>“проще” не значит “надёжно и корректно”.

повторюсь, то что предлагаете вы, создаcт еще больше ошибок и проблем, особенно у тех, кто пользуется Delphi. да и не будет ни кто это делать, о чем вы и говорите в статьте (а чему вы удивляетесь?). Не выгодно это, и обойти это можно проще простого, хотя бы потоком (в большинстве случаев пускается допольнительный поток для обработки данных).

>>Ну да, конечно. Он еще, поди, и ошибок в коде никогда не делает.

все зависит от опыта. Ошибки конечно будут, но не критичные.

Stan :
Мне нужно показать список драйверов, показать их размер, версию, дескрипшн, паблишера итп.
Как мне сделать это по другому? Никак.

Ну вот это и есть пример бага в дизайне. Такие вещи нужно делать из 64-х битного кода, а не из виртуальной песочницы Wow64. Вы же не будете пытаться показать список драйверов хоста, если ваша программа крутится в гостевой виртуальной машине под VM Ware?

пишу на Delphi, мне проще написать одну строчку, чем делать те танцы с бубном, которые отнимут массу времени (ведь нужно писать еще и x32 версию а для x64 менять компилятор на Turbo Pascal), и создадут еще больше ошибок, которые сразу трудно заметить.

Я прекрасно понимаю что Вам так проще. Однако “проще” не значит “надёжно и корректно”.

Для C# придется писать две версии и их же поддерживать.

Для C# как раз нужна будет одна версия cобранная с /anycpu. А вот для C/C++ – две. Или три если считать Itanium.

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

Ну да, конечно. Он еще, поди, и ошибок в коде никогда не делает.

Не знаю среди каких людей вы вращаетесь, но квалифицированный программист, всегда читает документацию, в которой все это расписано, и корректно представляет ближайшие события, которые могут возникнуть.
Иначе, – он начинающий.
Если эта статья для начинающих, тогда можно понять ее категоричность, мол “не играй со спичками, ты еще ребенок”. Но правда тогда не понятна категоричность, где высказывается что ее нельзя вообще использовать, кроме одного случая.

Глупость. прежде чем делать подобные заявления, подумайте.
простая ситуация:
Мне нужно показать список драйверов, показать их размер, версию, дескрипшн, паблишера итп.
Как мне сделать это по другому? Никак.

>> Используйте 64-х битный код для доступа к system32.
>> Используйте sysnative
пишу на Delphi, мне проще написать одну строчку, чем делать те танцы с бубном, которые отнимут массу времени (ведь нужно писать еще и x32 версию а для x64 менять компилятор на Turbo Pascal), и создадут еще больше ошибок, которые сразу трудно заметить.
Для C# придется писать две версии и их же поддерживать.
Так что глупые советы, как и статья.

Stan :
Во первых, возникает вопрос – а чем же тогда пользоваться? По другому wow никак не обойти, а это иногда ТРЕБУЕТСЯ.

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

Во вторых Wow64DisableWow64FsRedirection работает только для потока, который ее вызвал.
что мешает вызвать это в другом потоке?

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

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

А вот ко мне последние три года регулярно приходят люди с печальной миной на лице, спрашивая что случилось и как им теперь быть. Как правило, докопаться до того, что причина сбоя – некорректное использование Wow64DisableWow64FsRedirection, у них занимает много времени и сил. Даже докопавшись до причины, они частенько просят исправить Wow64DisableWow64FsRedirection, все еще не понимая, что настоящая причина в том, что они не в курсе неявных зависимостей в их коде.

Поэтому не понятно почему автор так категоричен.
Ну написал бы заметку, но зачем делать такой ахтунг.

Ахтунг внимание привлекает. Может задумается кто-нибудь, да глядишь на эти грабли не наступит. Проблема-то, не в самой функции. Проблема в том, что мало кто понимает какие зависимости скрываются на строчками их кода.

Во вторых Wow64DisableWow64FsRedirection работает только для потока, который ее вызвал.
что мешает вызвать это в другом потоке?

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

Поэтому не понятно почему автор так категоричен.
Ну написал бы заметку, но зачем делать такой ахтунг.

Eugene Golushkov :
Не лучше ли тогда было бы использовать флаг FILE_FLAG_NO_WOW64_FS_REDIRECTION в вызове CreateFile?

Лучше. С точки зрения сложившейся ситуации еще лучше было, если бы перенаправление в Wow64 не существовало с самого начала.

выглядят как минимум странно. Типа “росло, росло и выросло” а не как вдумчиво и дальновидно спроектированный механизм.

Это так и есть. Вдумчиво спроектированная часть – это возможность просто пересобрать 32-х разрядное приложение под 64-е бита и оно, с большой вероятностью, заработает. А вот Wow64DisableWow64FsRedirection – это не очень продуманные попытки обойти побочные эффекты перенаправления файлового ввода вывода.