Все программы находятся там же, в %ProgramFiles%, кроме случаев, когда вам требуется 32-битная версия, которая находится в %ProgramFiles(x86)%, за исключением ситуаций, когда дело касается 32-битной машины, и в этом случае они по-прежнему в %ProgramFiles%.
Все эти библиотеки, DLL, по-прежнему находятся в %SystemRoot%\System32, просто теперь они 64-битные. Ну а 32-битные, они вот, в %SystemRoot%\SysWOW64. Вы ещё следите за объяснением? Да, а 16-битные всё так же хранятся в %SystemRoot%\System – перемещать их в иное место было бы странным.
Данные реестра находятся в HKLM\Software, если только вы не имеете в виду данные для 32-битных программ, потому что в этом случае они в HKLM\Software\Wow6432Node.
А вообще правило очень простое: старайтесь всегда придерживаться 64-битных программ, и всё будет в шоколаде. Приложения же без 64-битных версий в любом случае малополезные, примером служат Office и Visual Studio [1]. Да, и всегда ставьте 32-битную версию Internet Explorer (она ставится по умолчанию), если вы хотите, чтобы что-нибудь из ваших дополнений работало. Ярлыки «по умолчанию» для всего прочего запускают 64-битные версии. Поскольку иметь по два ярлыка к каждой программе — не самый лучший выход, поэтому порой (cmd.exe) имеется только лишь один (64-битный), а второй вам нужно найти самостоятельно (всё там же, в SysWOW64, разумеется). Ну и конечно, не забудьте ‘Set-ExecutionPolicy RemoteSigned’ в обоих, 64- и 32-битной, версиях PowerShell.
Далее, всегда устанавливайте 64-битные версии драйверов и прочей фигни, кроме случаев, когда её нет (MSDORA, JET), или же вам требуются и 32-битная, и 64-битная версии (например, чтобы использовать MO / SqlCmd из 32-битного процесса, как MSBuild). Просто не следует делать этого, если 64-битный установщик уже установил 32-битную версию (как, например, Sql Native Client).
В общем, всё с ‘32’ в названии предназначено для 64 бит. Всё с ‘64’ — для 32 бит. Кроме, конечно, %ProgramW6432%, который является каталогом ProgramFiles для 64-битных программ в любом случае (ну, кроме как разве на 32-битной машине). Да, а .net-фреймворк фактически никуда не перемещался, просто у него рядом есть Framework64.
Ну то есть я вообще не понимаю, из-за чего люди так волнуются по поводу этого всего.
[1] Да, есть 64-битная версия Office 2010, но поскольку инсталлятор в целом не сообщает о ней, это неважно.
Здравствуйте, Torie, Вы писали:
T>Послушайте, в этом правда нет ничего сложного.
T>Все программы находятся там же, в %ProgramFiles%, кроме случаев, когда вам требуется 32-битная версия, которая находится в %ProgramFiles(x86)%, за исключением ситуаций, когда дело касается 32-битной машины, и в этом случае они по-прежнему в %ProgramFiles%.
Здравствуйте, Torie, Вы писали: T>Послушайте, в этом правда нет ничего сложного. T>[1] Да, есть 64-битная версия Office 2010, но поскольку инсталлятор в целом не сообщает о ней, это неважно. T>http://piers7.blogspot.com/2010/07/64-bit-explained.html T>[1] Ok, so there is a 64 bit version of Office 2010, but given the installer pretty much tells you not to install it, it doesn’t count.
Ну и перевод.
Здравствуйте, Mr.Cat, Вы писали:
T>>[1] Да, есть 64-битная версия Office 2010, но поскольку инсталлятор в целом не сообщает о ней, это неважно. T>>http://piers7.blogspot.com/2010/07/64-bit-explained.html T>>[1] Ok, so there is a 64 bit version of Office 2010, but given the installer pretty much tells you not to install it, it doesn’t count. MC>Ну и перевод.
Кстати да, всю шутку убили.
Видимо, не пробовали ставить Офис 2010 х64 бит. Он действительно перед установкой много пугает о том, как много всего стороннего или даже не совсем стороннего при этом работать не будет и предлагает взвесить решение, что вы хотите ставить именно х64 бит версию
Здравствуйте, fmiracle, Вы писали:
F>Кстати да, всю шутку убили. F>Видимо, не пробовали ставить Офис 2010 х64 бит. Он действительно перед установкой много пугает о том, как много всего стороннего или даже не совсем стороннего при этом работать не будет и предлагает взвесить решение, что вы хотите ставить именно х64 бит версию
Простите, но это пиз...ж — все ставится без всяких проблем и ругани. По ходу линуксоидлы с кривыми руками на винду переходят. А жадь. Сиделе бы в своем пингвинятнике.
Здравствуйте, MikePetrichenko, Вы писали:
MP>Простите, но это пиз...ж — все ставится без всяких проблем и ругани. По ходу линуксоидлы с кривыми руками на винду переходят. А жадь. Сиделе бы в своем пингвинятнике.
Никаких проблем и ругани — это точно.
А ты читал, что он пишет в информации перед установкой, или просто проигнорировал по привычке?
Здравствуйте, MikePetrichenko, Вы писали:
F>>Видимо, не пробовали ставить Офис 2010 х64 бит. Он действительно перед установкой много пугает о том, как много всего стороннего или даже не совсем стороннего при этом работать не будет и предлагает взвесить решение, что вы хотите ставить именно х64 бит версию MP>Простите, но это пиз...ж — все ставится без всяких проблем и ругани. По ходу линуксоидлы с кривыми руками на винду переходят. А жадь. Сиделе бы в своем пингвинятнике.
Молча сиди и завидуй как у нас в Линуксе всё классно работает.
У нас можно:
1) Запускать 32-битные приложения на 32-битном ядре (взять 32-битный дистрибутив, воткнуть туда 64-битное ядро — и оно будет работать).
2) Запускать 32-битные приложения на 64-битном ядре (без всяких магических перенаправлений).
2) Запускать 64-битные приложения на 64-битном ядре (как ни странно).
2) Запускать 64-битные приложения на 32-битном ядре (угу, это тоже возможно).
А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине.
Здравствуйте, Cyberax, Вы писали:
C>Молча сиди и завидуй как у нас в Линуксе всё классно работает.
Буквально на днях портировал виндовый код в линукс, обзавидовался блин. Г(ов)НО-мейк (GNU make), г-ениальный парсер которого (родом из 70х годов) в качестве отступов желает видить табы, а не пробелы это просто песня. Видимо корректный парсинг это rocket siense в мире линупс. Прекомпилённые заголовки, которые непойми как работают. Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник). Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win). Это только малая часть. Уж ешьте такое сами.
C>У нас можно: C>1) Запускать 32-битные приложения на 32-битном ядре
Ухтыж нифига себе, рыдаю от умиления
C>(взять 32-битный дистрибутив, воткнуть туда 64-битное ядро — и оно будет работать).
не факт, но лень разбираться (как и тебе с Сусёй)
C>2) Запускать 32-битные приложения на 64-битном ядре
о да!
C>(без всяких магических перенаправлений).
Перенаправления нужны вовсе не для возможности запуска
C>2) Запускать 64-битные приложения на 64-битном ядре (как ни странно).
Действительно странно
C>2) Запускать 64-битные приложения на 32-битном ядре (угу, это тоже возможно).
Этого "искаропки" в винде нет. Хотя не уверен насчёт семёрочного виртуализатора.
C>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине.
Татышо. А когда это он на винде перестал работать ? Почему это на моём Win2003 x86 все 8 гигов доступны ? (А про маркетинговое обрезание десктопных версий только вот не надо, это давно известно и не является технической проблемой).
Здравствуйте, IID, Вы писали:
C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. IID>Буквально на днях портировал виндовый код в линукс, обзавидовался блин. Г(ов)НО-мейк (GNU make), г-ениальный парсер которого (родом из 70х годов) в качестве отступов желает видить табы, а не пробелы это просто песня. Видимо корректный парсинг это rocket siense в мире линупс.
Вообще-то, это такая "фича" make с рождения. Самое простое тут — не использовать make.
Нафиг он нужен, когда есть CMake, scons или тот же waf?
IID>Прекомпилённые заголовки, которые непойми как работают. Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник). Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win). Это только малая часть. Уж ешьте такое сами.
Зато позволяют нормально делать циклические ссылки, так как зависимости разрешаются в рантайме загрузчиком.
C>>(взять 32-битный дистрибутив, воткнуть туда 64-битное ядро — и оно будет работать). IID>не факт, но лень разбираться (как и тебе с Сусёй)
Давай на деньги поспорим?
C>>(без всяких магических перенаправлений). IID>Перенаправления нужны вовсе не для возможности запуска
А для чего? Оно нужно из-за того, что куча приложений уже зашили слово "system32" намертво.
C>>2) Запускать 64-битные приложения на 32-битном ядре (угу, это тоже возможно). IID>Этого "искаропки" в винде нет. Хотя не уверен насчёт семёрочного виртуализатора.
В виртуализации можно, в VMWare. В семёрочном — низзя.
В Линуксе оно нативно вообще может работать.
C>>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине. IID>Татышо. А когда это он на винде перестал работать ? Почему это на моём Win2003 x86 все 8 гигов доступны ? (А про маркетинговое обрезание десктопных версий только вот не надо, это давно известно и не является технической проблемой).
Вот я про то и говорю. Чтоб этими 8Гб воспользоваться в 32 бит — нужен enterprise-сервер за кучу денег.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Cyberax, Вы писали:
C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. IID>Буквально на днях портировал виндовый код в линукс, обзавидовался блин. Г(ов)НО-мейк (GNU make), г-ениальный парсер которого (родом из 70х годов) в качестве отступов желает видить табы, а не пробелы это просто песня. Видимо корректный парсинг это rocket siense в мире линупс. Прекомпилённые заголовки, которые непойми как работают. Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник).
С этим вполне согласен. Гмэйком (и вообще мэйком) пользоваться невозможно. Нужен генератор этих мэйков или авто-билды. Вообще, это просто проблема тяжелого наследия времен железобетонных игрушек и экономии на спичках. Но она есть, да.
Однако, вынужден заметить, что и в Микрософте все плохо. Все гораздо хуже, чем в гмэйке. Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля. Иначе, если просто переименовывать, то нельзя будет сделать из набора проектов sln из за одинаковых гуидов. У студии от такого наступает полный когнитивный диссонанс вплоть до абсолютной недееспособности. Но 15 минут времени — это не самое страшное. Самое страшное, что за эти 15 минут успеваешь пережить весь ментальный геморрой со времен большого взрыва! По количеству WTF там 15 минут за 10 миллиардов лет надо считать. Вообще, самое страшное наказание программисту в аду — это вечно настраивать проекты в вижуал-студии.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>По количеству WTF там 15 минут за 10 миллиардов лет надо считать. Вообще, самое страшное наказание программисту в аду — это вечно настраивать проекты в вижуал-студии.
Открой для себя CMake. Я серьёзно, с ним я даже проекты для чистого Win32 делаю теперь. В чём фишка — из описания CMake делается студийный проект.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, MikePetrichenko, Вы писали:
F>>>Видимо, не пробовали ставить Офис 2010 х64 бит. Он действительно перед установкой много пугает о том, как много всего стороннего или даже не совсем стороннего при этом работать не будет и предлагает взвесить решение, что вы хотите ставить именно х64 бит версию MP>>Простите, но это пиз...ж — все ставится без всяких проблем и ругани. По ходу линуксоидлы с кривыми руками на винду переходят. А жадь. Сиделе бы в своем пингвинятнике. C>Молча сиди и завидуй как у нас в Линуксе всё классно работает.
C>У нас можно: C>1) Запускать 32-битные приложения на 32-битном ядре (взять 32-битный дистрибутив, воткнуть туда 64-битное ядро — и оно будет работать). C>2) Запускать 32-битные приложения на 64-битном ядре (без всяких магических перенаправлений). C>2) Запускать 64-битные приложения на 64-битном ядре (как ни странно). C>2) Запускать 64-битные приложения на 32-битном ядре (угу, это тоже возможно).
C>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине.
А 32-битную библиотеку можно загрузить в 64-битный процесс?
Здравствуйте, IID, Вы писали:
C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. IID>Буквально на днях портировал виндовый код в линукс, обзавидовался блин. Г(ов)НО-мейк (GNU make), г-ениальный парсер которого (родом из 70х годов) в качестве отступов желает видить табы, а не пробелы это просто песня. Видимо корректный парсинг это rocket siense в мире линупс.
Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки. Внимание, вопрос: зачем тратиться ради ламеров?
IID> Прекомпилённые заголовки, которые непойми как работают.
Наверно, надо тоже что-то почитать? ;)
IID> Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник).
Приведи пример зубодробительности.
IID> Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win).
И чем же они похожи на статические?
IID> Это только малая часть. Уж ешьте такое сами.
Вот скажи мне, мил человек — почему я не испытываю со всем этим существенных проблем? Может, потому, что иногда таки преодолеваю лень и пытаюсь понять, как оно устроено и почему?
А ты настолько повторил стандартные жалобы ламеров, которые ни странички не прочитали про программирование под Unix, что аж скучно до зевоты. Ладно бы ещё вспомнил реальные проблемы, было бы видно, что человек постарался и что-то понял. Но вместо этого — фонтан эмоций. Фу.
Здравствуйте, flonder, Вы писали:
F>А че вы все ржете так ? F>Чтобы рассмешить программиста достаточно все перевернуть наоборот ?
Как сказал Хайнлайн (наверняка упростив какого-то психолога), мы смеёмся, чтобы заглушить душевную боль. Не бывает смешных вещей, в которых кто-нибудь не страдает и нельзя представить себя на его месте.
Я уже много лет плотно не работаю с Windows, поэтому сам всё это не переживаю. Наверно, поэтому не смеялся. Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами.
Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
Здравствуйте, netch80, Вы писали:
N>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
Хуже всего, что "совместимость" от всех этих костылей с путями и перенаправлениями весьма липовая. Я портировал кое-что на 64 бита, и убрать захардкоденные пути для %SYSTEM% (даже если они есть) — это была наименьшая из всех проблем.
Решив высосанную из пальца проблему, M$ породил геморрой, который придется тянуть еще не одно десятилетие.
Здравствуйте, netch80, Вы писали:
N>Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами. N>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
Однако, в отношении GNU make у тебя налицо двойные стандарты
Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки. Внимание, вопрос: зачем тратиться ради ламеров?
Здравствуйте, midcyber, Вы писали:
N>>Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами. N>>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
M>Однако, в отношении GNU make у тебя налицо двойные стандарты ;)
M>
M>Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки. Внимание, вопрос: зачем тратиться ради ламеров?
Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. make (не говори GNU make, потому что их несколько версий от разных производителей) в случае необходимости переделки означает чуть ли не глобальную реформу в отрасли, потому что тот или иной makefile сопровождает любую юниксовую тулзу. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы:)
В случае же перехода 32->64 мы и так имеем грандиозную реформу всего кода. На момент подготовки этого перехода (я не говорю про сейчас, я говорю про 2002-2005 годы) крайне мало кода программ под Windows было готово для перекомпиляции под 64 бита и успешной работы под ней. Поэтому всё равно реформа требовалась. Почему бы в неё не включить и исправление по замене хардкоженных стандартных путей на получаемые из адекватного источника?
Здравствуйте, Torie, Вы писали:
N>>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
T>Хуже всего, что "совместимость" от всех этих костылей с путями и перенаправлениями весьма липовая. Я портировал кое-что на 64 бита, и убрать захардкоденные пути для %SYSTEM% (даже если они есть) — это была наименьшая из всех проблем. T>Решив высосанную из пальца проблему, M$ породил геморрой, который придется тянуть еще не одно десятилетие.
Ясно. Тогда тем более непонятно, почему соображения в пользу такой "совместимости" перевесили остальное...
Здравствуйте, Torie, Вы писали:
T>Здравствуйте, netch80, Вы писали:
N>>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
T>Хуже всего, что "совместимость" от всех этих костылей с путями и перенаправлениями весьма липовая. Я портировал кое-что на 64 бита, и убрать захардкоденные пути для %SYSTEM% (даже если они есть) — это была наименьшая из всех проблем. T>Решив высосанную из пальца проблему, M$ породил геморрой, который придется тянуть еще не одно десятилетие.
Этот весь геморой нужен для того чтобы 32-тные программы работали на 64-битной винде. Причем тут портирование и десятилетие?
Здравствуйте, Константин Б., Вы писали:
КБ>Этот весь геморой нужен для того чтобы 32-тные программы работали на 64-битной винде. Причем тут портирование и десятилетие?
Я писал про пихание 64-битных библиотек в system32. Ну и каким образом оно должно помочь работать 32-битным программам? Сам вдумайся в то, что ты написал.
Здравствуйте, netch80, Вы писали:
N>Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы
Вот в моем представлении — это такие же "костыли, вызванные уже несуществующими историческими причинами"
Здравствуйте, McSeem2, Вы писали:
MS>Однако, вынужден заметить, что и в Микрософте все плохо.
Да ты шо?
MS>Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля.
А что, в самом vcproj текстовый guid в текстовом редакторе поменять не судьба?
MS>Самое страшное, что за эти 15 минут успеваешь пережить весь ментальный геморрой со времен большого взрыва! По количеству WTF там 15 минут за 10 миллиардов лет надо считать. Вообще, самое страшное наказание программисту в аду — это вечно настраивать проекты в вижуал-студии.
Извини, но согласиться не могу. Всё там просто и понятно. По крайней мере всё что мне понадобилось ковырять в vcproj ручками я проделывал быстро и без единого WTF.
Здравствуйте, Константин Б., Вы писали:
КБ>Этот весь геморой нужен для того чтобы 32-тные программы работали на 64-битной винде. Причем тут портирование и десятилетие?
Я у себя на 2008R2 вырубил нахрен как виртуализацию реестра так и файловые перенаправления + ограничение в правах для х86 процессов. И только тогда у меня нормально начали работать х86 проги а из Far x86 стало возможно запускать любые проги с полными правами. Far х64 пользоваться невозможно, т.к. под него нет нужных плагинов.
Так что нафиг эти извраты не нужны. У меня без них куда больше софта работает чем с ними.
Здравствуйте, Torie, Вы писали:
C>>Зато позволяют нормально делать циклические ссылки, так как зависимости разрешаются в рантайме загрузчиком. T>Это типа должно быть преимуществом? А по моему, за такие фокусы надо бить лопатой по хлебалу.
Вообще говоря, да. Иногда крайне удобно.
Здравствуйте, Константин Б., Вы писали:
C>>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине. КБ>А 32-битную библиотеку можно загрузить в 64-битный процесс?
Нельзя, конечно.
Был проект, позволявший это делать с ограничениями, но обычно проще выделить 32-битную часть в отдельный процесс.
N>Как сказал Хайнлайн (наверняка упростив какого-то психолога), мы смеёмся, чтобы заглушить душевную боль. Не бывает смешных вещей, в которых кто-нибудь не страдает и нельзя представить себя на его месте. N>Я уже много лет плотно не работаю с Windows, поэтому сам всё это не переживаю. Наверно, поэтому не смеялся. Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами. N>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
На самом деле даже ничего ломать не требовалось — сделали бы system64 для 64хбитных приложений, а system32 оставили с 32хитными длл. С реестром тоже можно было обойтись без этих волшебных перестановок — при помощи симлинок и изменения численного значения HKEY_LOCAL_MACHINE.
Совместимость с уже написанными 32хбитными приложениями осталась бы. А перед тем как портировать приложения на нативные 64 бита всего ничего — пришлось бы поискать захардкоженные в исходном тексте строки system32 И поменять их на system64 или на спец апи типа GetSystemDirectory.
А микрософт решила ввести совершенно новый уровень сложности в ядро винды вместо этого.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Константин Б., Вы писали:
T>>Хуже всего, что "совместимость" от всех этих костылей с путями и перенаправлениями весьма липовая. Я портировал кое-что на 64 бита, и убрать захардкоденные пути для %SYSTEM% (даже если они есть) — это была наименьшая из всех проблем. T>>Решив высосанную из пальца проблему, M$ породил геморрой, который придется тянуть еще не одно десятилетие.
КБ>Этот весь геморой нужен для того чтобы 32-тные программы работали на 64-битной винде. Причем тут портирование и десятилетие? :xz:
Объясни, plz. Вот криво написанная 32-битная программа ищет что-то в %WINDOWS%/system32. DLL'ку там положила, например. Вот 64-битная система, и она же — 32-битная программа — там ничего не находит, потому что то же содержимое лежит в %WINDOWS%/хренЗнаетГде/WOW64. Каким образом этот весь геморрой помогает программе работать в 64-битной системе?;)) (Нет, я читал про всякие тайные подмены путей на ходу. Не надо рассказывать их ещё раз, просто объясни, чем альтернативный вариант с отсутствием таких странных прыжков был бы заведомо хуже.)
Здравствуйте, midcyber, Вы писали:
N>>Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы:)
M>Вот в моем представлении — это такие же "костыли, вызванные уже несуществующими историческими причинами"
Тогда объясни эти исторические причины.:)
В конце концов, в отличие от виндовых путей, тебя никто не обязывает использовать именно make традиционного вида. Есть десятки альтернатив, от просто изменённого синтаксиса до принципиально другого подхода. Но тебя потянуло именно на традиционный make, и ты, не попробовав альтернатив, плюёшься на всех как на него. Зачем?
Здравствуйте, Cyberax, Вы писали:
C>Нафиг он нужен, когда есть CMake, scons или тот же waf?
Все унылое г-но, к сожалению. От того у буста свой Jam, а у ACE свой MPC. CMake неплохо лечит недостатки make, но появился слишком поздно. Собсно, он уже родился устаревшим, поэтому несерьезно его сегодня советовать. Уж лучше Ant/NAnt.
IID>>Прекомпилённые заголовки, которые непойми как работают. Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник). Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win). Это только малая часть. Уж ешьте такое сами. C>Зато позволяют нормально делать циклические ссылки, так как зависимости разрешаются в рантайме загрузчиком.
Циклически можно с помощью стабов собирать и под виндами. Вообще, гоните вы оба, ибо есть флаг --no-undefined. И да, динамические библиотеки в линухах — это вовсе не DLL в виндах, другой принцип загрузки. И да, загрузчик легко и статическую библиотеку в процесс при загрузке прилинковать может, в этом плане и в упомянутом насчет ресолвинга ссылок просто в линухах есть некая консистентность м/у статическими и динамическими либами.
C>>>(без всяких магических перенаправлений). IID>>Перенаправления нужны вовсе не для возможности запуска C>А для чего? Оно нужно из-за того, что куча приложений уже зашили слово "system32" намертво.
Их проблемы, надо было брать значения из реестра, как в доке и сказано.
C>В Линуксе оно нативно вообще может работать.
А вот это как раз из-за недоделанных динамических библиотек в линухах. Имею ввиду, что каждый процесс полностью изолирован от других, и не умеет шарить/маппить память загруженных динамических библиотек. Смешно, но сей недостаток оказался бенефитом для такой гетерогенной среды.
C>Вот я про то и говорю. Чтоб этими 8Гб воспользоваться в 32 бит — нужен enterprise-сервер за кучу денег.
А ими и так, и так нельзя воспользоваться. Никакой 32-битный процесс более 4 гиг не увидит, поэтому на однопользовательской машине с десктопной осью оно и нафиг не облокотилось. Понятно, что юнихи изначально являются серверно-ориентированными осями, где может крутиться несколько "больших" приложений, но и стоят серьезные юнихи подороже виндов-то. Да и в "бесплатном" линухе недалеко все ушло, ибо кто на RedHat сидит (единственная адекватная серверная сборка), по итогам платит не меньше чем за виндовые решения.
Здравствуйте, McSeem2, Вы писали:
MS>Однако, вынужден заметить, что и в Микрософте все плохо. Все гораздо хуже, чем в гмэйке. Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля. Иначе, если просто переименовывать, то нельзя будет сделать из набора проектов sln из за одинаковых гуидов. У студии от такого наступает полный когнитивный диссонанс вплоть до абсолютной недееспособности.
Не понял, почему надо 15 мин на то, чтобы в первых строчках vcproj-файла просто поменять GUID и спокойно добавить его в проект?
Здравствуйте, vdimas, Вы писали:
C>>Нафиг он нужен, когда есть CMake, scons или тот же waf? V>Все унылое г-но, к сожалению. От того у буста свой Jam, а у ACE свой MPC. CMake неплохо лечит недостатки make, но появился слишком поздно. Собсно, он уже родился устаревшим, поэтому несерьезно его сегодня советовать. Уж лучше Ant/NAnt.
LOL! Ты хоть SCons поблизости видел? Ant по сравнению с ним — унылая поделка, заведи тему в КСВ, если хочешь. Подробно объясню почему.
C>>>>(без всяких магических перенаправлений). IID>>>Перенаправления нужны вовсе не для возможности запуска C>>А для чего? Оно нужно из-за того, что куча приложений уже зашили слово "system32" намертво. V>Их проблемы, надо было брать значения из реестра, как в доке и сказано.
Ну так вот и получилось, что system32 содержит 64-битные DLL-ки. А ещё перенаправление Program Files в домашний каталог в Висте — вообще супер.
C>>В Линуксе оно нативно вообще может работать. V>А вот это как раз из-за недоделанных динамических библиотек в линухах. Имею ввиду, что каждый процесс полностью изолирован от других, и не умеет шарить/маппить память загруженных динамических библиотек. Смешно, но сей недостаток оказался бенефитом для такой гетерогенной среды.
Мимо. Я говорю про возможность запуска 64-битных процессов в 32-битной системе. Это делается с помощью специального shim-слоя, переключающего процессор из long mode в protected mode при системных вызовах и переключениях контекста. Причём тут изолированность?
C>>Вот я про то и говорю. Чтоб этими 8Гб воспользоваться в 32 бит — нужен enterprise-сервер за кучу денег. V>А ими и так, и так нельзя воспользоваться. Никакой 32-битный процесс более 4 гиг не увидит, поэтому на однопользовательской машине с десктопной осью оно и нафиг не облокотилось.
А и не надо. У меня сейчас работает 20 приложений на машине, ни одному вообще больше 2Гб не нужно, а все вместе они за 6Гб запросто уходят. Ну и файловый кэш, конечно же, весьма помогает.
Здравствуйте, McSeem2, Вы писали:
MS>А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля.
GUID проекта записан в одном месте .vcproj-файла. Если уж приспичило скопировать .vcproj, то GUID заменяется секунд за 40 в том же FAR. C .sln-ами сложнее, ну так их и компоновать из студии просто — просто добавляешь новые проекты, никакого колдовства.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, MikePetrichenko, Вы писали:
MP>Здравствуйте, Torie, Вы писали:
T>>Послушайте, в этом правда нет ничего сложного.
T>>Все программы находятся там же, в %ProgramFiles%, кроме случаев, когда вам требуется 32-битная версия, которая находится в %ProgramFiles(x86)%, за исключением ситуаций, когда дело касается 32-битной машины, и в этом случае они по-прежнему в %ProgramFiles%.
MP>Не понятный плач какого-то придурка.
Да ладно. Сделано, возможно, и лучшим способом из расчета на максимальную обратную совместимость, но если собрать все факты в один пучок, получается смешно. Будьте оптимистом
V>А ими и так, и так нельзя воспользоваться. Никакой 32-битный процесс более 4 гиг не увидит, поэтому на однопользовательской машине с десктопной осью оно и нафиг не облокотилось.
Здравствуйте, Cyberax, Вы писали:
C>Молча сиди и завидуй как у нас в Линуксе всё классно работает. C>У нас можно: C>1) Запускать 32-битные приложения на 32-битном ядре ...
Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.
Здравствуйте, D. Mon, Вы писали:
C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. C>>У нас можно: C>>1) Запускать 32-битные приложения на 32-битном ядре ... DM>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.
Мимо. Под самым последним ядром у меня запустился древний Debian Woody. Т.е. совместимость ядро<->userland почти идеальная.
С glibc, действительно, есть проблемы. Надо собирать с минимальной её версией — в результате оно всё будет гарантированно работать на будущих версиях (там тоже почти идеальная совместимость).
Как бы, только что купил игрушку "And Yet It Moves" — вполне себе закрытое приложение. Ещё предзаказал "Amnesia: The Dark Descent" — тоже бинарное приложение. А ещё у меня VMWare Player стоит — тоже вполне себе бинарный и коробочный.
Здравствуйте, D. Mon, Вы писали: DM>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится
Хз. В арче ряд пакетов — перепакованные пакеты дебиана/сьюзи/etc. Работают.
Здравствуйте, Геннадий Васильев, Вы писали: ГВ>GUID проекта записан в одном месте .vcproj-файла. Если уж приспичило скопировать .vcproj, то GUID заменяется секунд за 40 в том же FAR. C .sln-ами сложнее, ну так их и компоновать из студии просто — просто добавляешь новые проекты, никакого колдовства.
Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
Здравствуйте, Cyberax, Вы писали: C>waf
Кстати, а чем он лучше сконса и что, кроме С/С++ умеет собирать искаропки? А то сайт как-то на этот счет скрытничает.
Здравствуйте, Mr.Cat, Вы писали:
ГВ>>GUID проекта записан в одном месте .vcproj-файла. Если уж приспичило скопировать .vcproj, то GUID заменяется секунд за 40 в том же FAR. C .sln-ами сложнее, ну так их и компоновать из студии просто — просто добавляешь новые проекты, никакого колдовства. MC>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
Хм. Если проект новый, то его гуид ещё никому не известен, следовательно, исправлять какие бы то ни было дополнительные ссылки при копировании .vcproj нет никакой необходимости. Ну а со ссылками изнутри проекта та же история, что и с любыми другими — если в исходном .vcproj они есть, то их либо надо исправлять (но тогда их придётся исправлять в любом случае), либо не надо (тогда и проблемы нет).
Да и вообще — проблемы студии в данном случае значения не имеют. А если проекты ссылаются друг на друга циклическим порядком — так ССЗБ.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Mr.Cat, Вы писали:
C>>waf MC>Кстати, а чем он лучше сконса и что, кроме С/С++ умеет собирать искаропки? А то сайт как-то на этот счет скрытничает.
Ну я как-то давно в waf даже контибьютил немного. В целом:
1) Более правильная внутренняя структура и трекинг целей.
2) Более быстрый. Намного более быстрый.
3) Более удобный.
Пожалуй, один минус в том, что для scons есть больше готовой интеграции. Хотя всё равно не так много как хотелось бы.
На waf из крупных проектов сейчас перешла Samba4 — там все ему очень рады.
PS: давно хочу что-то типа SCons/waf с нормальным трекингом зависимостей для Java. А нету
Здравствуйте, Mr.Cat, Вы писали:
MC>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.
Здравствуйте, master_of_shadows, Вы писали:
V>>А ими и так, и так нельзя воспользоваться. Никакой 32-битный процесс более 4 гиг не увидит, поэтому на однопользовательской машине с десктопной осью оно и нафиг не облокотилось.
__>Здрасте я ваша тётя. 640кб хватит всем?
Здравствуйте, vdimas, Вы писали:
MC>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто. V>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.
ROTFL!
Здравствуйте, Cyberax, Вы писали:
DM>>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО. C>Мимо. Под самым последним ядром у меня запустился древний Debian Woody. Т.е. совместимость ядро<->userland почти идеальная.
А обратно? В винде я под семеркой собираю прогу, и она запускается в более старых виндах. А собранная в линуксе с ядром 2.6.чего-то простенькая консольная утилита не запускается под 2.6.другое-чего-то (более раннее), ругаясь на неподходящее ядро.
Здравствуйте, D. Mon, Вы писали:
C>>Мимо. Под самым последним ядром у меня запустился древний Debian Woody. Т.е. совместимость ядро<->userland почти идеальная. DM>А обратно? В винде я под семеркой собираю прогу, и она запускается в более старых виндах. А собранная в линуксе с ядром 2.6.чего-то простенькая консольная утилита не запускается под 2.6.другое-чего-то (более раннее), ругаясь на неподходящее ядро.
И обратно тоже. От ядра зависимость будет только если ты используешь какие-то специфичные вызовы, которые есть в новых ядрах, но нет в старом. Точно так же, как и новый API из Vista не будет на WinXP работать.
Основная проблема — с glibc, но она обходится рядом способов: сборкой на старой glibc или использованием автономных dietlibc/uclibc.
Здравствуйте, Cyberax, Вы писали:
C>И обратно тоже. От ядра зависимость будет только если ты используешь какие-то специфичные вызовы, которые есть в новых ядрах, но нет в старом. Точно так же, как и новый API из Vista не будет на WinXP работать.
Видимо, такие вызовы есть в glibc. Ибо столкнулся с этим, когда статически с ним слинковал и пытался запустить на более старой системе. Та же программа, собранная тем же компилятором (окамла) на третьей системе, заработала нормально, т.е. в исходной программе/компиляторе привязки к новым фичам ядра не было.
C>Основная проблема — с glibc, но она обходится рядом способов: сборкой на старой glibc или использованием автономных dietlibc/uclibc.
Здравствуйте, D. Mon, Вы писали:
C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. C>>У нас можно: C>>1) Запускать 32-битные приложения на 32-битном ядре ... DM>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.
Что есть "система" в данном случае? Я спокойно запускаю коробочный Oracle на коробочных RHEL и SLES.
Там, где действительно нужна коробочность:) — оно может быть сделано без проблем.
Конечно, если наивно посмотреть со стороны — кошмар! сотни дистрибутивов!
Мы на самом деле имеем дело с результатом — винды, офисы, а почему они стали именно такими, не знаем.
Я уже давно не ругаюсь на MS, благодаря очень познавательному блогу:
Здравствуйте, D. Mon, Вы писали:
DM>>>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО. C>>Мимо. Под самым последним ядром у меня запустился древний Debian Woody. Т.е. совместимость ядро<->userland почти идеальная. DM>А обратно? В винде я под семеркой собираю прогу, и она запускается в более старых виндах. А собранная в линуксе с ядром 2.6.чего-то простенькая консольная утилита не запускается под 2.6.другое-чего-то (более раннее), ругаясь на неподходящее ядро.
Начнём с того, что в 2.6 сейчас где-то 4 версии 3-го уровня на год. То есть между 2.6.18 и 2.6.32 разница в 3.5 года. И развитие за это время прошло колоссальное. Между тем ещё год назад большинство коммерчески значимых дистрибутивов опирались на 2.6.18 и 2.6.27; это уже вопрос предпочтений стабильности ABI и содействия авторам драйверов. Сейчас основная опорная линия — 2.6.32 и скорее всего на нём и стабилизируются на пару лет.
Далее, ругань на неподходящее ядро идёт от glibc. Glibc в распространённых дистрибутивах всё равно имеет множество специфики, и перетащить под более старую версию может не пойти не только по ядру.
Это основные факторы. Перефразируя твои жалобы, никто явно не заботится о том, чтобы результат сборки работал на более ранних версиях, неважно уж почему такое потребовалось и что этому мешает. Да, это так. Более того, были дистрибутивы, в которых пытались идти таким путём. Обнаружилось, что это (на тот момент) было никому массово нафиг не нужно. Я не хочу делать из этого каких-то глобальных философских выводов. В принципе, мне это не нравится — подход Windows действительно более адекватен задаче обеспечения совместимости работы на разных версиях и даже сборке под старые версии. Осталось понять, насколько это реально нужно...
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, IID, Вы писали:
C>>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. IID>>Буквально на днях портировал виндовый код в линукс, обзавидовался блин. Г(ов)НО-мейк (GNU make), г-ениальный парсер которого (родом из 70х годов) в качестве отступов желает видить табы, а не пробелы это просто песня. Видимо корректный парсинг это rocket siense в мире линупс.
N>Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки.
Так, а теперь включаем логику. Если парсер, в качестве разделителей, станет воспринимать ещё и пробелы, это никак не сломает обратную совместимость. Зато будет работать ожидаемо. А не через жопу.
N>Внимание, вопрос: зачем тратиться ради ламеров?
Именно так, зачем тратить своё время на ламерские гнутые поделия.
IID>> Прекомпилённые заголовки, которые непойми как работают.
N>Наверно, надо тоже что-то почитать?
Прочёл, сделал. Прекомпилированный заголовок создался. А вот бинарник — нет. После часа гугления я выкинул их нахер. Кстати, вот забавная строчка из документации, к которой ты так упорно меня отсылаешь:
Caution: There are a few known situations where GCC will crash when trying to use a precompiled header. If you have trouble with a precompiled header, you should remove the precompiled header and compile without it.
IID>> Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник).
N>Приведи пример зубодробительности.
Нагромождение символов в конце последней строки это унылый пипец.
IID>> Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win).
N>И чем же они похожи на статические?
Тем что резолвинг внешних ссылок разрешает загрузчик, а не линкер. Фактически луноходный загрузчик выполняет работу линкера.
IID>> Это только малая часть. Уж ешьте такое сами.
N>Вот скажи мне, мил человек — почему я не испытываю со всем этим существенных проблем?
Привычка великая сила. Да и каждый кулик всегда своё болото хвалит.
N>Может, потому, что иногда таки преодолеваю лень и пытаюсь понять, как оно устроено и почему?
Меня больше устраивает вариант "оно просто работает". Вместо того чтобы потаться понять "почему не работает" и "ща посмотрим как оно устроено, чтобы понять почему не работае".
N>А ты настолько повторил стандартные жалобы ламеров, которые ни странички не прочитали про программирование под Unix, что аж скучно до зевоты.
Чего-ж влез, раз скучно ? Кстати, типичная отмазка луноходов, уже неоднократно слышал от fk0 такое. Отмахиваться от досадных проблем и неудобств если они некрупные и существуют воркараунды и всяческие стояния раком (типа табов вместо пробелов) которые позволяют грабли обходить.
N>Ладно бы ещё вспомнил реальные проблемы, было бы видно, что человек постарался и что-то понял.
Для меня эти проблемы достаточно реальны. То, что есть более вырвиглазные проблемы я знаю. Но сам не сталкивался, и не горю желаением.
N>Но вместо этого — фонтан эмоций. Фу.
Фу это линух. Бо говно.
Особенно меня бесят программы, которые во время своей установки решают, что они офигенно круты, и поэтому они повсюду размещают свои ярлыки, чтобы быть уверенными, что вы абсолютно точно не пропустите самую крутую и удивительную прогу, которая когда-либо была написана в истории человечества. Они записываю себя в меню Пуск, в часто используемые программы, в быстрый запуск, на рабочий стол, они заменяют ваши ассоциации, они перехватывают автозапуск дисков, они устанавливают вашу домашнюю страницу на свой сайт, они даже добавляют иконку в трей на случай, если вы умудрились как-то пропустить все другие места — и каждый раз, когда вы запускаете эту программу, она идёт и пересоздаёт все эти ярлычки на случай, если вы "случайно их потеряли".
Он тока про один ньюанс забыл : сама мелкософт со своими прогами ведет себя ровно также
Здравствуйте, McSeem2, Вы писали:
MS>С этим вполне согласен. Гмэйком (и вообще мэйком) пользоваться невозможно. Нужен генератор этих мэйков или авто-билды. Вообще, это просто проблема тяжелого наследия времен железобетонных игрушек и экономии на спичках. Но она есть, да.
MS>Однако, вынужден заметить, что и в Микрософте все плохо. Все гораздо хуже, чем в гмэйке. Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля. Иначе, если просто переименовывать, то нельзя будет сделать из набора проектов sln из за одинаковых гуидов. У студии от такого наступает полный когнитивный диссонанс вплоть до абсолютной недееспособности. Но 15 минут времени — это не самое страшное. Самое страшное, что за эти 15 минут успеваешь пережить весь ментальный геморрой со времен большого взрыва! По количеству WTF там 15 минут за 10 миллиардов лет надо считать. Вообще, самое страшное наказание программисту в аду — это вечно настраивать проекты в вижуал-студии.
Я даже больше скажу, переименование проекта с какими-то там правками внутри файлов в Far-е это тоже извращение.
Почему в других нормальных программах, если мне нужно быстро создать проект я не должен ковыряться внутри их дерьма и править какието там гребаные гуиды на которые мне как пользователю класть с ... чтобы быстро создать проект?
Это ведь и есть тот самый ублюдский юзабилити, когда плоскогубцами и молотком оказывается работать проще чем с интерфейсом созданным СПЕЦИАЛЬНО для этой работы.
Да ладно когда сам мучаешься, но смешно наблюдать когда рассказываешь новичку, что для создания проекта можно 15 минут подрочить мышой, а можно скопировать и чтото-там ручками править, и главное не забыть вот ето ето и ето и не ошибиться тут и тут а то!!!111 и он смотрит на тебя как на дибила! А ведь правильно смотрит!
МС сделали заготовки мастеров для своих библиотек типа MFC, однако то, что написать даже примитивный стенд для работы не подключив кучу местных библиотек, не настроив зависимости и прочую муть — невозможно.
Нехватает по идее обычной функции построителя шаблона.
Я знаю что можно писать свои мастера и тд и тп, но там черт ноги поломает.
Человеки! Кто знает способ набросать быстро набор своих мастеров в VS для создания проектов без недельных разбирательств в теории и реверсе студийных скриптов?
Требуется быстро создавать одним кликом несколько типов проектов, где уже добавлены заранее забитые гвоздями библиотеки, их зависимости, и пара тройка файлов с вариациями содержимого в зависимости от галок на панели.
Век не забуду кто поможет
Здравствуйте, IID, Вы писали:
C>>>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. IID>>>Буквально на днях портировал виндовый код в линукс, обзавидовался блин. Г(ов)НО-мейк (GNU make), г-ениальный парсер которого (родом из 70х годов) в качестве отступов желает видить табы, а не пробелы это просто песня. Видимо корректный парсинг это rocket siense в мире линупс.
N>>Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки.
IID>Так, а теперь включаем логику. Если парсер, в качестве разделителей, станет воспринимать ещё и пробелы, это никак не сломает обратную совместимость. Зато будет работать ожидаемо. А не через жопу.
Во-первых, понятие "ожидаемо" здесь совершенно сомнительно. Я вот ожидаю, что будет работать по документации, в которой сказано — ожидать tab. А чего ты ожидаешь? Что оно будет работать от пробела? А почему?
Во-вторых, любое такое расширение сомнительно тем, что его использование не будет переноситься на другие флаворы. Например, перестанет работать под BSD make. А теперь см. выше про синхронность действий вендоров.
N>>Внимание, вопрос: зачем тратиться ради ламеров? IID>Именно так, зачем тратить своё время на ламерские гнутые поделия.
Ну так зачем ты тратил время и нервы на него, а потом ещё и писал сюда об этом? Ты же первый начал эту подветку — своим рассказом "ах, какой плохой make". При том, что:
* тебя никто не заставлял его использовать (есть куча альтернатив)
* ты не прочитал документацию средства, которое было разработано в другом мире с другими традициями и стилем
Не хочешь gmake? Почему ты заранее не спросил "а что есть нет такое кошмарное"? Мне он тоже не нравится, хотя проще всего таки его взять. Но это мне, я "в системе" уже более 10 лет. Спроси вначале, а не плачься в конце.
Тут в форме ответа есть замечательная ссылка "Как правильно задавать вопросы". Но почему-то никто не хочет пока сказать, что это должно распространяться и на другие виды постингов, и в первую очередь вот на такие плачи и скрежеты зубовные.
IID>>> Прекомпилённые заголовки, которые непойми как работают. N>>Наверно, надо тоже что-то почитать? ;)
Угу. info gcc.
IID>Прочёл, сделал. Прекомпилированный заголовок создался. А вот бинарник — нет. После часа гугления я выкинул их нахер. Кстати, вот забавная строчка из документации, к которой ты так упорно меня отсылаешь: IID>
IID>Caution: There are a few known situations where GCC will crash when trying to use a precompiled header. If you have trouble with a precompiled header, you should remove the precompiled header and compile without it.
Ну так эта фича ещё не была в релизном статусе, насколько я помню.
IID>>> Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник). N>>Приведи пример зубодробительности. IID>
IID>Нагромождение символов в конце последней строки это унылый пипец.
Ну и. Опять-таки, читай документацию. $@ это target. $^ это все зависимости. Тебе не нравится? Предложи, как это стоило бы лучше назвать — причём "лучше" не только для того, кто читает makefile впервые, но и для того, кто им систематически пользуется. Вот у BSD make есть алиасы типа ${.TARGET}, но никто не требует их массово использовать.
IID>>> Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win). N>>И чем же они похожи на статические? IID>Тем что резолвинг внешних ссылок разрешает загрузчик, а не линкер. Фактически луноходный загрузчик выполняет работу линкера.
Да, динамические ссылки разрешаются при загрузке. Это имеет ряд существенных преимуществ (или недостатков, кому как). Например, я могу заменить некоторые библиотеки целиком или отдельные символы из них; установкой preload'а библиотек поменять стиль работы приложения. Это недостаток или преимущество? Для среды, в которой надо прилагать страшные усилия для защиты от вирусов — недостаток. Для среды, которая предполагает удобство управления и администрирования — скорее преимущество.
IID>>> Это только малая часть. Уж ешьте такое сами. N>>Вот скажи мне, мил человек — почему я не испытываю со всем этим существенных проблем? IID>Привычка великая сила. Да и каждый кулик всегда своё болото хвалит.
"Ты так сказал, как будто в этом есть что-то плохое" (tm). Да, привычка великая сила. И кто сказал, что это плохо? Привычка позволяет сосредоточиться на главном, не отвлекаясь на всяческие глупости.
Кто кому кулик — мне неинтересно. Я знаю, что Unix меня отлично кормит и помогает решать множество задач лучше, чем это бы делала Windows. Например, мы влёгкую решаем задачи, для которых в случае Windows потребовалось двухнедельное бдение почти без сна тридцати опытных инженеров Microsoft, и то они потом сказали, что результат штучный и повторить не могут:) А мы делаем прямолинейно и без напряга, и результат повторяем. Подробнее рассказать не могу — NDA — но уж поверь, такой случай был и всё ещё актуален. Думаю, кто-то найдёт и обратный пример — ну и флаг ему в руки.
N>>Может, потому, что иногда таки преодолеваю лень и пытаюсь понять, как оно устроено и почему? IID>Меня больше устраивает вариант "оно просто работает". Вместо того чтобы потаться понять "почему не работает" и "ща посмотрим как оно устроено, чтобы понять почему не работае".
N>>А ты настолько повторил стандартные жалобы ламеров, которые ни странички не прочитали про программирование под Unix, что аж скучно до зевоты. IID>Чего-ж влез, раз скучно ?
Так ты ж в другую ветку влез.
IID> Кстати, типичная отмазка луноходов, уже неоднократно слышал от fk0 такое.
"Луноходы" это юниксоеды? Тогда ты зря fk0 причисляешь. И зачем обобщать? Я это одно, fk0 другое, Cyberax третье, и так далее. Твоя попытка обобщения совершенно разных людей с разными занятиями и разным опытом как "луноходов" показывает то, что ты не желаешь вникать в суть и ограничиваешься поверхностным сканом. Ну так и результаты будут соответствующие — полное непонимание и плачи на жизнь.
IID> Отмахиваться от досадных проблем и неудобств если они некрупные и существуют воркараунды и всяческие стояния раком (типа табов вместо пробелов) которые позволяют грабли обходить.
Конечно. Потому что идеальной системы, увы, нет. Работаем на том, что есть. Сейчас и надолго вперёд меня Unix устраивает в разы больше. Как сказал Бутенко, любить надо женщин, а с компьютерами — работать.
N>>Но вместо этого — фонтан эмоций. Фу. IID>Фу это линух. Бо говно. :)
Ну за такую реплику, извини, таки минус. Ибо нефиг.
Здравствуйте, unreg_flex, Вы писали:
_>Почему в других нормальных программах, если мне нужно быстро создать проект я не должен ковыряться внутри их дерьма и править какието там гребаные гуиды на которые мне как пользователю класть с ... чтобы быстро создать проект?
Не создать а склонировать готовый.
Тыб разобрался о чём речь идёт прежде чем заводиться и забрызгивать тут всё.
Новый проект в той же вижле делается в пару кликов. А топикстартеру надо копия уже готового проекта рядом с оригиналом. Всё что для этого надо — поменять 1 параметр в XML. А крику...
_>Да ладно когда сам мучаешься, но смешно наблюдать когда рассказываешь новичку, что для создания проекта можно 15 минут подрочить мышой, а можно скопировать и чтото-там ручками править, и главное не забыть вот ето ето и ето и не ошибиться тут и тут а то!!!111 и он смотрит на тебя как на дибила! А ведь правильно смотрит!
Угу. Ведь он знает способ куда проще, чем тот идиотизм, который ему впрягают.
_>Требуется быстро создавать одним кликом несколько типов проектов, где уже добавлены заранее забитые гвоздями библиотеки, их зависимости, и пара тройка файлов с вариациями содержимого в зависимости от галок на панели. _>Век не забуду кто поможет
Есть в недрах MSVS такой забавный скрипт default.js, в котором описаны defaults для вижуаловских проектов.
Здравствуйте, Cyberax, Вы писали:
C>PS: давно хочу что-то типа SCons/waf с нормальным трекингом зависимостей для Java. А нету
чем не устраивает maven?
сам сейчас сижу на bash + maven но это уже не система сборки, а мего нечто для деплоймента из нечего во всё и все места автоматом в одно касание из интернета, отладки, профилирования, тестирования итд.
Здравствуйте, dotidot, Вы писали:
C>>PS: давно хочу что-то типа SCons/waf с нормальным трекингом зависимостей для Java. А нету D>чем не устраивает maven?
Нету трекинга зависимостей. Т.е. maven просто тупо берёт и последовательно запускает плугины, даже если не изменилось то, что плугин должен обработать.
D>сам сейчас сижу на bash + maven но это уже не система сборки, а мего нечто для деплоймента из нечего во всё и все места автоматом в одно касание из интернета, отладки, профилирования, тестирования итд.
Я тоже использую Maven.
Здравствуйте, Nik_1, Вы писали:
N_>Он тока про один ньюанс забыл : сама мелкософт со своими прогами ведет себя ровно также
Да, так и есть, по крайней мере один из разработчиков MS Реймонд Чен, бывает, критикует подходы своего же работодателя. Остановите это безумие: подпапки в Моих документах
И примеры демонстрирует на паскале (дельфи).
Забавно, правда?
Здравствуйте, Skleroz, Вы писали:
S>Да, так и есть, по крайней мере один из разработчиков MS Реймонд Чен, бывает, критикует подходы своего же работодателя. S>Остановите это безумие: подпапки в Моих документах S>И примеры демонстрирует на паскале (дельфи). S>Забавно, правда?
Ну строго говоря, Чен свои примеры на С пишет. Это переводчик переводит его не только с английского на русский, но и с С на паскаль (блог вообще дельфи посвящен).
Здравствуйте, CreatorCray, Вы писали:
CC>Тыб разобрался о чём речь идёт прежде чем заводиться и забрызгивать тут всё. CC>Новый проект в той же вижле делается в пару кликов. А топикстартеру надо копия уже готового проекта рядом с оригиналом. Всё что для этого надо — поменять 1 параметр в XML. А крику...
Я знаю что новый проект делается в пару кликов, только такой проект нафиг несдался, мне нужно создавать sln на основе существующих, чтобы опции компиляции стояли какие нужно, было подключено куча дополнительных проектов, настроены зависимости и тп. Это тоже делается в пару кликов?
Если же править ручками в фаре то поменять нужно далеко не 1 параметр, надо залезть в sln, потом в vcproj и там и там переименовать проект и гуид, кроме того нужно переименовать сами файлы проекта и решения, потом загрузить полученный клон в ИДЕ, убедиться что зависимости какого-то буя сбросились и выставлять их заново.
CC>Угу. Ведь он знает способ куда проще, чем тот идиотизм, который ему впрягают.
Я впрягаю как раз способ с фаром, ибо это действительно быстрее чем создать проект в "пару кликов" как расписал выше.
А удивление вызывает как раз именно ручная правка каких-то там файлов IDE вместо выполнения команд.
CC>Есть в недрах MSVS такой забавный скрипт default.js, в котором описаны defaults для вижуаловских проектов.
В недрах моей MSVS 53 таких скрипта, и какой из них тот самый?
Потыкал справку на эту тему, там как я и говорил целый раздел на тему как создавать собственные мастера, чтобы реально было в пару кликов, только вот раскопать все это и написать свой мастер наверно неделя нужна, учитывая еще что с JS я не знаком и тем более не знаком с API JS для создания мастеров, а так да, в пару кликов.
А всего то нужна команда в IDE — "создать шаблон проекта/решения по существующему".
Здравствуйте, unreg_flex, Вы писали:
_>Я знаю что новый проект делается в пару кликов, только такой проект нафиг несдался, мне нужно создавать sln на основе существующих, чтобы опции компиляции стояли какие нужно, было подключено куча дополнительных проектов, настроены зависимости и тп. Это тоже делается в пару кликов?
Это делается один раз в default.js и после чего все новые проекты создаются уже настроенными.
_>Если же править ручками в фаре то поменять нужно далеко не 1 параметр, надо залезть в sln, потом в vcproj и там и там переименовать проект и гуид
Зачем? Ты ж делаешь копию готового проекта. Поменяй имя и гуид в vcproj копии и добавь его в solution. Вижла сама всё что надо в sln пропишет.
Я от большой лени как то так и сделал, когда надо было в одном и том же solution за один билд одновременно собирать и х64 и х86 версию одного из проектов чтоб потом положить их в MSI. И всё осталось на месте, все refs и т.п.
_> кроме того нужно переименовать сами файлы проекта и решения, потом загрузить полученный клон в ИДЕ, убедиться что зависимости какого-то буя сбросились и выставлять их заново.
Это всё потому, что делал неправильно. Не надо было в sln ничего ковырять.
CC>>Угу. Ведь он знает способ куда проще, чем тот идиотизм, который ему впрягают. _>Я впрягаю как раз способ с фаром, ибо это действительно быстрее чем создать проект в "пару кликов" как расписал выше. _>А удивление вызывает как раз именно ручная правка каких-то там файлов IDE вместо выполнения команд.
CC>>Есть в недрах MSVS такой забавный скрипт default.js, в котором описаны defaults для вижуаловских проектов. _>В недрах моей MSVS 53 таких скрипта, и какой из них тот самый?
А по пути посмотреть?
Например вот: Visual Studio 9.0\VC\VCWizards\AppWiz\Generic\Application\scripts\1033\default.js
_>Потыкал справку на эту тему, там как я и говорил целый раздел на тему как создавать собственные мастера, чтобы реально было в пару кликов, только вот раскопать все это и написать свой мастер наверно неделя нужна
Не ну конечно быстрее каждый раз матюгаясь возюкаться вручную чем потратить несколько умственных усилий и сделать несколько внятно сформулированных поисковых запросов в гугл.
_> учитывая еще что с JS я не знаком и тем более не знаком с API JS для создания мастеров, а так да, в пару кликов.
Там всё просто. Кода мизер. Имея под рукой гугл задача решаема.
Я под себя за полчаса в своё время стандартные С++ проекты переточил. Отдельный мастер не делал, поменял готовые.
_>А всего то нужна команда в IDE — "создать шаблон проекта/решения по существующему".
Для решения этой задачи в общем случае гемору авторам такой команды будет предостаточно.
Но можно написать в спортлото^W саппорт вижуалки feature request, и глядишь в MSVS2012 добавят.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vdimas, Вы писали:
C>>>Нафиг он нужен, когда есть CMake, scons или тот же waf? V>>Все унылое г-но, к сожалению. От того у буста свой Jam, а у ACE свой MPC. CMake неплохо лечит недостатки make, но появился слишком поздно. Собсно, он уже родился устаревшим, поэтому несерьезно его сегодня советовать. Уж лучше Ant/NAnt. C>LOL! Ты хоть SCons поблизости видел? Ant по сравнению с ним — унылая поделка, заведи тему в КСВ, если хочешь. Подробно объясню почему.
Да, на scons подробно не смотрел, но если парой строк чиркнешь почему он, было бы неплохо.
C>Ну так вот и получилось, что system32 содержит 64-битные DLL-ки. А ещё перенаправление Program Files в домашний каталог в Висте — вообще супер.
Я имел ввиду, что в этом случае можно было бы легко сделать system64 для либ, соответствующей разрядности. Более того, т.к. 64-битная винда появилась уже после изобретения манифестов, управляющих загрузчиком, можно было ввести обязательное требование устанавливать только подписанные манифестом 64-бит DLL-ки, и соотв. ссылки на либы тоже через embedded manifest, в этом случае подобных вопросов не стояло бы вообще, где эти либы хранить. А так зачем-то перетянули DLL-hell из прошлого века в новые ОСи.
Кстати, стоит заметить, что там, где используется манифест сейчас (например, у нас в продуктах все либы подписаны), проблема не стоит вообще, как для 32-бит, так и для 64-бит, и система ложит либы не в system32, а в специальный каталог, с которым только она и разбирается (GAC). Еще пример: я как-то для Open SSL делал собственную сборку под винды, ибо зачастую у клиентов вяляется прямо в system32 неподписанные DLL-ки от неизвестной мне версии Open SLL, со всеми вытекающими потенциальными конфликтами, возникающими в случае, если мы будем поставлять продукт со другими версиями тех же либ без подписи.
В общем, мое мнение таково, что если MS VC давно уже по-умолчанию умеет ембеддить манифест в компилируемые либы, обсуждаемый вопрос не столь актуален. И даже не принципиально, как они обозвали "песочницу" для 32-битных приложений, для эмуляции DOS-а в свое время тоже было сделана масса допущений, никто не возмущался.
C>Мимо. Я говорю про возможность запуска 64-битных процессов в 32-битной системе. Это делается с помощью специального shim-слоя, переключающего процессор из long mode в protected mode при системных вызовах и переключениях контекста. Причём тут изолированность?
При том, что винды мапят память загруженного образа DLL или exe-шников на все процессы, их использующие, экономя физическую память. Это относится и к DLL-кам ядра. Насчет линухов я имел ввиду, что одна и та же загруженная *.so может быть уникальна после загрузки, в зависимости от настройки окружения в момент загрузки (напомню, там можно даже статические либы подгружать и ресолвить ссылки). Понятное дело, что функциональность маппинга отличается для win-x64, что в любом случае требует дополнительно всей инфраструктуры x64, включая DLL-ки ядра (ибо АПИ для 64-бит изменилось). Собственно, всё это и предоставляется 64-битной осью. Как раз там есть "слои", переключающие процессор м/у указанными тобой режимами.
Единственно что реально плохо, в сравнении с поддержкой 64-бит на 32-бит (у виндов поддержка наоборот), это дрова, да... все дрова "идут с 0-ля". Но, ИМХО, это опять же экономии ради, чтобы не держать в памяти фактически две копии ядра, предназначенные для разных режимов.
C>А и не надо. У меня сейчас работает 20 приложений на машине, ни одному вообще больше 2Гб не нужно, а все вместе они за 6Гб запросто уходят. Ну и файловый кэш, конечно же, весьма помогает.
20 "прожорливых" приложений на клиентской машине? Небось среди них и SQL и прочие сервера есть, даже небось всякие тырнетные прокси? Дык, поставь себе еще одну серверную коробку для подобного хозяйства. Кстати, замечал интересную фичу, у меня апдейт с SVN гораздо быстрее выполняется на машине, подключенной к домашнему прокси, чем на самом прокси. Хотя, казалось бы, задержки у прокси должны быть меньше, ибо непосредственно в глобальную сеть воткнутый, да и комп там чуть мощнее...
Здравствуйте, vdimas, Вы писали:
C>>LOL! Ты хоть SCons поблизости видел? Ant по сравнению с ним — унылая поделка, заведи тему в КСВ, если хочешь. Подробно объясню почему. V>Да, на scons подробно не смотрел, но если парой строк чиркнешь почему он, было бы неплохо.
В ant/nant нет нормального трекинга зависимостей. Scons/waf при работе строят граф зависимостей всех целей, так что это позволяет минимизировать работу по перестройке.
C>>Ну так вот и получилось, что system32 содержит 64-битные DLL-ки. А ещё перенаправление Program Files в домашний каталог в Висте — вообще супер. V>Я имел ввиду, что в этом случае можно было бы легко сделать system64 для либ, соответствующей разрядности. Более того, т.к. 64-битная винда появилась уже после изобретения манифестов, управляющих загрузчиком, можно было ввести обязательное требование устанавливать только подписанные манифестом 64-бит DLL-ки, и соотв. ссылки на либы тоже через embedded manifest, в этом случае подобных вопросов не стояло бы вообще, где эти либы хранить. А так зачем-то перетянули DLL-hell из прошлого века в новые ОСи.
Манифест — это не решение. Это просто способ ссылаться на конкретную DLL. WinSxS — это уже очередной слой хаков.
C>>Мимо. Я говорю про возможность запуска 64-битных процессов в 32-битной системе. Это делается с помощью специального shim-слоя, переключающего процессор из long mode в protected mode при системных вызовах и переключениях контекста. Причём тут изолированность? V>При том, что винды мапят память загруженного образа DLL или exe-шников на все процессы, их использующие, экономя физическую память. Это относится и к DLL-кам ядра. Насчет линухов я имел ввиду, что одна и та же загруженная *.so может быть уникальна после загрузки, в зависимости от настройки окружения в момент загрузки (напомню, там можно даже статические либы подгружать и ресолвить ссылки).
Представь себе, в Линуксе всё ровно так же. Один и тот же исполняемый образ отображается в несколько процессов, в случае конфликта в адресном пространстве — делается релокация. Ровно как в Винде.
А для 64-бит в Линуксе вообще почти все исполняемые файлы — PIC'и (Position Independent Code). Т.е. им пофиг куда быть загруженным, даже релокации не надо делать.
V>Единственно что реально плохо, в сравнении с поддержкой 64-бит на 32-бит (у виндов поддержка наоборот), это дрова, да... все дрова "идут с 0-ля". Но, ИМХО, это опять же экономии ради, чтобы не держать в памяти фактически две копии ядра, предназначенные для разных режимов.
Как раз в случае 64-бит на 32-битах — ядро работает в 32-битном режиме, и все драйвера тоже. В 64-битном режиме работают только приложения.
C>>А и не надо. У меня сейчас работает 20 приложений на машине, ни одному вообще больше 2Гб не нужно, а все вместе они за 6Гб запросто уходят. Ну и файловый кэш, конечно же, весьма помогает. V>20 "прожорливых" приложений на клиентской машине? Небось среди них и SQL и прочие сервера есть, даже небось всякие тырнетные прокси?
Нет. IDEA, пара моих отлаживаемых приложений, несколько OpenOffice'ов, браузер, PostgreSQL (локальный намного удобнее), и ещё куча всего.
V>Дык, поставь себе еще одну серверную коробку для подобного хозяйства. Кстати, замечал интересную фичу, у меня апдейт с SVN гораздо быстрее выполняется на машине, подключенной к домашнему прокси, чем на самом прокси. Хотя, казалось бы, задержки у прокси должны быть меньше, ибо непосредственно в глобальную сеть воткнутый, да и комп там чуть мощнее...
Прокси мне нафиг не сдался. Подключение к Инету у меня — 100Мбит (реальные).
Здравствуйте, Torie, Вы писали:
T>Все эти библиотеки, DLL, по-прежнему находятся в %SystemRoot%\System32, просто теперь они 64-битные. Ну а 32-битные, они вот, в %SystemRoot%\SysWOW64. Вы ещё следите за объяснением? Да, а 16-битные всё так же хранятся в %SystemRoot%\System – перемещать их в иное место было бы странным.
Про 16-битные — гонево. Их в 64-битной винде нет.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Добавлю что на 64 битную систему нужно ставить всегда 64 битные приложения. Или когда нет — 32 битные. Или как в случае с неизвестным никому продуктом microsoft biztalk server нужно ставить обе версии и 64 и 32 битную, иначе просто не заработает.
А если вы собираете приложение, которое хотите ставить и на 64 и на 32 бита, то вам хорошо бы иметь две машины, потому как продукты типа sharepoint не ставят runtime и библиотеки для альтернативной платформы.
И если вы вдруг решили сделать инсталлятор используя Setup project, то обязательно поставьте соответствующее свойство говорящее, что ваше приложение будет ставиться на 64 битной системе, хотя при этом в инстяллаторе для 64 битной системе вы не сможете использовать 64 битные custom actions, потому что инсталлятор запускается как 32 битный процесс.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>Добавлю что на 64 битную систему нужно ставить всегда 64 битные приложения. Или когда нет — 32 битные.
На слегка настроеную — пофигу. Что 64 что 32 будут работать одинаково.
VV>И если вы вдруг решили сделать инсталлятор используя Setup project, то обязательно поставьте соответствующее свойство говорящее, что ваше приложение будет ставиться на 64 битной системе, хотя при этом в инстяллаторе для 64 битной системе вы не сможете использовать 64 битные custom actions, потому что инсталлятор запускается как 32 битный процесс.
WiX, 64битная прога, туева хуча 64битных custom actions — всё работает.
remove — Erases elements in a list that match a specified value.
erase — Removes an element or a range of elements in a list from specified positions.
T>Ну то есть я вообще не понимаю, из-за чего люди так волнуются по поводу этого всего
Здравствуйте, vladimir.vladimirovich, Вы писали:
CC>>На слегка настроеную — пофигу. Что 64 что 32 будут работать одинаково. VV>Так уж и одинаково?
Имеют одинаковые права, видят одинаковый реестр, файлы и системные потроха.
У меня после настройки работает именно так.
VV>Ты в душе не линуксойд — ы?
Неа. Вообще ни разу.
VV> Про wix-то всяко знаем, только каким боком он вдруг вылез?
Не знаю про какой ты Wix, но я про тот, что генерит пакеты для Microsoft Installer
Здравствуйте, CreatorCray, Вы писали:
CC>Имеют одинаковые права, видят одинаковый реестр, файлы и системные потроха. CC>У меня после настройки работает именно так.
И что ты мне про свою настройку рассказываешь? Я спрашивал как у тебя настроено? Russian Software Developer Network, а не вася пупкин Localhost\Administrator.
CC>Неа. Вообще ни разу.
А отвечаешь в лучших традициях LOR.
VV>> Про wix-то всяко знаем, только каким боком он вдруг вылез? CC>Не знаю про какой ты Wix, но я про тот, что генерит пакеты для Microsoft Installer
А я тебе вообще про Setup project писал. Аналогия: тебе говорят — у копейки двигатель слабый, а ты — нет у миг29 нормальный.
Здравствуйте, vladimir.vladimirovich, Вы писали:
VV>>> Про wix-то всяко знаем, только каким боком он вдруг вылез? CC>>Не знаю про какой ты Wix, но я про тот, что генерит пакеты для Microsoft Installer VV>А я тебе вообще про Setup project писал.
Т.е. WIX АКА Windows Installer XML, который ещё в MSVC встраиваться умеет это ни разу не Setup project?
Здравствуйте, McSeem2, Вы писали:
MS>Однако, вынужден заметить, что и в Микрософте все плохо. Все гораздо хуже, чем в гмэйке. Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля.
Ниже уже написали, что можно ручками в .vcproj изменить GUID. Добавить могу только следующее — если мы копируем файл проекта, потом добавляем новый проект как "Add existing", то студия GUID в проекте сама поправит, чтобы не было одинаковых в солюшене.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, dotidot, Вы писали:
C>>>PS: давно хочу что-то типа SCons/waf с нормальным трекингом зависимостей для Java. А нету :( D>>чем не устраивает maven? C>Нету трекинга зависимостей. Т.е. maven просто тупо берёт и последовательно запускает плугины, даже если не изменилось то, что плугин должен обработать.
Запускать-то он запускает, только гоалы сами как правило не делают не нужную работу. Так что в сухом остатке результат именно такой, какой ты описывал.
D>>сам сейчас сижу на bash + maven :( но это уже не система сборки, а мего нечто для деплоймента из нечего во всё и все места автоматом в одно касание из интернета, отладки, профилирования, тестирования итд. C>Я тоже использую Maven
Сегодня нужно было подхачить один аддон к vaadin, удивился, увидев в корне файлик build.gradle. Оказалось, это нечто среднее между maven-ом и ant-ом, позволяет декларативно описывать зависимости как maven (а также использует систему репизоториев мавена), но при этом позволяет императивно описать процесс сборки на груви, как ант. Видимо, начинали делать еще во времена второго мавена, потому как в третьем мавен позволяет неплохо интегрировать груви.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Mr.Cat, Вы писали:
MC>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто.
V>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости.
Не выношу упоминаний парадокса Влада Блаба, но этот тот самый случай, когда без упоминания просто невозможно обойтись.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Cyberax, Вы писали:
C>У нас можно: C>1) Запускать 32-битные приложения на 32-битном ядре (взять 32-битный дистрибутив, воткнуть туда 64-битное ядро — и оно будет работать). C>2) Запускать 32-битные приложения на 64-битном ядре (без всяких магических перенаправлений). C>2) Запускать 64-битные приложения на 64-битном ядре (как ни странно). C>2) Запускать 64-битные приложения на 32-битном ядре (угу, это тоже возможно).
C>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине.
Да у вас там клево, я как-то кидал приятелю прогу (32), а у него 64 система (это про линукс, если че). Прога сразу не пошла, сказала либ нет, а приятель сказал — ну нах ставить еще что-то, когда и так все работает, а польза от проги еще чз
Здравствуйте, Cyberax, Вы писали:
IID>>Прекомпилённые заголовки, которые непойми как работают. Зубодробительный синтаксис прописываня зависимостей в make-файлах (а без них собирается говно, т.к. измененя не подхватываются и линкуется прокисший объектник). Идиотские динамические библиотеки, которые больше похожи на статик-либы и превосходно собираются с неразрешёнными внешними связями (unresolved external в Win). Это только малая часть. Уж ешьте такое сами. C>Зато позволяют нормально делать циклические ссылки, так как зависимости разрешаются в рантайме загрузчиком.
Таки и в винде можно делать циклически ссылки, хотя и не так просто, как "два пальца описать". В тоже время, а оно надо, циклические ссылки? Сколько живу, ни разу не понадобилось
Здравствуйте, McSeem2, Вы писали:
MS>Однако, вынужден заметить, что и в Микрософте все плохо. Все гораздо хуже, чем в гмэйке. Вот была VisualStudio-6, все было классно! В VS7 они зачем-то добавили в проекты свои идиотские кретинские гуиды (ВОТ ЗАЧЕМ!?) Что я делал в VS6 — просто копировал dsp и dsw, переименовывал, менял там названия файлов и все было отлично! А теперь, из за этих идиотских гуидов я вынужден каждый раз лишние 15 минут времени тратить на дрочение мышью, чтобы создать vcproj с нуля. Иначе, если просто переименовывать, то нельзя будет сделать из набора проектов sln из за одинаковых гуидов. У студии от такого наступает полный когнитивный диссонанс вплоть до абсолютной недееспособности. Но 15 минут времени — это не самое страшное. Самое страшное, что за эти 15 минут успеваешь пережить весь ментальный геморрой со времен большого взрыва! По количеству WTF там 15 минут за 10 миллиардов лет надо считать. Вообще, самое страшное наказание программисту в аду — это вечно настраивать проекты в вижуал-студии.
В фаре/консоли копируем vcproj. Можно руцами гуид поменять, можно и так в проект добавить, и студия сама новый гуид придумает. Раньше тоже сам руцами гуид менял, а сейчас лень стало
Здравствуйте, unreg_flex, Вы писали:
_>Здравствуйте, CreatorCray, Вы писали:
_>Если же править ручками в фаре то поменять нужно далеко не 1 параметр, надо залезть в sln, потом в vcproj и там и там переименовать проект и гуид, кроме того нужно переименовать сами файлы проекта и решения, потом загрузить полученный клон в ИДЕ, убедиться что зависимости какого-то буя сбросились и выставлять их заново.
Зачем лезть в sln? Я обычно копирую vcproj в фаре, потом в нем меняю имя, гуид и имя файла, в котором main/dllmain, потом добавляю проект в солюшн. Делов секунд на 30. Да, конечно, я уже стал немного лениться, и хочется в меню по правому клику на имеющемся проекте мыши пунктик — "сделать кайфовую копию", а в студии на панели кнопку "сделать вкайф".
Под линуксом немного работал, там обычно гемора больше было. Или с чем сравнение-то идет? А так, вообще уже надо давно шлем придумать, надел на голову, мыслишь — и код строчится, и пальцы о клаву не стираются, и проекты клонируются.
IID>Так, а теперь включаем логику. Если парсер, в качестве разделителей, станет воспринимать ещё и пробелы, это никак не сломает обратную совместимость. Зато будет работать ожидаемо. А не через жопу.
Не совсем так. Пробелы они в make для читабельности, а tab — для синтаксиса. Хотя да, не удобно. Можно было бы ключик придумать — обрабатывать пробелы как табы, это было бы круто для нового и не поломало бы совместимость.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Cyberax, Вы писали:
C>>Молча сиди и завидуй как у нас в Линуксе всё классно работает. C>>У нас можно: C>>1) Запускать 32-битные приложения на 32-битном ядре ...
DM>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.
Не правда ваша, все работает, причем не только на разных версиях одного дистра, но и на разных (правда родственных) дистрах.
Если что, я за винду таки, линукс — овно еще то
Здравствуйте, netch80, Вы писали:
N>Это основные факторы. Перефразируя твои жалобы, никто явно не заботится о том, чтобы результат сборки работал на более ранних версиях, неважно уж почему такое потребовалось и что этому мешает. Да, это так. Более того, были дистрибутивы, в которых пытались идти таким путём. Обнаружилось, что это (на тот момент) было никому массово нафиг не нужно. Я не хочу делать из этого каких-то глобальных философских выводов. В принципе, мне это не нравится — подход Windows действительно более адекватен задаче обеспечения совместимости работы на разных версиях и даже сборке под старые версии. Осталось понять, насколько это реально нужно...
Здравствуйте, netch80, Вы писали:
N>>>Но мне жаль тех, кто будет это понимать, когда 32-битка уйдёт и останутся только костыли, вызванные уже несуществующими историческими причинами. N>>>Иногда нужно таки ломать совместимость с чужими глюками, даже если это кажется дорогим.
M>>Однако, в отношении GNU make у тебя налицо двойные стандарты
M>>
M>>Нет, rocket science это договориться сотне поставщиков о синхронном изменении синтаксиса именно туда, куда хочет его изменить IID и прочие, кто не удосужился потратить пару минут на чтение документации или простой книжки. Внимание, вопрос: зачем тратиться ради ламеров?
N>Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. make (не говори GNU make, потому что их несколько версий от разных производителей) в случае необходимости переделки означает чуть ли не глобальную реформу в отрасли, потому что тот или иной makefile сопровождает любую юниксовую тулзу. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы
Неправда ваша. Для GMake и прочих make достаточно добавить кличик для работы с пробелами — без ключика — работать по старому, с табами. Делов на три минуты, чего там делать.
N>В случае же перехода 32->64 мы и так имеем грандиозную реформу всего кода. На момент подготовки этого перехода (я не говорю про сейчас, я говорю про 2002-2005 годы) крайне мало кода программ под Windows было готово для перекомпиляции под 64 бита и успешной работы под ней. Поэтому всё равно реформа требовалась. Почему бы в неё не включить и исправление по замене хардкоженных стандартных путей на получаемые из адекватного источника?
Потому что эти программы с 2000 года никто и не собирался перекомпилировать, работает — и ладно. Тяжкое наследие, и все такое. Винда за счет совместимости со старьем во многом и выезжает.
Здравствуйте, netch80, Вы писали:
M>>Вот в моем представлении — это такие же "костыли, вызванные уже несуществующими историческими причинами"
N>Тогда объясни эти исторические причины. N>В конце концов, в отличие от виндовых путей, тебя никто не обязывает использовать именно make традиционного вида. Есть десятки альтернатив, от просто изменённого синтаксиса до принципиально другого подхода. Но тебя потянуло именно на традиционный make, и ты, не попробовав альтернатив, плюёшься на всех как на него. Зачем?
С make гемор конечно. Я вот с маке познакомился, когда с борман си работал, их мейк пробелы нормально обрабатывал. И МС nmake их тоже нормально понимал. А гнутый/никсовый make — нет. А в редакторе есть только глобальная настройка "менять табы на пробелы", и каждый раз ее менять как-то лениво.
Здравствуйте, Marty, Вы писали:
C>>У нас можно: C>>1) Запускать 32-битные приложения на 32-битном ядре (взять 32-битный дистрибутив, воткнуть туда 64-битное ядро — и оно будет работать). C>>2) Запускать 32-битные приложения на 64-битном ядре (без всяких магических перенаправлений). C>>2) Запускать 64-битные приложения на 64-битном ядре (как ни странно). C>>2) Запускать 64-битные приложения на 32-битном ядре (угу, это тоже возможно).
C>>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине.
M>Да у вас там клево, я как-то кидал приятелю прогу (32), а у него 64 система (это про линукс, если че). Прога сразу не пошла, сказала либ нет, а приятель сказал — ну нах ставить еще что-то, когда и так все работает, а польза от проги еще чз
Точно так же могло не стоять какой-то библиотеки, без которой бы не запускалось в той же битности. Лень она и в Африке лень.
Здравствуйте, Marty, Вы писали:
N>>Такие "двойные стандарты" никак не двойные, а возникают в любом случае, где приходится идти на компромисс — сравнивается цена каждого варианта. make (не говори GNU make, потому что их несколько версий от разных производителей) в случае необходимости переделки означает чуть ли не глобальную реформу в отрасли, потому что тот или иной makefile сопровождает любую юниксовую тулзу. С другой стороны, сама по себе необходимость отличать пробелы от Tab'ов не означает ничего нового — есть и другие средства, где эта разница существенна. Наконец, это как раз просто, понимается за полминуты и дальше с этим надо просто работать, главное — не тратить нервы
M>Неправда ваша. Для GMake и прочих make достаточно добавить кличик для работы с пробелами — без ключика — работать по старому, с табами. Делов на три минуты, чего там делать.
Ключик-то добавить просто, не спорю. Но вопрос: *зачем*? Повторяюсь (уже сказано в треде), но мы 1) усложняем парсер (кстати, его исправить, отладить, обложить тестами, etc. — это не три минуты, это скорее один день), 2) ничего не даём полезного тем, кто и так "в системе" и пользуется её средствами (сейчас не 70-е годы, редакторы с адаптацией синтаксиса весят ничего и их уже десятки готовых), 3) рождаем новую потенциальную несовместимость с аналогами. Куча гимора с реально нулевым выходом.
N>>В случае же перехода 32->64 мы и так имеем грандиозную реформу всего кода. На момент подготовки этого перехода (я не говорю про сейчас, я говорю про 2002-2005 годы) крайне мало кода программ под Windows было готово для перекомпиляции под 64 бита и успешной работы под ней. Поэтому всё равно реформа требовалась. Почему бы в неё не включить и исправление по замене хардкоженных стандартных путей на получаемые из адекватного источника?
M>Потому что эти программы с 2000 года никто и не собирался перекомпилировать, работает — и ладно. Тяжкое наследие, и все такое. Винда за счет совместимости со старьем во многом и выезжает.
В том и фигня, что твои аргументы как раз работают в сторону прямого стиля решения (то есть /system64 для 64-битных библиотек и /system32 для 32-битных). 32-битные то никто не перекомпилирует, и для них осталось бы старое окружение, а на 64 бита всё равно перевод сложный (вон даже народ зарабатывает на средствах адаптации и поиска потенциальных ошибок), и там замена пути — только одна из граблей.
Тебе совсем нечего делать, кроме как на посты полуторалетней давности отвечать?
DM>>Забыл упомянуть, что приложения должны быть собраны на месте, ибо бинарник с соседнего линукса чуть другой версии уже хрен запустится (то ему glibc не тот, то ядро не то). Что делает систему непригодной для целой отрасли — коробочного ПО.
M>Не правда ваша, все работает, причем не только на разных версиях одного дистра, но и на разных (правда родственных) дистрах.
Уже ведь обсудили выше, чего повторяться. Что-то работает, да, но уже точно не "все работает" (сам же пример и привел). Полагаю, тут найдется немало людей, хлебнувших проблем с версиями glibc и вообще с зоопарком зависимостей софта от разных версий библиотек. Не думаю, что кто-то в здравом уме скажет, что в плане бинарной совместимости проги под линух делать/распространять проще, чем под винду.
Здравствуйте, Marty, Вы писали:
C>>А ещё у нас работает PAE, так что можно на полную катушку использовать память даже на 32-битной машине. M>Да у вас там клево, я как-то кидал приятелю прогу (32), а у него 64 система (это про линукс, если че). Прога сразу не пошла, сказала либ нет, а приятель сказал — ну нах ставить еще что-то, когда и так все работает, а польза от проги еще чз
Ну и? Если мне в Винде кинут программу, которая не работает из-за отсутствующих библиотек — не факт, что я не плюну на неё.
вообще логичней было б оставить
ProgramFiles для 32 бит
а дальше просто добавлять
ProgramFiles х64
ProgramFiles х128
ProgramFiles х256
ProgramFiles х512
...
хотя нафига вообще отдельная папка я так и не понял
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Cyberax, Вы писали:
MC>>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто. V>>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости. C>ROTFL!
Ну как минимум это лучше чем сидеть и ждать пока мейк сгенерит файлы зависимостей для каждой единицы трансляции.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
MC>>>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто. V>>>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости. C>>ROTFL! V>Ну как минимум это лучше чем сидеть и ждать пока мейк сгенерит файлы зависимостей для каждой единицы трансляции.
Гораздо лучше ждать, пока Студия решить компилировать ли ей файлы или просто воздух в комнате процессором погреть.
Здравствуйте, Cyberax, Вы писали:
MC>>>>>Ага, очень приятно в этом всем ковыряться. Проекты/солюшены ссылаются друг на друга как по путям, так и по гуидам. А студия умеет эти ссылки портить. При этом у msbuild крышу срывает начисто. V>>>>Осторожность с GUID-ами, это не самая большая плата за систему сборки, лучше всех на сегодня отслеживающей зависимости. C>>>ROTFL! V>>Ну как минимум это лучше чем сидеть и ждать пока мейк сгенерит файлы зависимостей для каждой единицы трансляции. C>Гораздо лучше ждать, пока Студия решить компилировать ли ей файлы или просто воздух в комнате процессором погреть.
Ничего подобного. Билд система студии гораздо быстрее гнушного мейка.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Kingofastellarwar, Вы писали:
K>вообще логичней было б оставить K>ProgramFiles для 32 бит K>а дальше просто добавлять K>ProgramFiles х64 K>ProgramFiles х128 K>ProgramFiles х256 K>ProgramFiles х512 K>...
K>хотя нафига вообще отдельная папка я так и не понял
Теоретически ты можешь поставить 32- и 64-битную версии софтины одновременно.
Здравствуйте, Kingofastellarwar, Вы писали:
K>вообще логичней было б оставить K>ProgramFiles для 32 бит K>а дальше просто добавлять K>ProgramFiles х64 K>ProgramFiles х128 K>ProgramFiles х256 K>ProgramFiles х512 K>...
K>хотя нафига вообще отдельная папка я так и не понял
Например, для того, чтобы иметь разнобитные версии одной программы. Потому как, вот скажем оракловый Sql Developer требует 32-битную jvm даже на 64-битной машине(и сам он при этом типа тоже 64-битный, хотя там нативы почти нет). А другие проги требуют 64-битную.
Я знаю, что жабовские виртуалки можно держать где угодно, но это просто из такого, что сразу могу рассказать.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Kingofastellarwar, Вы писали:
K>>вообще логичней было б оставить K>>ProgramFiles для 32 бит K>>а дальше просто добавлять K>>ProgramFiles х64 K>>ProgramFiles х128 K>>ProgramFiles х256 K>>ProgramFiles х512 K>>...
K>>хотя нафига вообще отдельная папка я так и не понял
E__>Например, для того, чтобы иметь разнобитные версии одной программы. Потому как, вот скажем оракловый Sql Developer требует 32-битную jvm даже на 64-битной машине(и сам он при этом типа тоже 64-битный, хотя там нативы почти нет). А другие проги требуют 64-битную. E__>Я знаю, что жабовские виртуалки можно держать где угодно, но это просто из такого, что сразу могу рассказать.
ну и ради бога, че мешает нам это самим сдеать напрмиер так:
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
кста когда появятся 128 битные процы, то как папки называться будут?
Program Files (x86)
Program Files
Program Files (x128)
или
Program Files (x86)
Program Files (x64)
Program Files
?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Torie, Вы писали:
T>Послушайте, в этом правда нет ничего сложного.
Чота поржал так полдня...
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Torie, Вы писали:
T>Послушайте, в этом правда нет ничего сложного.
А ещё если на 64-битной винде 32-битное приложение попытается открыть какой-нить .exe из System32 просто как файл, на чтение, то откроется версия из SysWOW64. Что может привести к оч. весёлой отладке...
МД>>Чота поржал так полдня...
K>за 7 лет раздел прочитал? )
Ага... На ссыль где то нажал...
Помоему я даже статью тут писал...про x64...
Да... В промышленном коде это жесть... Падеж возникал в самых неожиданных местах... Без дампов ничо и не понять было...
И это я ещё молчу что все библы надо было пересобирать
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Kingofastellarwar, Вы писали:
K>вообще логичней было б оставить K>ProgramFiles для 32 бит K>а дальше просто добавлять K>ProgramFiles х64 K>ProgramFiles х128 K>ProgramFiles х256 K>ProgramFiles х512 K>...
K>хотя нафига вообще отдельная папка я так и не понял
Я тоже полагаю, что просто ProgramFiles сгодится для любых программ
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Мёртвый Даун, Вы писали:
МД>>Чота поржал так полдня...
С>У меня есть сильное подозрение, что сегодня вы пишете на RSDN, будучи нетрезвым. Так делать не надо.
на RSDN можно писать трезвым? трезвым надо портировать программы с win16 на x64 фортрана на хаскель
Здравствуйте, CreatorCray, Вы писали:
CC>Думаю что тут лучше как раз накатить. Трезвым такое делать будет тяжко.
да.. я вот тоже удивляюсь современной жизни программистов в этой болотной жиже энтропии и полного упадка идей.. однако считают, что надо дожить до своей старческой болезни трезвым и не дай бог убиться как Мыщъх
Здравствуйте, ӍїϛϮϠǷiя-ȺҜ, Вы писали:
С>>У меня есть сильное подозрение, что сегодня вы пишете на RSDN, будучи нетрезвым. Так делать не надо.
ӍȺ>на RSDN можно писать трезвым? трезвым надо портировать программы с win16 на x64 фортрана на хаскель
Да ну, это банально. Ну получится Фортран-программа на Хаскеле, нам не привыкать.
Я даже футболку себе сделал — "I can write Fortran program in any language".
Здравствуйте, Marzec19, Вы писали:
M>Послушайте, скажите мне одну вещь. У автора текста, процитированного в первом посте, очень странно работал мозг. M>Как он это придумал?
M>Т.е. у него мозг в каком базисе (основополагающий набор исходных представлений) был?
Здравствуйте, Marzec19, Вы писали:
M>Послушайте, скажите мне одну вещь. У автора текста, процитированного в первом посте, очень странно работал мозг. M>Как он это придумал?
M>Т.е. у него мозг в каком базисе (основополагающий набор исходных представлений) был?
А по моему, за такие фокусы надо бить лопатой по хлебалу.
