Расширение окон адресации (Address Windowing Extensions, AWE) — это функция Windows, которая позволяет программам выделять физическую память и отображать её по страницам в область адресного пространства («окно адреса»). PAE — это расширение физического адреса (Physical Address Extension), функция 32-битного x86‑процессора, которая позволяет генерации физических адресов больше 32 бит, что даёт возможность обращаться к более чем 4 ГБ физической оперативной памяти материнской платы.
Некоторое время назад я отметил, что AWE не требует PAE. Эти две функции работают независимо, но их удобно использовать вместе.
Если вы используете AWE без PAE, то ваша 32‑битная система Windows может адресовать только 4 ГБ установленной памяти, поэтому возможность AWE предоставлять доступ к большому объёму физической памяти имеет ограниченную практическую ценность: система изначально имеет только 4 ГБ памяти, и это всё, что вы можете получить. Вы написали много сложного кода для сценария с большим объёмом оперативной памяти, когда на самом деле такой памяти, чтобы извлечь из этого выгоду, нет.
Это похоже на покупку большого чайника для заваривания одной чашки чая: у вашего чайника есть вместимость для большого объёма чая, но вы собираетесь налить в него всего одну чашку.
Всё это в значительной степени историческая информация, потому что 64‑битные процессы на 64‑битных системах могут выделять более 4 ГБ памяти и использовать её обычным образом. Никаких специальных ухищрений не требуется.
Примечание: одна вещь, которую даёт AWE — возможность выделять физическую неперемещаемую (non‑pageable) память. И снова: вы можете использовать эту возможность независимо от того, включён ли у вас PAE.
Примечание 1: 32‑битная программа, использующая AWE, по‑прежнему будет выполняться на 64‑битной системе при условии, что 64‑битная система использует тот же размер страницы, что и 32‑битная система. Смотрев на таблицу размеров страниц, используемых Windows, это означает, что 32‑битная x86‑программа (размер страницы 4 КБ) может работать на x86‑64‑системе и на AArch64, но не на Itanium.
Рэймонд участвует в эволюции Windows более 30 лет. В 2003 году он запустил веб‑сайт под названием The Old New Thing, который стал гораздо популярнее, чем он мог себе представить, развитие чего до сих пор вызывает у него смутное беспокойство. Сайт породил книгу с тем же названием (Addison Wesley, 2007). Иногда он появляется в аккаунте Windows Dev Docs в Twitter, рассказывая истории, которые не несут полезной информации.
Обсуждение закрыто. Войдите, чтобы редактировать/удалять существующие комментарии.
Я полагаю, AWE представляет физические фреймы страниц, которыми управляет диспетчер памяти, или что‑то близкое к этой абстракции.
Почему это считается устаревшим для x64? Оно фиксирует ваши фреймы, и хотя непосредственные проблемы x86 исчезли, это могло бы быть полезно для обеспечения физической согласованности, вместо того чтобы фреймы страниц «летали» как сумасшедшие (в изощрённой форме, но всё же).
В x64, насколько я знаю, это было бы полезно только для резервирования неперемещаемой памяти (а это, само по себе, обычно плохая идея, если вы не знаете, что делаете). Если вы можете обойтись обычной, подкачиваемой памятью, проще зарезервировать достаточно большой блок обычной памяти. А в случае неперемещаемой памяти, вероятно, есть и другие способы добиться того же. Так что можно сказать, что в x64 AWE было «почти» бесполезно (кавычки намеренно). Разве что вам нужно больше чем 16 HB (то есть гексабайт) памяти, конечно.
AWE немного напоминает отображение представления файла в память (memory mapping), или, может быть, скорее EMS‑страничный фрейм из старых времён (особенно с PAE), поскольку и там тоже присутствовало окно в более большое адресное пространство.
Это не совсем то же самое, AWE близко к выделению фреймов страниц. Это как физическое выделение. Ядро управляет картой виртуальной и физической памяти. Виртуальные фреймы могут оставаться резидентными, в то время как физические фреймы страниц могут «летать» по системе.
В этой конкретной реализации mmap просто потоково переносит ввод‑вывод в ОЗУ. Между ними нет эквивалентности.
Это довольно похоже на то, что EMS делал в режиме программной эмуляции, которым пользовались 99% людей: он отображал в окно под лимитом в 1 МБ страницы, находившиеся выше этого лимита, чтобы программы в реальном режиме могли использовать больше, чем 640 КБ ОЗУ. Он также выполнял некоторый учёт памяти выше 1 МБ, в основном отслеживая, какие страницы выделены, а какие свободны.
Конечно, существовали и физические EMS‑платы памяти, но даже в своё время они были редки, и появление PC на базе 386 с более чем 640 КБ базовой памяти сделало их бесполезными. Стандарт, таким образом, пережил аппаратное обеспечение, для которого он был разработан, и окончательно умер лишь с распространением 32‑битного ПО в эпоху Windows 95.
Мы имеем «Примечание:» и «Примечание 1:», но пропустили «Примечание 0:» в стремлении делиться знаниями.
Возможно, я вижу ещё один (признанно нишевый) сценарий использования AWE без PAE: если у вас 4 ГБ ОЗУ и GPU (или другое устройство) с, скажем, 2 ГБ собственной памяти, AWE позволил бы вам использовать обе максимально.
Без PAE суммарное физическое адресное пространство ограничено 4 ГБ, поэтому нет способа одновременно отобразить 4 ГБ системной ОЗУ и 2 ГБ видеопамяти в это пространство.
В некоторых случаях чипсет поддерживал только 32‑битное физическое адресное пространство, так что всё было ограничено суммарно 4 ГБ независимо от CPU или ОС. Я наблюдал это на материнской плате с процессором Pentium D и чипсетом Intel 945 — я загрузил ОС на основе FreeBSD, и она сообщила <4 ГБ общей памяти.
В ту эпоху было много ПК, которые показывали ровно 3,25 ГБ ОЗУ. Фактически они были 4‑гигабайтными машинами, работающими под 32‑битной ОС, и по каким‑то причинам материнская плата резервировала 768 МБ (=0,75 ГБ) окна для отображаемых устройств памяти (из которых, в подавляющем большинстве случаев, было только одно: видеокарта). Я не знаю, была ли эта величина окна частью какой‑то спецификации, но я видел много компьютеров с 3,25 ГБ ОЗУ и не припоминаю ни одного с другим значением.
Хм. Ладно, я этого не знал. Я предполагал, что у них будут отдельные отображения в виртуальном адресном пространстве.
Опасности привязки к типам-значениям в XAML.
Случай с обратным вызовом прогресса, который никогда не вызывался при наличии прогресса.
Получайте уведомления, когда публикуются новые записи.
Вы уверены, что хотите удалить это?