64 Bit Explained
Вот. Истинная правда:
Look, it’s really not that hard.
Programs are still in the same place, in %ProgramFiles%, unless you need the 32 bit version, which is in %ProgramFiles(x86)%, except on a 32 bit machine, where it’s still %ProgramFiles%.
All those dll’s are still in %SystemRoot%\System32, just now they’re 64 bit. The 32 bit ones, they’re in %SystemRoot%\SysWOW64. You’re with me so far, right? Oh, and the 16 bit ones are still in %SystemRoot%\System – moving them would just be weird.
Registry settings are in HKLM\Software, unless you mean the settings for the 32 bit programs, in which case they’re in HKLM\Software\Wow6432Node.
So the rule is easy: stick to the 64 bit versions of apps, and you’ll be fine. Apps without a 64 bit version are pretty obscure anyway, Office and Visual Studio for example[1]. Oh, and stick to the 32 bit version of Internet Explorer (which is the default) if you want any of your add-ins to work. The ‘default’ shortcut for everything else is the 64 bit version. Having two shortcuts to everything can be a bit confusing, so sometimes (cmd.exe) there’s only the one (64 bit) and you’ll have to find the other yourself (back in SysWOW64, of course). And don’t forget to ‘Set-ExecutionPolicy RemoteSigned’ in both your 64 bit and 32 bit PowerShell environments.
Always install 64 bit versions of drivers and stuff, unless there isn’t one (MSDORA, JET), or you need both the 32 bit and 64 bit versions (eg to use SMO / SqlCmd from a 32 bit process like MSBuild). Just don’t do this if the 64 bit installer already installs the 32 bit version for you (like Sql Native Client).
Anything with a ‘32’ is for 64 bit. Anything with a ‘64’ is for 32 bit. Except %ProgramW6432% which is the 64 bit ProgramFiles folder in all cases (well, except on a 32 bit machine). Oh and the .net framework didn’t actually move either, but now it has a Framework64 sibling.
I really don’t understand how people get so worked up over it all.
Для всего этого счастья есть логичное объяснение, сдобренное обычным “ну здесь мы применили маленький хак”. Но от этого не сильно легче.
Отсюда: http://piers7.blogspot.com/2010/07/64-bit-explained.html.
Жуть
. Обратная совместимость это и “плюс” и “минус” современных ОС Windows.
А что будет, если вы начнёте поддерживать в “основных Виндах” ещё и процессоры ARM?
Кстати, чтобы вам было ещё “приятнее”, от пути “Program files (x86)” программа mingw32-make.exe иногда шизеет – не хочет компилировать библиотеку Qwt, вылетая с ошибкой
“C:\Qt\2010.04\mingw\bin\make.EXE: Interrupt/Exception caught (code = 0xc00000fd, addr = 0×421963)”.
Ой, а можно я любимый аргументом Windows haters воспользуюсь? 64-х битная Windows вышла в 2003 году. За 7 лет можно было бы баг бы и исправить?
@Алексей Пахунов
> Ой, а можно я любимый аргументом Windows haters воспользуюсь?
Более того, не дай бог в вашей конторе будут делать очередной костыль вроде виртуализации ФС для обхода ошибки в mingw32-make!
Но у вас, к счастью, всё-таки народ здравомыслящий. А так, есть где развернуться с виртуальными фс
.
—————–
1. Кстати, нет ли у вас какого-нибудь места, где планируют дальнейшую эволюцию ОС?
2. А почему нельзя было при проектировании Windows 7 использовать традиционный для MacOS/Linux метод совместимости со старым сторонним софтом, а именно, “проблемы индейцев шерифа не волнуют”?
Всё равно ведь есть запускаемая в виртуалке WinXP, а под Висту не так много чего поднаделали, чтобы нельзя было это исправить?
> Кстати, нет ли у вас какого-нибудь места, где планируют дальнейшую эволюцию ОС?
В смысле, централизованно планируют. Вроде, что убрать, что добавить, как будем менять расположение System32 в System64 и т.д. Чтобы планы были больше, чем на один релиз.
Т.е., к примеру, в Vista мы переносим часть Program Files в Program Files (x86), а в 7-ке оставляем PF (x86-64) и PF (x86), а Program Files просто убираем.
Есть. Но любая информация от них закрыта.
Потому что мы хотим, чтобы Windows продавалась.
Есть. Но планируют там не просто “переименовать System32 в System64″, а задумываются сколько каждое планируемое изменение стоит и насколько полезно оно будет. Насколько я это понимаю.
На всякий случай замечу, что нет такого места где разбираются ВСЕ изменения на ВСЕХ уровнях. Это просто невозможно.
“Клята пропрієтарщина” (шутка)
Я задумался, почему таких косяков нет у Mac OS (есть свои, но не такие косые) и решил, что разница в подходах: Майкрофост считает, что “программисты никогда не следуют всем рекомендациям на 100%”. В то время как Apple – “программисты всегда следуют всем рекомендациям на 100%”. В реальности, конечно, все не так и наиболее правильной будет формулировка “не все программисты следуют всем рекомендациям на 100%”.
Подход Apple стимулирует ответственность: что-то не прочитал или сделал не по правилам – сам себе буратина, в то время как Microsoft позволяет расслабиться и не сильно думать.
> Я задумался, почему таких косяков нет у Mac OS
Во-первых, MacOSX – это неуловимый Джо.
Во-вторых, на мой взгляд, там система на большую часть состоит из “свободных” программ, вроде mingw32-make.exe, которые можно просто подправить в любой момент. И не надо городить всякие виртуализации ФС и остальные костыли.
В-третьих, подход MacOSX – “проблемы индейцев шерифа не волнуют”.
Такой же и в Linux. В результате под Linux теперь нет ни единого off-line дефрагментатора ФС. Раньше был e2defrag, который работал с ядрами 2.2, а сейчас, боюсь, он уже даже и не компилируется.
Ужасно. В чью светлую голову вообще могла прийти мысль засовывать 64хбитный код в system32? Неужели бардак при переходе с 16 бит никого ничему не научил?
Его нет не по этому, а из-за слабой нужности. Для новой ext4 есть онлайн-дефрагментатор, но в дистрибутивах его до сих пор нет, потому что есть вещи понужнее.
Я помню аналогичную ситуацию с NTFS. Утверждалось, что дефрагментатор для NTFS не нужен. Какой вой стоял в Fido/форумах!.. Потом появилось дефрагментаторы третьих фирм. Потом дефрагментатор встроили в Windows.
> Я помню аналогичную ситуацию с NTFS. Утверждалось, что дефрагментатор для NTFS не нужен.
Ну с NTFS ведь совсем клиника была во времена NT4 – http://www.ixbt.com/storage/ntfs.html Всё-таки, та же FAT на 95-х фрагментировалась значительно меньше.
Насколько я понимаю, сейчас идиотизм API дефрагментации убрали, но часть проблем вроде бы осталась.
Алексей, если можно, прокомментируйте пожалуйста эту IXBTшную статью. Или хотя бы скажите, поменяли ли аллокатор, который забивал новым файлом все свободные дырки с начала диска?
>Его нет не по этому, а из-за слабой нужности.
Ага. А xfs_fsr есть и работает. И полезен периодически.
А ReiserFS тоже через некоторое время полезно дефрагментировать методом перекопирования.
Да, в общем, какая разница, помимо e2defrag есть до чёрта другого софта, утратившего совместимость с текущими Linux дистрибутивами. Метод поддержки совместимости в Linux – это метод шерифа. Тоже, одновременно хорошо и плохо.