Невидимые файлы .msc
ты вроде достаточно умный пользователь, а такие простые вещи, как указание на систему, упускаешь. Дай угадаю, у тебя 64-битная винда?
Фару и тотал коммандеру за содержимое system32 выдается содержимое SysWOW64
Да, похоже на то. Только если сравнивать тоталом содержимое папок System32 и SysWOW64, то они отличаются - правда в подкаталогах.
вот оно проявление альтернативности мышления микрософтовцев: нельзя было оставить system32 в покое и добавить system64, так нет-же, им надо было поизвращаться с редиректами
вот оно проявление альтернативности мышления микрософтовцев: нельзя было оставить system32 в покое и добавить system64, так нет-же, им надо было поизвращаться с редиректамитакие слова как "совместимость", "работает, не трогай", "стоимость перехода" и т.д. тебе о чем-нибудь говорят?
при подходе microsoft-а - вся тьма прог, скриптов и т.д. без проблем работает и в 64-х битном окружении.
при твоем подходе - для 64-х бит пришлось бы всем перелопачивать эту гору кода.
Теперь я точно никогда не поставлю себе 64битную винду.
Натрахавшись вдоволь с этой соместимостью в солярке, я больше не хочу следовать принципам, которые ты указал в виде усложнения схемы работы с библиотеками и разрядностью.
Натрахавшись вдоволь с этой соместимостью в солярке, я больше не хочу следовать принципам, которые ты указал в виде усложнения схемы работы с библиотеками и разрядностью.
такие слова как "совместимость", "работает, не трогай", "стоимость перехода" и т.д. тебе о чем-нибудь говорят?значит, забьём на нормальную работу 32хбитных прог из-за лени перелопатить 64хбитные билды?
при подходе microsoft-а - вся тьма прог, скриптов и т.д. без проблем работает и в 64-х битном окружении.
при твоем подходе - для 64-х бит пришлось бы всем перелопачивать эту гору кода.
Теперь я точно никогда не поставлю себе 64битную винду.Боюсь, лет через 10 поддерживать 32хбитные окошки перестанут
Натрахавшись вдоволь с этой соместимостью в солярке, я больше не хочу следовать принципам, которые ты указал в виде усложнения схемы работы с библиотеками и разрядностью.
значит, забьём на нормальную работу 32хбитных прог из-за лени перелопатить 64хбитные билды?в том-то и хитрость, что 32-х битные тоже отлично работают.
32 битным прогам в качестве system32 подсовывается та самая wow64
в том-то и хитрость, что 32-х битные тоже отлично работают.извращение с файловой системой - это отличная работа?
32 битным прогам в качестве system32 подсовывается та самая wow64
извращение с файловой системой - это отличная работа?для 32-х битных приложений делается своя отдельная песочница, в чем извращение?
64-х битные приложения видят всё - так как есть: system32 - как реальную системную папку, и wow64 - как папку песочницы.
ты предлагаешь эти старые 32-х битные приложения пустить в реальную жизнь без песочницы - пусть портят жизнь нормальным окружающим?
пусть портят жизнь нормальным окружающим?Как, например?
64-х битные приложения видят всё - так как естьFail.
64-х битные приложения видят всё - так как естьпримеры?
Fail.
ps
стоит все-таки подтверждать свои слова без напоминания об этом.
х64 приложения не отображаются в контекстном меню файла, вызванного из х86 приложения.
То есть, среду х86 они не видят.
То есть, среду х86 они не видят.
Как, например?из банального - записать 32-х dll в общую системную папку, из которой подгружают dll-ки 64-ые приложения.
или, наоборот, пытаться загрузить 64-х dll из общей системной папки.
более тонкое - изменение настроек, которые были расширены в 64-х ОС, тогда 32-х приложение может затереть те настройки, которые были установлены 64-х приложениями.
х64 приложения не отображаются в контекстном меню файла, вызванного из х86 приложения.ты переставил местами причину и следствие.
То есть, среду х86 они не видят.
это x86 приложение не может выйти из песочницы и соответственно не видит, какие там доп. ярлыки навесили 64-х битные приложения.
Я так понял, Радист предлагал оставить в папке System32 то, что там было, т.е. 32-битные дллки, а 64-битные приложения писать так, чтобы они работали с папкой System64. Тогда не придётся переписывать все имеющиеся приложения, а лишь учитывать это в новых.
То есть, среду х86 они не видят.кстати еще не различаешь понятия: не может видеть; не хочет видеть; видет, но не хочет туда лезть.
Я так понял, Радист предлагал оставить в папке System32 то, что там было, т.е. 32-битные дллки, а 64-битные приложения писать так, чтобы они работали с папкой System64. Тогда не придётся переписывать все имеющиеся приложения, а лишь учитывать это в новых.возьмем такой интересный случай как скрипт: который был написан лет дцать назад.
это старая прога, или новая?
его надо переписывать под 64 бита, или нет?
т.е. предлагается делать теперь два вида скриптов: один который будет запускаться в 32-х битном окружение, а другой в 64-х?
ps
microsoft-овский путь говорит - что не надо ничего переписывать.
проги надо лишь пересобрать под 64 бита, а скрипты лишь надо запустить в 64-х битном окружении.
Не может, ибо лезть обязан.
т.е. предлагается делать теперь два вида скриптов: один который будет запускаться в 32-х битном окружение, а другой в 64-х?Что мешает сделать взаимодействие 32-битных и 64-битных приложений прозрачным? Единственное что требуется обеспечить - невозможность загрузки 32-битных модулей в 64-битные приложения и наоборот.
Что касается скриптов, ситуация, в которой скрипту может потребоваться информация о расположении папки system<platformID>, достаточно редкая (если обеспечена прозрачность).
Единственное что требуется обеспечить - невозможность загрузки 32-битных модулей в 64-битные приложения и наоборот.Фарс.
Фарс.что тебе неясно?
Что мешает сделать взаимодействие 32-битных и 64-битных приложений прозрачным? Единственное что требуется обеспечить - невозможность загрузки 32-битных модулей в 64-битные приложения и наоборот.отлично.
у всех 64-х битный dll-ек будут новые названия?
т.е. при пересборке под 64 бита ты предлагаешь просмотреть все места, где грузились dll-ки и поправить названия?
Мне всё ясно.
Это ты не понимаешь, что предлагаешь бессмыслицу. х86-apps должны взаимодействовать с х64.
По крайней мере потому, что часто нет аналогов х86 из х64, и приходится юзать х86.
Это ты не понимаешь, что предлагаешь бессмыслицу. х86-apps должны взаимодействовать с х64.
По крайней мере потому, что часто нет аналогов х86 из х64, и приходится юзать х86.
отлично.Это не обязательно. Если кто-то грузил дллки из system32 по полному пути - значит сам себе злобный Буратино. В остальных случаях при поиске файла будет учитываться разрядность текущего процесса (как вариант, сделать частью виртуальной 32-битной машины дописывание system32 в path, либо LoadLibrary должна быть более интеллектуальна и при несоответствии разрядности искать другой файл с тем-же именем).
у всех 64-х битный dll-ек будут новые названия?
т.е. при пересборке под 64 бита ты предлагаешь просмотреть все места, где грузились dll-ки и поправить названия?
Это ты не понимаешь, что предлагаешь бессмыслицу. х86-apps должны взаимодействовать с х64.В это взаимодействие не может входить смешивание кода двух различных платформ. Именно про это я пишу. А о каких вариантах взаимодействия ты пишешь?
По крайней мере потому, что часто нет аналогов х86 из х64, и приходится юзать х86.
Ну о , допустим.
Если кто-то грузил дллки из system32 по полному пути - значит сам себе злобный Буратинотолько ты забываешь, что злобный буратино - это какой-нибудь разработчик, которого уже давно и след простыл,
а на деньги попал ты (как пользователь этой программы)
как вариант, сделать частью виртуальной 32-битной машины дописывание system32 в path, либо LoadLibrary должна быть более интеллектуальна и при несоответствии разрядности искать другой файл с тем-же именеми чем это шаманство - лучше, чем существующее?
microsoft-ский вариант - приводит к небольшой путанице с именами, но зато весь миллион прог работает.
твой вариант - вводит более формальные красивые имена, но ломает кучу программ.
ради чего стоит выбирать твой путь?
ps
кстати если представить на минутку, что цифры 32 в имени system32 означает имя любимого хомячка Билла Гейтса (или еще что-нибудь никак не связанное с битами то вообще никакой проблемы нет.
есть ОС (32х, 64x, 128x) - и в ней всегда системная дира с одним и тем же названием system32.
ура!. мир стал проще, не надо заморачиваться, что имя диры меняется от бита к биту.
для загрузки иконок, можно вызывать что-то типа LoadLibraryEx(...,LOAD_LIBRARY_AS_IMAGE_RESOURCE|LOAD_LIBRARY_AS_DATAFILE что не подразумевает выполнение кода и не требует проверки разрядности. Всё остальное, что может потребоваться для добавления пунктов меню, не требует прямого взаимодействия модулей различной разрядности.
Зато такой подход ведёт к вёдрам типа высты. Сколько они её писали? Через какое время после релиза она стала относительно безбажной?
только ты забываешь, что злобный буратино - это какой-нибудь разработчик, которого уже давно и след простыл,Ну, system32 как назывался, так и называется, в чём проблема?
а на деньги попал ты (как пользователь этой программы)
твой вариант - вводит более формальные красивые имена, но ломает кучу программ.Я так и не услышал конкретного варианта поломки. Лишь абстрактные размышления. А текущий вариант ломает, как минимум, файловые менеджеры.
ура!. мир стал проще, не надо заморачиваться, что имя диры меняется от бита к биту.Прикладной софт это не должно волновать, как называется эта папка. А если .нет доведётся до ума к версии 8.0, об этом вообще противопоказано будет думать, ведь это будет одно из неотъемлемых свойств хорошей платформы.
Всё остальное, что может потребоваться для добавления пунктов меню, не требует прямого взаимодействия модулей различной разрядности.не вся правда.
на пункте меню может висеть плагин (например, который показывает разные иконки для разного содержимого файла который будет подгружаться в адресное пространство.
не вся правда.Кажется, такие плагины работают через COM? Значит не стоит беспокоиться, он подгрузится в отдельном процессе.
на пункте меню может висеть плагин (например, который показывает разные иконки для разного содержимого файла который будет подгружаться в адресное пространство.
А текущий вариант ломает, как минимум, файловые менеджеры.какие например? 32-х битные? так они же в песочнице.
то, что Dos Navigator, Norton и Volcov Commander плохо работают с современной файловой системой - тебя тоже расстраивает?
возьми 64-х битный менеджер - и никаких проблем у тебя не будет.
Я так и не услышал конкретного варианта поломки.у меня был скрипт, который ставил мое приложение.
этот скрипт ставил dll-ки в system32 (да, все было плохо, это имя было где-то захардкорено в недрах скрипта)
я пересобрал свое приложение под 64-х бита, и скрипт я теперь тоже запускаю в 64-х окружении.
но вот черт - после запуска скрипта ничего не работает.
мое приложение не работает потому что, 64 dll-ки улетели в песочницу, а песочница неработает - потому что там откуда-то взялись 64-ные dll-ки.
Прикладной софт это не должно волновать, как называется эта папкапочему же в этом треде большинство забывают, что еще есть около системный софт, например, скрипты?
А взаимодействие программ между собой сводится к чему-то большему?
Кажется, такие плагины работают через COM? Значит не стоит беспокоиться, он подгрузится в отдельном процессе.только часть com-а умеет маршалиться(работать между разными процессах).
например, FileHandle между процессами "почему-то" передать нельзя.
А взаимодействие программ между собой сводится к чему-то большему?COM, сообщения, memory mapping, глобальные объекты синхронизации. Или ты под программами имеешь в виду не запущенные процессы, а что-то другое?
Сколько они её писали? Через какое время после релиза она стала относительно безбажной?какое отношение это имеет к обсуждаемой теме?
64-бита еще в xp появились
только часть com-а умеет маршалиться(работать между разными процессах).Не "почему-то", причина вполне конкретная - нарушение доступа. Неужели в таких плагинах используются хендлы?
например, FileHandle между процессами "почему-то" передать нельзя.
Неужели в таких плагинах используются хендлы?иконки, вроде, тоже, например, не маршалятся.
иконки, вроде, тоже, например, не маршалятся.Это естественно, т.к. иконка - это ресурс, а следовательно - memory-mapped область в адресном пространстве процесса. Поэтому их можно передавать в виде строки вида "shell32.dll,NNN" (тем более что они кешируются).
Это естественно, т.к. иконка - это ресурсниоткуда не следует.
иконки бывает и на лету генерятся.
64-бита еще в xp появилисьага, с таким же успехом её могло бы и не быть, это же чистая поделка для красноглазиков.
memory mappingЭто скорее задача ОС.
Ну да ладно, я в этом не особо шарю...
Ну да ладно, я в этом не особо шарю...Как-бы поэтому, вместо этой фразы:
Это скорее задача ОС.следовало написать следующую:
объясни, пожалуйста, что это такое, с чем его едят и как оно используется для взаимодействия между приложениямиОтвечаю: эта такая фича, позволяющая отобразить кусок файла в память. При чём это может быть кусок выделенный из файла подкачки. Понятие отобразить означает что содержимое области памяти и области файла будут совпадать. Есть механизм, позволяющий отразить один и тот-же кусок одного и того-же файла в память разных процессов. Это может использоваться для передачи информации между ними. Естественно, что это требует использования объектов синхронизации.
Взрывос. Завтра обмозгую твой пост.
П.С. Вы все, анимешники, такие умные?
П.С. Вы все, анимешники, такие умные?
Сколько они её писали?Полтора года, кажется.
Через какое время после релиза она стала относительно безбажной?За полгода до релиза она стала относительно безбажной.
и сколько они её писали?
Полтора года
Что там с копированием файла было в первый год?ХЗ.
Охуенно. А это как, например?1) _Относительно_ безбажной.
2) Anna Kurnikova naked! TO READ MORE, REGISTER OR LOGIN BELOW.
64-х битные приложения видят всё - так как есть: system32 - как реальную системную папку, и wow64 - как папку песочницы.в нормальных ОС для этого есть ldconfig (даже в гребаной соляре есть crle который занимается динамическими библиотеками.
И только в винде это сделали на уровне ФС.
в нормальных ОС для этого есть ldconfig (даже в гребаной соляре есть crle который занимается динамическими библиотеками.чем это лучше, чем на уровне ФС?
И только в винде это сделали на уровне ФС.
ничем, ведь реализации обоих этих способов написаны на языках программирования, которые ничем не лучше ассемблера 
тем, что область видимость файлов не зависит ни от чего.
тем, что область видимость файлов не зависит ни от чего.что такая область видимости файлов?
Зато такой подход ведёт к вёдрам типа высты. Сколько они её писали? Через какое время после релиза она стала относительно безбажной?За год-полгода до выпуска.
За год-полгода до выпуска.почему-то я слышал мнение, что после выхода сп1 ей уже можно пользоваться.
У криворуких всё не слава богу.
Будто если я тебе скажу, что в течение 5 лет знакомства с линуксом я стал считать, что им можно пользоваться только в прошлом году, ты будешь об этом рассказывать другим?
Будто если я тебе скажу, что в течение 5 лет знакомства с линуксом я стал считать, что им можно пользоваться только в прошлом году, ты будешь об этом рассказывать другим?
У криворуких всё не слава богу.неумение шагать по минному полю - это не криворукость...
Короче, это уже уход от конструктива.
Будто если я тебе скажу, что в течение 5 лет знакомства с линуксом я стал считать, что им можно пользоваться только в прошлом году, ты будешь об этом рассказывать другим?Ну, похоже на то, что в последнее время некоторые сборки становятся всё более юзабельными...
неумение шагать по минному полю - это не криворукость...Согласен с утверждением в буквальном смысле. Применительно к вопросу без примеров оно бессмысленно.
По теме могу сказать, что ни та, ни другая система не решает проблемы, связанной со скриптами, т.к. скрипты будут путать папки 32 и 64-битных библиотек в зависимости от того, под каким интерпретатором они запущены, 32 или 64-битным.
что такая область видимости файлов?
т.к. скрипты будут путать папки 32 и 64-битных библиотек в зависимости от того, под каким интерпретатором они запущены, 32 или 64-битным.решается на уровне интерпретатора, если скрипты, которые он , как правило, выполняет, используются для подобных целей.
Как-то я не очень понимаю, откуда интерпретатор узнает, предназначен ли скрипт для x64 или для x86, если скрипт этого не офиширует.
Как-то я не очень понимаю, откуда интерпретатор узнает, предназначен ли скрипт для x64 или для x86, если скрипт этого не офиширует.Достаточно проверять чтобы 32х-битные модули не писались в system64 и наоборот.
Это интерпертатор должен парсить каждый модуль, чтобы определить 32 или 64 битный он?
Это интерпертатор должен парсить каждый модуль, чтобы определить 32 или 64 битный он?Парсинг заключается в проверке небольшого поля в заголовке. В любом случае, для копирования приходится прочесть файл.
web-страницаэто не область видимости.
это только показывает, что бывают виртуальные папки, содержимое которых мапится по разному в зависимости от контекста.
ps
я надеюсь тебя не смущает, что папка home в *nix-е - у каждого своя, и реально указывают в разное место файловой системы?
home в *nix-е - у каждого свояэмм, а можно поподробнее, а то я не понял этого высказывания.
И что, он должен знать форматы всех заголовков, которые различаются для x86 и x64 ?
И каждый парсер должен знать? Жуть.
И каждый парсер должен знать? Жуть.
microsoft-ский вариант - приводит к небольшой путанице с именами, но зато весь миллион прог работает.Если файловый менеджер не может менеджить файлы, то он не работает. И пусть работают миллионы прог, без файлового менеджера в условиях отсутствия вменяемого интерактивного командного интерпретатора живётся очень неудобно. Вообще это решение microsoft'a навевает ужос, но ничего поделать нельзя - 32 битной адресации не хватает. Так что придётся терять либо управляемость компа и полную совместимость прог, либо ограничивать себя в памяти, либо переходить на никсы с аппаратной поддержкой виртуализации.
Так что придётся терять либо управляемость компа и полную совместимость прог, либо ограничивать себя в памяти, либо переходить на никсы с аппаратной поддержкой виртуализации.Может хватит уже ныть? Чего тебе там надо ворочать в system32 такого, что нельзя сделать с помощью Windows Explorer?
Если файловый менеджер не может менеджить файлы, то он не работает.так поставь файловый менеджер? в чем проблема? зачем ты пользуешься до сих пор Dos Navigator-ом?
что нельзя сделать с помощью Windows Explorer?видишь ли, я хочу забыть о нём как о страшном сне. Мечтаю вот о том, как заменить бы стандартные шелл диалоги, чтобы там не было эксплорера.
так поставь файловый менеджер? в чем проблема?В том, что под винду принято выкладывать бинарники, а не сырцы
А бинарной совместимости майкрософт не догадалась сделать. Хотя и могла бы, благо успешные примеры существуют. При чём тут dos navigator? Тебя неверно информировали. Я уже неоднократно в этом разделе утверждал, что лучше фара и тотала под винду файловых менеджеров нет.эмм, а можно поподробнее, а то я не понял этого высказывания.мне казалось, что в ряде дистров *nix-ов папку текущего юзера принято монтировать под неким определенным имененем
В том, что под винду принято выкладывать бинарники, а не сырцы А бинарной совместимости майкрософт не догадалась сделать. Хотя и могла бы, благо успешные примеры существуютчего? какое отношение микрософт и бинарная совместимость имеют к твоему любимому файловому менеджеру?
Я уже неоднократно в этом разделе утверждал, что лучше фара и тотала под винду файловых менеджеров нет.far же вроде open source.
так собери его под 64, да поставь.
При чём тут dos navigator?ты говоришь, что ты запускаешь свой 32-х битный файловый менеджер на 64х битной винде, и он что-то там неправильно показывает. вот я тебя и подкалываю, попробуй 16-x битный файловый менеджер запустить(например, Dos Navigator) , в нем вообще ФС очень странно выглядеть будет.
мне казалось, что в ряде дистров *nix-ов папку текущего юзера принято монтировать под неким определенным имененемвыполни команду mount, либо загляни в /proc - обнаружищь, что такого маунта не создаётся. В никсах вообще не принято каталоги монтировать, бажит эта фича, и ценные ресурсы ядра жрёт.
что нельзя сделать с помощью Windows Explorer?Кстати да, есть ещё один аргумент - не хочу. У пользователя должен быть выбор. Меня когда-то долго убеждали, что то, что стандартная виндовая шара отказывается шарить system32 - это нормально. Ничего подобного, я желаю управлять машиной по своему усмотрению, не спрашивая дядюшки била
выполни команду mount, либо загляни в /proc - обнаружищь, что такого маунта не создаётся. В никсах вообще не принято каталоги монтировать, бажит эта фича, и ценные ресурсы ядра жрёт.похоже, я ошибся с этим примером. прошу меня извинить.
чего? какое отношение микрософт и бинарная совместимость имеют к твоему любимому файловому менеджеру?то, что моему менеджеру не дают работать с файловой системой. То есть я не могу взять бинарник от старой системы и тупо запустить его.
то, что моему менеджеру не дают работать с файловой системой. То есть я не могу взять бинарник от старой системы и тупо запустить его.песочница, на то и песочница, что ограничения сами по себе по неволе появляются.
far же вроде open source.к сожалению стабильный фар не опенсорс, и для него написано куда больше плагинов, чем для версии, до сих пор находящейся в разработке. Я, кстати, так и не понял, как они будут делать файловый менеджер для терминала с переменной шириной шрифта. Когда выйдет хоть сколько нибудь стабильная версия выйдет, я сам портирую нужные мне плагины, если раньше этого не сделают другие, благо что у меня есть парочка фичареквестов, которые всё равно пришлось бы дописывать самому.
так собери его под 64, да поставь.
песочница, на то и песочница, что ограничения сами по себе по неволе появляются.либо не суйте меня в песочницу, либо дайте возможность ею управлять. Об хорошей управляемой песочнице под винду я давно мечтаю. А то как меня задрали "защищенные" программы, которые суют нос, куда их не просят, и ведут себя непотребно.
Вы все тут горазды только материться на Microsoft, да выдумывать себе проблемы.
http://www.google.ru/search?hl=ru&q=disable+syswow64+red...
По первой же ссылке:
http://www.google.ru/search?hl=ru&q=disable+syswow64+red...
По первой же ссылке:
32-bit applications can access the native system directory by substituting %windir%\SysnativeПо пятой ссылке утверждается существование API отключения этого перенаправления.
Wow64DisableWow64FSRedirection
И что, он должен знать форматы всех заголовков, которые различаются для x86 и x64 ?подозреваю, что для того, чтобы отличить 32хбитный программный модуль (exe/dll/...) от 64хбитного, достаточно прочесть один байт по определённому смещению (которое, правда, возможно придётся определять исходя из адреса, записанного по другому (фиксированному) смещению).
И каждый парсер должен знать? Жуть.
Делать такое определение много раз не нужно, достаточно либо принудительно буфферизировать запись файлов, отправляемых в system32/system64, либо наделить такой функциональностью системную функцию копирования + возложить задачу проверки совместимости платформ на службу защиты системных файлов.
Текущее решение, как мне кажется, решает лишь одну единственную проблему - проблему лёгкой портируемости с 32 битов на 64 бита программ, в которых используются абсолютные пути. Единственное где это реально нужно - инсталляторы, но в них можно и реализовать вменяемую проверку битности, если они нужны для установки 64х битных прог (с 32хбитными проблем не должно быть).
Текущее решение, как мне кажется, решает лишь одну единственную проблему - проблему лёгкой портируемости с 32 битов на 64 бита программ, в которых используются абсолютные пути. Единственное где это реально нужно - инсталляторы,вот есть прикладная прога, в которой есть буквальной следующий код:
var disk = GetSystemDrive;
var filename = disk + "\\system32";
if (File.Exists(filename
LoadLibrary(fliename);
как ты собираешься его портировать на 64бита по своей методике?
глазами искать в коде во всех программах все эти system32?
как ты собираешься его портировать на 64бита по своей методике?отстреливать недопрограммеров. желательно плазменной пушкой. это ошибки в DNA, они неизлечимы.
глазами искать в коде во всех программах все эти system32?
отстреливать недопрограммеров. желательно плазменной пушкой. это ошибки в DNA, они неизлечимы.но проблемы-то будут у пользователей, а не у программеров.
ps
вон, например, ghisler использовал какой-то левый инструмент для разработки Total Commander-а, теперь у него проблемы с переведом на 64-бита.
но в итоге-то, это бьет по куче пользователей в первую очередь, а не по нему.
но проблемы-то будут у пользователей, а не у программеров.Во-первых, загрузить "файл" %systemroot%\system32 нельзя, так что текст не дописан.
Во-вторых, с 32-битным билдом проблем не будет.
В третьих, 64-битный билд не сможет загрузить библиотеку при первом-же запуске. Я не думаю, что кто-то будет распостранять программу даже ни разу не запустив, так что проблема вылезет у разработчика, а не у пользователя.
Где вымышленная проблема пользователя?
psКакое отношение это имеет к идиотскому решению микрософта "упростить мир" методом фиксирования названия папки system32 в не зависимости от платформы?
вон, например, ghisler использовал какой-то левый инструмент для разработки Total Commander-а, теперь у него проблемы с переведом на 64-бита.
но в итоге-то, это бьет по куче пользователей в первую очередь, а не по нему.
терминала с переменной шириной шрифтаЩИТО?! кто такое придумал?
ЩИТО?! кто такое придумал?В некоторых языках (в частности - в языках с иероглифическим письмом) символы достаточно широкие и их не желательно вместе с обычными символами равнять под одну ширину.
32-bit applications can access the native system directory by substituting %windir%\Sysnative
Не пашет
Похоже это работает нативно только под Vista и 2008.
Для 2003 нужно скачать фикс.
Про XP ничего не знаю.
Для 2003 нужно скачать фикс.
Про XP ничего не знаю.
В третьих, 64-битный билд не сможет загрузить библиотеку при первом-же запуске. Я не думаю, что кто-то будет распостранять программу даже ни разу не запустив, так что проблема вылезет у разработчика, а не у пользователя.речь шла о стоимости портирования существующей программы под x64.
Где вымышленная проблема пользователя?
сейчас ты заявляешь, что при использовании заявленного тобой метода - после пересборки проги под 64-бита требуется полная перетестирование всей программы, т.к. указанный кусок кода мог использоваться как угодно далеко от старта программы.
соответственно вся эта стоимость перетестирования ляжет на пользователей.
и после этого ты заявляешь, что твое предложение идет на благо пользователей?....
соответственно вся эта стоимость перетестирования ляжет на пользователей.на разрабов. Они же перетестируют. Хорошим разрабам этой обойдётся дешевле.
на разрабов. Они же перетестируют. Хорошим разрабам этой обойдётся дешевле.это ты заявляешь, как человек со стороны, или как человек который видел кухню разработки?
это ты заявляешь, как человек со стороны, или как человек который видел кухню разработки?Он разработчик =)
Оставить комментарий
Dimon89
Сегодня заметил интересную вещь. Винда утверждает, что в папке c:\Windows\System32 лежит куча .msc-файлов (для тех, кто не в теме - это административные консольки). Если зайти в эту папку Проводником - всё верно, там их целая куча. Однако и Far, и Total Commander видят там всего 1 файл. Остальных будто и вообще нет, т.е. даже поиском не находит. В то же время, поиск Проводника отлично их все видит. Где наёпка?PS Да, попытка запустить какой-нибудь из этих файлов через TC, находясь в нужной папке, приводит лишь к сообщению "File not found", а стандартный "Выполнить" обрабатывает их нормально.