Здравствуйте, BulatZiganshin, Вы писали:

BZ>пользователю ничуть не легче от того, что антивирусы и прочая дрянь формально являются частью его процесса

Это как так (про выделенное)?

dll-ки это контроллируемо. Загружаются только используемые и их зависимости. Out-of-process системные dll не загружаются — внутри пространства процесса только stubs для вызовов

Здравствуйте, BulatZiganshin, Вы писали:

BZ>почему? неужели лишние 100-200 мег так критичны?

Там цифры были несколько иные.
Только под нужды системы было захвачено почти девятьсот мегабайт. Для сравнения — вот я сейчас
пишу сообщение из-под 32-битной Windows 7, открыта Opera и несколько вкладок. Диспетчер задач
показывает, что занято 470 мб физической памяти, что, грубо говоря, вдвое меньше.
А оставшийся гигабайт с копейками очень быстро съедается какой-нибудь "Студией", после чего
начинается активный своппинг и тормоза. И в такой ситуации нет разницы, 64-битный 32-битный
процесс, есть ли у его PE-заголовка флаг "large address aware" — память исчерпана, не из
воздуха же операционная система ее возьмет. IMHO 2 гигабайта для 64-битной Windows маловато.

Здравствуйте, okman, Вы писали:

O>Попробовал.
O>А еще я пробовал работать на ноутбуке с двумя гигами оперативки и 64-битной Windows.
O>Знатное, скажу я, извращение.

Ну у меня на нетбуке такое стоит. Ещё и своп отключен.
Работает вполне сносно.

Здравствуйте, okman, Вы писали:

BZ>>почему? неужели лишние 100-200 мег так критичны?

O>Там цифры были несколько иные.
O>Только под нужды системы было захвачено почти девятьсот мегабайт.

у меня невыгружаемых 338. согласись, проблема у тебя была не в винде, а в несоответствии железа софту. с другой стороны, сейчас и браузер гиг отожрать способен, так что машину с двумя гигами лучше всего вообще "покрасить и выбросить"

Здравствуйте, Vetal_ca, Вы писали:

BZ>>пользователю ничуть не легче от того, что антивирусы и прочая дрянь формально являются частью его процесса

V_>Это как так (про выделенное)?

в подробности не вдавался

V_>dll-ки это контроллируемо. Загружаются только используемые и их зависимости. Out-of-process системные dll не загружаются — внутри пространства процесса только stubs для вызовов

ну и как это контролируемо? хочешь 4 гб — не используй никаких библиотек, втч системных?

Здравствуйте, BulatZiganshin, Вы писали:

BZ>ну и как это контролируемо? хочешь 4 гб — не используй никаких библиотек, втч системных?

А так, что под адресным пространством процесса подразумевается пространство для всех его dll (in-proc), стека, хипа, static data и т.д. DLL это тот же процесс, тот же стек и т.п., от самой программы они мало ччем отличаются. Это что-то вроде оверлеев в доисторическую эпоху

От многих системных остаются только стабы (out-of-process dll)

Для in-process dll можно загружать выгружать динамически, по мере использования

Здравствуйте, okman, Вы писали:

O>Вот только на сегодняшний день далеко не всякая программа, — особенно это касается
O>прикладного софта, — имеет 64-битную редакцию. Это значит, что запускаться такие
O>программы будут в WOW64 и почти никаких преимуществ платформы они не получат

Не совсем так. Системные dll'ки остаются в 64-хбитах, поэтому адресного пространства приложение получает почти 4Гб, а не 2-3 как на 32-х битах. Иногда это важно.

O>И еще. Система безопасности на 64-битных Windows, начиная с Vista, не позволяет загружать
O>неподписанные драйверы

В Win8 запрет можно отключить.

O>, не разрешает патчить код ядра, системных таблиц и т.п.

Это скорее плюс

Здравствуйте, okman, Вы писали:

O>Для этого в PE-заголовке должен быть прописан флажок "large address aware".

Так где от этого есть польза — он прописан.

Здравствуйте, AndrewVK, Вы писали:

AVK>В Win8 запрет можно отключить.
Насовсем или как и раньше, до след. ребута?

Здравствуйте, Трололоша, Вы писали:

Т>Насовсем или как и раньше, до след. ребута?

до следующего ребута. но установленные драйвера остаются.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>у меня невыгружаемых 338. согласись, проблема у тебя была не в винде, а в несоответствии железа софту. с другой стороны, сейчас и браузер гиг отожрать способен, так что машину с двумя гигами лучше всего вообще "покрасить и выбросить"

IMHO, логичнее покрасить и выбросить такой браузер...

Здравствуйте, Erop, Вы писали:

BZ>>у меня невыгружаемых 338. согласись, проблема у тебя была не в винде, а в несоответствии железа софту. с другой стороны, сейчас и браузер гиг отожрать способен, так что машину с двумя гигами лучше всего вообще "покрасить и выбросить"

E>IMHO, логичнее покрасить и выбросить такой браузер...

на втором месте по занимаемой памяти у меня стоит tortoise hg — 200 мб, 7-zip для макс. сжатия требует 800 мб и т.д. просто времена dos прошли

Здравствуйте, BulatZiganshin, Вы писали:

BZ>на втором месте по занимаемой памяти у меня стоит tortoise hg — 200 мб, 7-zip для макс. сжатия требует 800 мб и т.д. просто времена dos прошли

