как удобно делать много процессов - можно сожрать намного больше! ;)

>4-5 гиг памяти ещё под 32-битной WinXP (и не спрашивайте как)

А что такого? Он же в несколько процессов работает. Разделить между несколькими процессами можно хоть 256 ГБ

Для меня в этом всё равно есть какая-то магия. Процессы разные, да - но ведь они могут взаимодействовать, и один процесс может, хотя бы теоретически, передать другому процессу указатель на свои внутренности (выставив соответствующие права доступа к себе), а второй процесс - эти внутренности прочитать? При этом указатель - 32 бита, а суммарный объём памяти на все процессы - больше 4Гб...

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

Ну а чо такого? Использовать общий кэш. Или передачу кэша. Я помню, на древней игрушке под ZX Spectrum с его 48 К оперативки разработчики умудрились впихнуть вроде миллион с лишним картинок и они не подгружались даже. Ну т.е. понятно, что, скорее всего, они просто рисовались. Но всё равно.

Не-не-не! Какой кеш, зачем кеш? Берём обычный указатель, на произвольный кусок своей памяти, и передаём его соседнему процессу. Если это в принципе возможно (пусть с объяснениями системе, что "ему в меня можно") - то возникает вопрос "как?!", указатель-то произвольный, а памяти - много.

Варианты, которые я вижу (какой правильный не знаю, ибо "не настоящий программист", и обмен данными под винду не писал):
  - так таки нельзя, и для обмена кусками памяти надо использовать только специально подготовленную (замапленную в доступную обоим процессам область) память
  - указатель на самом деле не настоящий линейный указатель, а пара "дескриптор + настоящий указатель", тогда в 32 бита "как-бы-указателя" можно спрятать сколько угодно настоящих бит (извлекаемых из таблицы по дескриптору)
Как на самом деле - я не знаю, но "в лоб" - вроде как нельзя.

> разработчики умудрились впихнуть вроде миллион с лишним картинок и они не подгружались даже

А как это выглядело-то? Миллион картинок даже на 25FPS придётся смотреть 11 часов подряд, значит всех их увидеть вряд ли было возможно - но тогда откуда известно, что их миллион?

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

>А как это выглядело-то? Миллион картинок даже на 25FPS придётся смотреть 11 часов подряд, значит всех их увидеть вряд ли было возможно - но тогда откуда известно, что их миллион?

Из обзора, но могли и наврать, конечно. Игрушка, впрочем, действительно была очень красочная и бродить там можно было долго. На Спектруме ничего подобного больше не было.

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

А вообще, ещё с первой "Элитой" такое было: просто текстовый файл с названиями всех планет и систем занимал бы больше, чем исполняемый файл с игрой.

А, понятно что за картинки. И, в-общем-то, ясно что даже если они "собираются по схеме из кубиков", сами схемы тоже придётся генерировать - миллион карт в 64к ну никак не поместится :-)
А про "элиту" - не знал. Неужели названия тоже генерировались на ходу?..

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

ну а про всякие демосцены, где в 64 К графики, как на современную (по тем временам) игру даже молчу)

Давайте я вмешаюсь, всё-таки я хорошо знал «Спектрум» и много под него программил.

Были «Спектрумы», у которых на борту было больше памяти, чем 64КБ. Например — 512КБ. Организация была «страничная», т.е. можно было попросить систему «замени мне такие-то (фиксированные) адреса другим банком памяти». Видимо речь идёт о них.

По поводу «Элиты» названия генерились из содержимого ROM. А поскольку «Спектрумов» с кастомной прошивкой было пруд пруди, названия планет могли ещё и сильно отличаться от модели к модели.

В 512КБ уместить миллион "карт" всё равно не получится - в четыре бита карта не поместится, да и пользователь утомится, пока всё это загрузится в память. Написать генератор карт, выдающий миллион разных "играбельных" (с гарантированной проходимостью) карт - куда проще, чем пытаться всё это запаковать :-)

"Из содержимого ROM" - это интересно. На "писишной" демосцене была история, как на каком-то конкурсе "сверхкомпактных демок" (то-ли 1k demo, то-ли 4k demo, то-ли не помню уже), где параметры компьютера для демонстрации были подробно объявлены заранее, включая точную версию DOS, демка использовала часть содержимого command.com как текстуру для отрисовки. На других версиях dos текстура, естественно, рассыпалась :-)

