Господа, такой вопросик - я когда то на асме под досом баловался и так понимаю, что если ехешник 5 кг весит, то и в памяти где-то столько же будет (динамически ничего не просит).

А вот надо мне теперь мАААленькую утиль под Вынь32 сделать - и что я вижу? Ехешник сам всего - ничего, а в памяти 500 килов съел. Это если я окон вообще не создаю. А если создаю - более тонны.. Ну я понимаю, Вынь создает структуры там у себя чтобы окно описать и все такое. Но совесть-то надо иметь!?

Как с таким расходом DDR'a бороться?

[EHOT: [i]Как с таким расходом DDR'a бороться?[i]]

Ответ простой - никак.

Стек - одна страничка для начала.
Память на структуры объектов "процесс" и "поток" - как минимум.
Ну это, правда, в ядре.
Блоки окружения процесса и потока.
Еще кое-какие нужные структуры.

А длл: kernel32, user32 и т.п. В NT каждый процесс имеет свою копию.
Код разделяет физические страницы, а вот секция данных индивидуальна.
Они то в основном и жрут.

Так что не трать силы - бесполезно.

А длл: kernel32, user32 и т.п. В NT каждый процесс имеет свою копию.
Код разделяет физические страницы, а вот секция данных индивидуальна.
Они то в основном и жрут.

Не правда. DLL'и у всех програм те-же самые, то-есть одна копия на всю систему. А если программа исменила данные/код DLL'a, то только эти изменения сохраняутся отдельно (одна страница - 4096 байтов).

[comrade: Не правда. DLL'и у всех програм те-же самые, то-есть одна копия на всю систему. А если программа исменила данные/код DLL'a, то только эти изменения сохраняутся отдельно (одна страница - 4096 байтов).]

Ох, лень писать, да ладно, раз пошла такая пьянка.

Я уже оговаривался, что имею ввиду NT. Оговариваюсь еще раз.
Для 9x сами смотрите.
В 9x все системные длл действительно разделяются между процессами.
Но что там с секцией данных я уже не помню.


Входим в SoftICE

cls

Чтоб лог поменьше был.

proc

Выбираем любые два процесса (можно больше - по вкусу), кроме idle (у него вообще юзерных модулей нет), System и smss.

Переключаемся на адресный контекст выбранного процесса:

addr <имя процесса>

Смотрим какие модули у него в юзере:

mod -u

Можно и не смотреть, т.к. kernel32, user32, advapi32 и gdi32 практически в каждый процесс отображаются (кроме вышеперечисленных).
Выбираем, например advapi32 (у него секция данных побольше)

Смотрим адрес и размер (у мя 4 страницы) секции данных:

map32 advapi

Смотрим в какие физические страницы отображена секция данных:

page <адрес секции данных> l 4

Если у вас размер .data для advapi32 другой, то подставляете свое значение (в страницах). Видим физические адреса.

Проделываем все вышеописанное (начиная с команды addr) для другого (других) процесса.
Идем в SoftICE Symbol Loader и сохраняем лог в файл: File->Save SoftICE History As...
Открываем в нескольких (по числу просмотренных прцессов) экземплярах notepad, сравниваем и анализируем результаты. Критикуем меня если не прав ;-)

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

В NT каждый процесс получает свою копию системной длл, причем все секции разделяют одни и те же физические страницы, кроме секции данных. Если процесс что-то пишет в секцию кода например, то тогда эта страница переотображается в другую физ страницу. А вся секция данных у каждого процесса своя.

Вообще посмотреть что куда мапится у процесса можно по команде:

query

А потом брать каждый диапазон и смотреть по каким физ адресам он отображен, все той же page.

Можно еще проанализировать системные модули (mod -s), но там немного сложнее все.

Ну ладно, своим знанием вы меня, товарищь, закапали.

> Стек - одна страничка для начала

Если не ошибась, то для начала три странички - сверху и снизу PAGE_GUARD :)

Чуть-чуть ошибся ;-) страничка PAGE_GUARD только снизу.
Я сразу хотел поправиться да заленился.

Щас глянул. Реально, для процесса, кот ваще ничего не делает

.code
start:
invoke Sleep, -1
ret
end start

Под стек уже 2 страницы выделено + 1 сторожевая.
А сразу за стеком (вверх) у мя куча начинается. 3 паги выделенных, между прочим.