Просто снобы неадекватны. Есть куча мелких машинок под виндой, которым незачем быть большими дорогими и тяжёлыми...

Здравствуйте, Erop, Вы писали:

BZ>>на втором месте по занимаемой памяти у меня стоит tortoise hg — 200 мб, 7-zip для макс. сжатия требует 800 мб и т.д. просто времена dos прошли

E>Просто снобы неадекватны. Есть куча мелких машинок под виндой, которым незачем быть большими дорогими и тяжёлыми...

я не знаю, почему это вызывает такие проблемы. вот времена "640к хватит на всех" прошли, это ты понимаешь? вот и времена "2гб хватит" также проходят. софт тяжелеет

Здравствуйте, BulatZiganshin, Вы писали:

BZ>я не знаю, почему это вызывает такие проблемы.
Потому, что слишком узко смотришь на проблему. Совсем и не всем людям срочно нужно купить компик помощнее... И даже жать зип с максимальным сжатием мало кому нужно

BZ>вот времена "640к хватит на всех" прошли, это ты понимаешь?
Не знаю, среди моих 20 любимых программ, по крайней мере три досовских...

BZ>вот и времена "2гб хватит" также проходят. софт тяжелеет
Это тоже иллюзия. Софт тяжелеет на десктопах.
Но уже были ноутбуки, нетбуки, теперь планшетки, потом ещё что-нибудь появится массовое и слабое...
А софт, который всё тяжелеет и тяжелеет так на десктопах и серверах и остаётся

Здравствуйте, AndrewVK, Вы писали:

AVK>Не совсем так. Системные dll'ки остаются в 64-хбитах, поэтому адресного пространства приложение получает почти 4Гб, а не 2-3 как на 32-х битах. Иногда это важно.

Системные dll-ки никуда не деваются — 32-битные приложения на x64 загружают их 32-битные
версии из /Windows/SysWOW64, и проецируются они на 32-битное адресное пространство, аналогично
тому, как это происходит на 32-битных системах. Поэтому виртуальной памяти у 32-битных
процессов, запущенных на x64, остается столько же, как если бы они были запущены на x86,
ну или даже чуть меньше, поскольку определенное пространство уходит на поддержку WOW64 — это,
как минимум, образы wow64*.dll, 64-битной ntdll.dll, а также 64-битные стеки потоков.

Все описанное относится к ситуации, когда исполняемый файл не имеет в PE-заголовке флага
"large address aware". Если такой флаг имеется, тогда тогда приложению становятся доступными
почти все четыре гигабайта, даже если физически установлено меньше.

Вопрос в том, много ли 32-битных программ, у которых этот флажок есть и что это за программы.
Например, на моем рабочем компьютере из пятнадцати установленных программ работать с адресами
выше 2 гигабайт умеют только две — Visual Studio и Opera, а распостраненный прикладной
софт типа асек-скайпов-вьюеров-офисов в большинстве своем такого флага не имеет и резона
использовать его на x64 не будет.

O>>И еще. Система безопасности на 64-битных Windows, начиная с Vista, не позволяет загружать
O>>неподписанные драйверы

AVK>В Win8 запрет можно отключить.

Но это плохо, когда из-за ограничений какого-то одного драйвера приходится всю
систему переводить в тестовый режим или нажимать каждый раз F8 при загрузке.

O>>, не разрешает патчить код ядра, системных таблиц и т.п.

AVK>Это скорее плюс

Полностью согласен.

Здравствуйте, okman, Вы писали:

O>Вопрос в том, много ли 32-битных программ, у которых этот флажок есть и что это за программы.

а к чему ты спрашиваешь? если в практических целях, то editbin позволяет легко выставить этот флажок на любом exe

Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, okman, Вы писали:

O>>Вопрос в том, много ли 32-битных программ, у которых этот флажок есть и что это за программы.

BZ>а к чему ты спрашиваешь? если в практических целях, то editbin позволяет легко выставить этот флажок на любом exe

дело же не во флажке, как таковом, а именно в поддержке. То что ты поставишь флаг на проге, которая не понимает 3gb скорее всего приведет либо к ее крашу либо к глюкам.

Здравствуйте, mike_rs, Вы писали:

O>>>Вопрос в том, много ли 32-битных программ, у которых этот флажок есть и что это за программы.
_>дело же не во флажке, как таковом, а именно в поддержке. То что ты поставишь флаг на проге, которая не понимает 3gb скорее всего приведет либо к ее крашу либо к глюкам.

этот флажок на прогах не стоит исключительно потому, что он не стоит по умолчанию и вообще малоизвестен среди программистов. вряд ли ты сейчас найдёшь бибилиотеку, не способную работать с 4гб, и тем более программу, которая помимо библиотек содержит такой код

Здравствуйте, Vetal_ca, Вы писали:

ХГ>>Это не так. Под Win-64 32-битные программы получают примерно 3.7 Гб пользовательского адресного пространства вместо 3 Гб под Win-32. Иногда это существенно.

V_>Скорее, почти 4. Все зарезервированные областы "выносятся" из адресного пространства, оставляя только заглушки для вызовов и области для "отлова" околонулевых указателей. Но для этого надо флаг линкером или спец утилитой от VS ставить. Что программа способна работать с адресами за 2 Gb

Почти 4 — это сколько? У меня реально немногим больше 3.7 получалось. Правда, еще на XP мерил.