Делюсь интересным багом, грабли которого M$ услужливо разложила в системе.
Код самый простой — тупо вывести последнюю модификацию каталога:
var di = new DirectoryInfo(@"C:\Windows\System32");
Log.Trace("Modif: " + di.LastWriteTime);
И код в принципе работает! Но... в одной проге он выдаёт "20/3/2023 09:58:51", а в другой — "24/2/2023 02:02:05"!!!
Т.е. это даже не игры с часовым поясом, а отставание на целый месяц! Откуда такая разница?
Всё просто — "медвежья помощь" мелкософта!
Оказывается, одна прога была с prefer 32 bit, а другая без (обе AnyCPU). В результате, вместо нормального C:\Windows\System32 дридцатидвухбитной проге венда подсовывала c:\Windows\SysWOW64 ! Спасибо, обезьяны! Два часа отладки долой.
Я не знаю, насколько "переход на 64 бита" был тяжел для мелкософта, но вот это "c:\Program Files\", "c:\Program Files (x86)\", "C:\Windows\System32", "c:\Windows\SysWOW64" — маразм чистой воды и ГРАБЛИ на всю оставшуюся жизнь. Только придурок мог так "изящно" замаскировать венду для 32-битных прог.
Короче, программируйте и оглядывайтесь, не прилетит ли вам очередным граблями в лобешник!
Здравствуйте, Baiker, Вы писали:
B>Оказывается, одна прога была с prefer 32 bit, а другая без (обе AnyCPU). В результате, вместо нормального C:\Windows\System32 дридцатидвухбитной проге венда подсовывала c:\Windows\SysWOW64 !
Это вполне известное поведение, еще со времен 64-битной ХР. Странно что ты не знал. Куда интереснее почему у тебя при этом было разное время.
Здравствуйте, Baiker, Вы писали:
B>Я не знаю, насколько "переход на 64 бита" был тяжел для мелкософта, но вот это "c:\Program Files\", "c:\Program Files (x86)\", "C:\Windows\System32", "c:\Windows\SysWOW64" — маразм чистой воды и ГРАБЛИ на всю оставшуюся жизнь. Только придурок мог так "изящно" замаскировать венду для 32-битных прог.
Если тебе нужно зачем-то System32, то почему ты не в курсе такого поведения, которому уже лет десять точно? Тогда, когда это первый раз пошло, об этом кричали на всех сайтах, да и может даже в мегафон на оживлённых перекрёстках. Давно уже подразумевается, что все и так знают. А если тебе не нужно System32, то и не тереби его.
Здравствуйте, Baiker, Вы писали:
B>Оказывается, одна прога была с prefer 32 bit, а другая без (обе AnyCPU). В результате, вместо нормального C:\Windows\System32 дридцатидвухбитной проге венда подсовывала c:\Windows\SysWOW64 ! Спасибо, обезьяны! Два часа отладки долой.
Это не баг, а обратная совместимость для всяких 32-битных программ, которые по прямому пути в C:\Windows\System32 лезут. Так они хотя бы имеют шанс получить желаемое, а без подсовывания SysWOW64 — шансов нет.
Здравствуйте, Baiker, Вы писали:
B>Делюсь интересным багом, грабли которого M$ услужливо разложила в системе. B>Код самый простой — тупо вывести последнюю модификацию каталога:
B>
B>var di = new DirectoryInfo(@"C:\Windows\System32");
B>Log.Trace("Modif: " + di.LastWriteTime);
B>
B>И код в принципе работает! Но... в одной проге он выдаёт "20/3/2023 09:58:51", а в другой — "24/2/2023 02:02:05"!!! B>Т.е. это даже не игры с часовым поясом, а отставание на целый месяц! Откуда такая разница?
Так точно!
dotnet\sdk\7.0.202
C:\tmp\test>dotnet run -r win-x64
Modif: 21.03.2023 10:11:08
C:\tmp\test>dotnet run -r win-x86
Modif: 15.03.2023 18:03:50
Поэтому я стараюсь избегать системных директорий и привилегий.
Environment.GetFolderPath(Environment.SpecialFolder.SystemX86);;
val it: string = "C:\Windows\SysWOW64"
Environment.GetFolderPath(Environment.SpecialFolder.System);;
val it: string = "C:\Windows\system32"
Здравствуйте, vsb, Вы писали:
vsb>Я ничего не понял. Из-за чего ошибка-то?
есть предположение, что на разных версиях он пытается получить информацию по разным директориям, но ТС, как обычно, много рассказывал какие все м-ки, но внятно выразить суть проблемы не смог.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Baiker, Вы писали:
B>>Оказывается, одна прога была с prefer 32 bit, а другая без (обе AnyCPU). В результате, вместо нормального C:\Windows\System32 дридцатидвухбитной проге венда подсовывала c:\Windows\SysWOW64 !
НС>Это вполне известное поведение, еще со времен 64-битной ХР
Известное, да только очень узкому кругу товарищей! Либо админам после спец.курсов, либо бедолагам с шишкой на лбу.
НС> Странно что ты не знал
АБСОЛЮТНО ничего странного! Где тебе винда открытым текстом говорит, что System32 — это не System32?? Так что не выпендривайся, далеко не все обязаны знать крючкотворства вендолабателей. Программисты — тем более, МЫ НЕ АДМИНЫ, чтобы это знать.
НС> Куда интереснее почему у тебя при этом было разное время.
Не У МЕНЯ, а у микрософта! Простая догадка: "замаскировать" папку они замаскировали, да только РАБОТУ с этой папкой оставили на "обычном" уровне — т.е. когда пишут в system32, вторую папку даже не касаются. Отсюда и баги. Т.е. даже на этом уровне "маскировка" получилась халтура.
Здравствуйте, Baiker, Вы писали:
B>>>Оказывается, одна прога была с prefer 32 bit, а другая без (обе AnyCPU). В результате, вместо нормального C:\Windows\System32 дридцатидвухбитной проге венда подсовывала c:\Windows\SysWOW64 ! НС>>Это вполне известное поведение, еще со времен 64-битной ХР B>Известное, да только очень узкому кругу товарищей!
Я бы так не сказал.
B>АБСОЛЮТНО ничего странного! Где тебе винда открытым текстом говорит, что System32 — это не System32??
Здравствуйте, Sharowarsheg, Вы писали:
S>Если тебе нужно зачем-то System32, то почему ты не в курсе такого поведения
Потому что я НЕ АДМИН?? Ты же тоже не всё в жизни знал, когда лез впервые пробовать? Люди варят пельмени в холодной воде не потому, что тупые — просто такая инфа весьма специальная, узнаёшь только после прилетания грабель. Мне интересно другое — наколько надо быть самодовольным пижоном, чтобы вместо осуждения маразматического технического решения наезжать на людей, что это ещё ОНИ виноваты, что не знали придурошных "трюков" микросовта "как спрятать венду от 32 бит".
Вообще-то у M$ (как полного владельца ОС) была тысяча вариантов, как аккуратно модернизировать ОС без необходимости прибегания к трюкам "вот вам каталог, только это совсем не этот каталог" (как и с registry, кстати). Но M$ пошла своим любимым самым гадостным путём — "делать вид, что всё по-старому". По этой же причине они эмулировали баги(!) предыдущей версии, чтобы игрушки не падали в новой венде. Это уже вообще днище технических решений.
Здравствуйте, Xander Zerge, Вы писали:
XZ>Здравствуйте, Baiker, Вы писали:
B>>Оказывается, одна прога была с prefer 32 bit, а другая без (обе AnyCPU). В результате, вместо нормального C:\Windows\System32 дридцатидвухбитной проге венда подсовывала c:\Windows\SysWOW64 ! Спасибо, обезьяны! Два часа отладки долой.
XZ>Это не баг, а обратная совместимость для всяких 32-битных программ
Категорически не согласен. Было бы ВРЕМЯ ОДИНАКОВОЕ, тогда да — "совместимость". На деле "маскировочный" SysWOW64 работает независимо, что и показала практика.
Здравствуйте, vsb, Вы писали:
vsb>Я ничего не понял. Из-за чего ошибка-то?
Ему зачем то понадобилась дата модификации каталога system32 и он в 2023 году с удивлением для себя обнаружил, что в режиме эмуляции 32-х бит винда использует другой system32 с 32-хбитными версиями системных dll.
Здравствуйте, vaa, Вы писали:
vaa> Так точно! vaa>dotnet\sdk\7.0.202
Как я понял, от версии дотнета ничего не зависит — тут ошибка аж на системном уровне. Но спасибо, что проверил!
vaa>Поэтому я стараюсь избегать системных директорий и привилегий. vaa>Environment.GetFolderPath(Environment.SpecialFolder.SystemX86)
Дак в этом и прелесть дотнета, что мы максимально абстрагируемся от низлежащей ОС! Даже 32/64 НЕ ДОЛЖНЫ быть никогда нашим "головняком"! Не говоря о позорной венде, где ещё и "мир 32-битов" живёт отдельной жизнью. Венде практически НИЧЕГО не стоило распознавать старые проги и запускать в соотв. окружении, зачем было городить "Program Files(x86)"?? Да ещё и с тупорылым ПРОБЕЛОМ, перепортившим жизнь ещё тысячам прог, которые просто не понимают, как в пути может быть пробел! (который во всех операционках был разделителем аргументов) Ладно, чо уж. От M$ разве можно ожидать интеллектуальных решений!
Здравствуйте, _NN_, Вы писали:
_NN>Не смог пройти мимо: 64-битная Windows — это очень просто!
)))))))) ВОТ ВОТ!! Всё просто — рассмотрите это большую кучу грабель и просто проедьте по ней на велосипеде! Спасибо, NN! Вот лучшее объяснение "как можно не знать о "хитрых" 64 битах венды". Да всё просто! Мы — программисты, наша главная задача — алгоритмы. Низлежащий мусор — лишь проекция реальности.
Здравствуйте, Baiker, Вы писали:
B>Потому что я НЕ АДМИН??
При чем тут админ? Эту особенность исполнения 32-хбитных программ в 64 битной венде должен программист знать должен.
B> Ты же тоже не всё в жизни знал, когда лез впервые пробовать?
Се ля ви. Ты, наверное, не ту профессию выбрал — программисту нужно знать овердохрена тонкостей, увы.
B>Вообще-то у M$ (как полного владельца ОС) была тысяча вариантов, как аккуратно модернизировать ОС без необходимости прибегания к трюкам "вот вам каталог, только это совсем не этот каталог"
Здравствуйте, Baiker, Вы писали:
B>Категорически не согласен. Было бы ВРЕМЯ ОДИНАКОВОЕ, тогда да — "совместимость". На деле "маскировочный" SysWOW64 работает независимо, что и показала практика.
Он и должен работать независимо, это другой каталог с другими файлами. То что ты зачем то заточил логику на время последнего обновления system32 — твоя проблема.
У тебя, кстати, в твоем коде таки и написано константой, @"C:\Windows\System32"?
Здравствуйте, Baiker, Вы писали:
B>Категорически не согласен. Было бы ВРЕМЯ ОДИНАКОВОЕ, тогда да — "совместимость". На деле "маскировочный" SysWOW64 работает независимо, что и показала практика.
В каком смысле маскировочный? Это другая папка с другими файлами, которую и должна запрашивать 32-битная программа. Но если она лезет в System32, где ей делать нечего, ей всё равно подсовывают правильную.
Здравствуйте, Baiker, Вы писали:
S>>Если тебе нужно зачем-то System32, то почему ты не в курсе такого поведения
B>Потому что я НЕ АДМИН?? Ты же тоже не всё в жизни знал, когда лез впервые пробовать? Люди варят пельмени в холодной воде не потому, что тупые — просто такая инфа весьма специальная, узнаёшь только после прилетания грабель.
Предполагается, что если ты программист, то ты читаешь документацию на то, с чем работаешь; а не обучаешься методом скачек по граблям.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Он и должен работать независимо, это другой каталог с другими файлами. То что ты зачем то заточил логику на время последнего обновления system32 — твоя проблема. НС>У тебя, кстати, в твоем коде таки и написано константой, @"C:\Windows\System32"?
Я помню когда-то давно, где-то во времена XP так получилось, что у меня был комп, без диска C. Даже не помню почему так получилось. Но не было и не было, почему бы и нет. Винда стояла на H: соответственно.
блиин, это ж сколько разных программ там или вообще не запускалось или падало где-нибудь в процессе вдруг... Сразу становилось видно, что вот тут автор все лучше всех знает как должно и правильно, и нечего читать что там пишут в документации от microsoft, все равно там все тупые и ничего не знают.
Здравствуйте, fmiracle, Вы писали:
F>Я помню когда-то давно, где-то во времена XP так получилось, что у меня был комп, без диска C. Даже не помню почему так получилось. Но не было и не было, почему бы и нет. Винда стояла на H: соответственно.
Это можно сделать и сегодня тоже с тем же результатом
Да даже не нужно винду ставить на другой диск, достаточно хотя бы профиль пользователя вынести отдельно и уже будут проблемы не говоря про другие директории.
Здравствуйте, Baiker, Вы писали:
B>Я не знаю, насколько "переход на 64 бита" был тяжел для мелкософта, но вот это "c:\Program Files\", "c:\Program Files (x86)\", "C:\Windows\System32", "c:\Windows\SysWOW64" — маразм чистой воды и ГРАБЛИ на всю оставшуюся жизнь. Только придурок мог так "изящно" замаскировать венду для 32-битных прог. B>Короче, программируйте и оглядывайтесь, не прилетит ли вам очередным граблями в лобешник!
Вы можете на это смотреть как хотите, но то решение которое в итоге было принято позволяет работать 32-битным программам даже сегодня.
Кстати, в ARM64 сделано по похожему принципу и позволяет не переписывать программы x86.
Более того, есть даже способ запускать 16-битные приложение или даже запускать 16-битный установщик в самой современной системе.
Одна из причин в таком решение это то, что нет переменной среды с system32.
Можно ли было сломать совместимость и сделать "всё правильно" ?
Можно конечно, но тогда будет достаточно недовольных пользователей, по видимому включая вас, у которых всё работало, а теперь перестало.
Некоторые операционные системы так и работают, раз в несколько лет всё, что вы купили просто перестаёт работать.
И вам остаётся надеется, что разработчик нужных вам программ был заинтересован переписывать.
Вам такой подход нравится больше ?
Уже объяснили, спасибо. Ну сделал как сделали. Сделали бы по-другому, у других людей по-другому бы сломалось. Я так понимаю, они хотят, чтобы и программы 32/64 битные работали "бесшовно", и чтобы для перехода на 64 бита достаточно было бы перекомпилировать программу, даже если в ней захардкодено "C:\Windows\System32". Мне тоже кажется странным всё это, по-мне правильно было бы сделать C:\Windows\System64 для 64-битных библиотек и всё, но, очевидно, я над этим решением думал 5 секунд, а архитекторы микрософта гораздо дольше, раз сделали как сделали, значит причины были весомые.
Здравствуйте, vsb, Вы писали:
vsb>Уже объяснили, спасибо. Ну сделал как сделали. Сделали бы по-другому, у других людей по-другому бы сломалось. Я так понимаю, они хотят, чтобы и программы 32/64 битные работали "бесшовно", и чтобы для перехода на 64 бита достаточно было бы перекомпилировать программу, даже если в ней захардкодено "C:\Windows\System32". Мне тоже кажется странным всё это, по-мне правильно было бы сделать C:\Windows\System64 для 64-битных библиотек и всё, но, очевидно, я над этим решением думал 5 секунд, а архитекторы микрософта гораздо дольше, раз сделали как сделали, значит причины были весомые.
Думаю, их остановила необходимость в таком случае тотально заменять 32 на 64 для всех переводимых в 64 бита программ и их DLL.
Здравствуйте, fmiracle, Вы писали:
F>блиин, это ж сколько разных программ там или вообще не запускалось или падало где-нибудь в процессе вдруг... Сразу становилось видно, что вот тут автор все лучше всех знает как должно и правильно, и нечего читать что там пишут в документации от microsoft, все равно там все тупые и ничего не знают.
Ну так из-за такого кривого софта МС и вынужден был замапить system32 на другую папку. Вот та памятная 64битная ХР как раз была без кучи таких фокусов. В результате она была весьма специфической, применимой в очень особых случаях, так как куча 32-битного софта под ней не работала.
F>>блиин, это ж сколько разных программ там или вообще не запускалось или падало где-нибудь в процессе вдруг... Сразу становилось видно, что вот тут автор все лучше всех знает как должно и правильно, и нечего читать что там пишут в документации от microsoft, все равно там все тупые и ничего не знают.
НС>Ну так из-за такого кривого софта МС и вынужден был замапить system32 на другую папку. Вот та памятная 64битная ХР как раз была без кучи таких фокусов. В результате она была весьма специфической, применимой в очень особых случаях, так как куча 32-битного софта под ней не работала.
По-моему WOW64 был на всех 64битных версиях, т.е. на winxp тоже.
B>Я не знаю, насколько "переход на 64 бита" был тяжел для мелкософта, но вот это "c:\Program Files\", "c:\Program Files (x86)\", "C:\Windows\System32", "c:\Windows\SysWOW64" — маразм чистой воды и ГРАБЛИ на всю оставшуюся жизнь. Только придурок мог так "изящно" замаскировать венду для 32-битных прог. B>Короче, программируйте и оглядывайтесь, не прилетит ли вам очередным граблями в лобешник!
Здравствуйте, Baiker, Вы писали:
B>Я не знаю, насколько "переход на 64 бита" был тяжел для мелкософта, но вот это "c:\Program Files\", "c:\Program Files (x86)\", "C:\Windows\System32", "c:\Windows\SysWOW64" — маразм чистой воды и ГРАБЛИ на всю оставшуюся жизнь. Только придурок мог так "изящно" замаскировать венду для 32-битных прог.
Кстати, если на то пошло, то можно вспомнить происхождение system32
В 16-битной Windows был \windows\system. Он и сейчас есть, только в нем почти ничего нет. А тогда там были системные файлы.
Создавая 32-битную Windows, MS оставила этот каталог в покое, а для 32-битных программ сделала system32.
А теперь представьте себе на минуту, что 16-битной Windows не было бы вообще. Тогда, очевидно, для хранения системных файлов использовался бы \windows\system — зачем еще число добавлять ?
Так бы и жили. А при переходе к 64-битной Windows , естественно, имя этого каталога менять не стали бы — с чего ради ? Придумали бы способ разграничить доступ средствами ОС. Что и было фактически сделано.
Здравствуйте, Baiker, Вы писали:
B>Потому что я НЕ АДМИН??
Зато бравада из тебя так и прёт, а как реальная ситуация настала — так сразу не админ, и вообще мопед не твой. Ты уж определись, кто ты — или Лев Толстой или ...
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это вполне известное поведение, еще со времен 64-битной ХР. Странно что ты не знал. Куда интереснее почему у тебя при этом было разное время.
Так каталоги разные. В один что-то записали, в другой — нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Baiker, Вы писали:
B>Я не знаю, насколько "переход на 64 бита" был тяжел для мелкософта, но вот это "c:\Program Files\", "c:\Program Files (x86)\", "C:\Windows\System32", "c:\Windows\SysWOW64" — маразм чистой воды и ГРАБЛИ на всю оставшуюся жизнь. Только придурок мог так "изящно" замаскировать венду для 32-битных прог.
Так точно!