Мало того, что названия генерировались, так там и цены на товары генерировались и каждый раз одинаково плюс небольшой рандом. А потом начинали плавать в зависимости от того, ввозил ли игрок товар в систему или вывозил.
И так восемь галактик по оченьмного звёзд.

> Не-не-не! Какой кеш, зачем кеш? Берём обычный указатель, на произвольный кусок своей памяти, и передаём
> его соседнему процессу. Если это в принципе возможно (пусть с объяснениями системе, что "ему в меня
> можно") - то возникает вопрос "как?!", указатель-то произвольный, а памяти - много.
Вот прямо так - нельзя. Можно иначе:
1. "Прочитать из такого-то процесса с такого-то адреса столько-то байт и положить вот сюда".
BOOL WINAPI ReadProcessMemory(
__in HANDLE hProcess,
__in LPCVOID lpBaseAddress,
__out LPVOID lpBuffer,
__in SIZE_T nSize,
__out SIZE_T* lpNumberOfBytesRead
);

2. "Взять кусок shared memory и замапить его в мой процесс"
LPVOID WINAPI MapViewOfFile(
__in HANDLE hFileMappingObject,
__in DWORD dwDesiredAccess,
__in DWORD dwFileOffsetHigh,
__in DWORD dwFileOffsetLow,
__in SIZE_T dwNumberOfBytesToMap
);

3. "Выдилить кучу страниц памяти, а потом по очереди мапить их в одно и то же адресное пространство"
AllocateUserPhysicalPages/MapUserPhysicalPages.

В общем, все три способа - трансанальные.

Адресные пространства процессов изолированы, поэтому и адреса могут просто перекрываться, а писать и читать надо специальными ф-ями. Но если надо страницы зашарить, то используют memory mapped file, который может быть как бы и не файл, а просто кусок виртуальной памяти, это самый быстрый способ, страницы просто отображаются в разные процессы. Ну а вообщем зачем всем видеть всю эту суммарную память, надо лишь взаимодействие организовать и постараться изолироваться по максимуму.

Оно и забавно - если адреса могут перекрываться, значит для адресации фактически используется не просто "указатель", а "указатель+контекст", то есть на самом деле адресовать можно больше чем помещается в 32 бита, просто "не за один раз". При Путине в VAX/VMS такого безобразия не было (впрочем, могу ошибаться), указатель указывал на область памяти однозначным образом! :-)))

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

Пишут, что для взаимодействия они каналы используют. Посмотрел список объектов ядра в process explorer - действительно каналы там имеются.

нет магии.
шарить память по указателю можно только через специальную область, повыше области 2 Гб приложения. так вот место в этой области крайне ограниченно, соответственно гигабайтами напрямую (через указатели) процессы в 32-х разрядной винде без ухищрений обмениваться не могут.

А, ну тогда понятно, как они это сделали. Мысль такая была (либо специальная область, либо "ненастоящие" указатели), но как именно - не знал :-)

Вспоминается архитектура VAX почему-то...

В VAX вроде до таких извратов (можно распределить памяти больше чем адресное пространство, и всё будет работать, разве что нельзя будет свободно обмениваться указателями) не додумались, ограничились виртуальной памятью? Или я ошибаюсь?

Честно сказать, я не помню, можно ли там было распределить памяти больше, чем адресное пространство.
Кажется, теоретически можно было. Книга Операционные системы в соседней комнате, а это из кресла вылезать надо :)
Я помню, что там основной цимес был в том, что можно распределить памяти больше, чем есть физической. Но это очевидно.

Можно было.
NT как раз многое, в этом плане, унаследовала от ваксов диджитал. В частности вот эту "анизотропию" адресного пространства (нижняя половина - для приложений, верхняя - для системы).

именно так

Коллеги, может осознаем главный ужас ситуации - браузер отежает гигабайты!

Гена
UA1ARN

Да уж осознали. Вот только что делать непонятно - боюсь, "под третьим нетскейпом" не так уж много сайтов заведутся, а современные браузеры - ну, таки да, они такие...