16-битная Windows сделала некоторые действительно удивительные подвиги управления памятью, но это было затруднено тем, что она была разработана для процессора без управления памятью, а именно i8086 оригинального ПК (аппаратные средства могут не совпадать с тем, что оригинальный ПК использовал i8088 который был идентичен, за исключением ширины шины данных).
Итак, в 16-битных процессах Windows общий доступ к памяти одинаков.
Одна из проблем заключается в том, что общее адресное пространство памяти не так уж велико, на самом деле, когда многочисленные процессы хотят иметь свои собственные куски.
Кроме того, процессы могут слишком легко споткнуться о ноги друг друга.
Windows предложила некоторые частичные решения, такие как возможность для процесса информировать Windows о том, когда она фактически использует некоторую память (процесс затем «заблокирует» эту область памяти), что означало, что Windows может перемещать содержимое памяти в освободите место, когда это необходимо, но все это было добровольно и не очень безопасно.
Итак, 32-битная Windows, Windows NT, использовала управление памятью более нового процессора, чтобы автоматизировать лучшие практики, которые должны были использовать 16-битные программы Windows. По сути, процесс имеет дело только с логическими адресами , которые процессор автоматически преобразует до физических адресов (которые процесс никогда не видит). Что ж, на 32-битном ПК перевод выполняется в два этапа, т. Е. Есть внутренняя промежуточная форма адреса, но это сложность, о которой вам не нужно знать.
Одним приятным следствием этой аппаратно-поддерживаемой трансляции адресов является то, что процесс может быть полностью изолирован от знания того, какие физические адреса он использует. Например, легко иметь два процесса в одной программе. Они думают, что имеют дело с одними и теми же адресами, но это только логические адреса; на самом деле их логические адреса преобразуются в разные физические адреса, чтобы они не топали области памяти друг друга.
И одно последствие, которое мы с 20-20 лет назад можем сказать, не очень приятно, это то, что схема перевода позволяет виртуальную память , например. моделировать оперативную память с использованием дискового пространства. Windows может скопировать содержимое памяти на диск, а затем использовать эту область физической памяти для чего-то другого. Когда процесс, который использовал эту область памяти, записывает или читает из нее, Windows выполняет некоторую неистовую деятельность, чтобы загрузить данные обратно с диска в некоторую область памяти (может быть той же или другой) и отобразить логические адреса процесса там. Результатом этого является то, что в условиях низкой памяти ПК превращается из электронного зверя в механического зверя, выполняя затухание в тысячи и миллионы раз. Нехорошо - но когда размеры оперативной памяти были небольшими, люди думали, что виртуальная память аккуратна.
Основная проблема с виртуальной памятью в современной Windows заключается в том, что на практике практически невозможно отключить эту чертову штуку. Даже если запущена только одна «основная» программа и доступно гораздо больше, чем достаточно физической ОЗУ, Windows будет активно обмениваться данными на диск, чтобы подготовиться к ним, когда, возможно, этому процессу понадобится еще больше логической памяти. Однако, если бы это было исправлено, то, скорее всего, вместо него появилось бы что-то еще; Такова природа Вселенной.
Приветствия и hth.,