Все программы находятся там же, в %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$ породил геморрой, который придется тянуть еще не одно десятилетие.
А по моему, за такие фокусы надо бить лопатой по хлебалу.
