- Оперативная память больше 4 ГБ в 32-разрядных пользовательских версиях Windows
- Причины, которые могут мешать переходу на 64-разрядные версии Windows
- Отсутствие непосредственной поддержки унаследованного оборудования
- Финансовые затраты при смене версии Windows
- Тестирование работы Windows 7 x86 с ядром, поддерживающим до 128 ГБ оперативной памяти
- Использование физической памяти Windows 7 x86 с исходным ядром
- Использование физической памяти Windows 7 x86 с ядром ntkr128g.exe
- Сравнительное тестирование работы Windows 7 x86 с ядром ntkr128g.exe
- Стоит ли использовать Windows 7 x86 с модифицированным ядром (с поддержкой до 128 ГБ оперативной памяти)
- Еще раз про Windows и четыре гигабайта
- 64 разряда
Оперативная память больше 4 ГБ в 32-разрядных пользовательских версиях Windows
Здравствуйте уважаемые читатели блога www.ithabits.ru. Предлагаю вашему вниманию заключительную часть цикла статей о “приключениях” большой оперативной памяти в 32-битных системах.
Коротко повторю выводы, которые были сделаны в предыдущих публикациях этой темы:
Для приложений (программ) работа системы в режиме PAE не эквивалентна переходу на x64, так как они по-прежнему имеют доступ только к 4 ГБ виртуальной памяти (Часть 1).
Сегодня мы протестируем способность Windows 7 x86 работать с оперативной памятью больше 4 ГБ.
Наверное, можно было бы не делать отдельный пост и закончить все в прошлый раз, но очень не хотелось смешивать между собой варианты “= 4 ГБ” и “> 4 ГБ”. Во-первых, 4 ГБ является официально заявленным Microsoft лимитом физической памяти для клиентских версий. Во-вторых, очень важно было разобраться с адресным пространством в этом диапазоне и понять, что тут не так. А именно, почему 4 ГБ на самом деле не поддерживаются.
Причины, которые могут мешать переходу на 64-разрядные версии Windows
Стоит ли вообще пытаться сегодня заставить 32-разрядный Windows работать с оперативной памятью более отмеренных ей Microsoft 4 гигабайт? Не проще сразу перейти на 64-разрядную версию и обо всем забыть?
На моем основном компьютере установлена Windows 7 x64. Системой я полностью доволен, ну или почти всем доволен. Из раздела недовольств:
Отсутствие непосредственной поддержки унаследованного оборудования
У меня есть МФУ Canon LaserBase MF3110, которое, дай бог ему здоровья, до сих пор исправно выполняет свои функции. Однако, печатать на него напрямую из 64-битной Windows я не могу из-за банального отсутствия соответствующих 64-разрядных драйверов. Думаю, что их не будет уже никогда.
Точно такая же ситуация, даже еще хуже, со сканером Hewlett-Packard.
Чуть позднее я обязательно расскажу как можно выйти из положения с помощью виртуализации. Ну не выкидывать же в самом деле по причине отсутствия драйверов исправно работающее, пусть и не новое, оборудование.
Сегодня унаследованное оборудование является одной из причин, которая все еще тормозит переход на 64-битные операционные системы.
То обстоятельство, что по сравнению с x32 системы x64 занимают чуть больше места на диске и в памяти, вряд ли можно считать серьезным минусом, хотя об этом и любят упоминать. Зато они работают быстрее за счет более полного использования возможностей процессора.
Финансовые затраты при смене версии Windows
Еще одна причина, которая может помешать переходу на x64 тем, кто пока еще использует 32-битные версии Windows, является финансово-организационной. Возможно, она даже более веская, чем унаследованное оборудование.
Предположим, что некоторое время назад вы купили в магазине компьютер с предустановленной 32-разрядной версией Windows, а спустя некоторое время, по той или иной причине, приняли решение перейти на 64-разрядную. Очень хорошо, но как реально осуществить это решение?
Допустим, что вас совершенно не пугает процесс перестановки системы «с нуля” с сопутствующими ему и, надо сказать, не всегда удачными, переносом данных и программ.
Цена Windows x64 не отличается от Windows x86, но где ее официально взять и не платить при этом дополнительные деньги? Если честно, то я не знаю. Если кто-то знает, поделитесь. Могу предположить, что легитимное решение проходит все же через магазин. Если при этом учесть, что официально ОЕМ версии Windows поставляются только с новыми компьютерами и выбирать придется из более дорогих коробочных вариантов, то желание немедленно осуществить задуманный переход на x64 может заметно поостыть.
Хорошо совмещать переход на x64 со сменой компьютера, но она происходит не так уж часто.
Тестирование работы Windows 7 x86 с ядром, поддерживающим до 128 ГБ оперативной памяти
Сегодня в качестве тестовой лаборатории будет выступать настольный компьютер с процессором I7 и 6 ГБ оперативной памяти.
Так как система x64 в контексте темы нам не товарищ, а виртуальная машина также не спасет в силу того, что ей не получится отдать больше 4 ГБ памяти, придется специально установить 32-разрядную Windows. Давно хотелось протестировать возможность загрузки операционной системы с виртуального диска. Вот, как раз, очень подходящий случай эту возможность опробовать.
Процесс инсталляции “Windows 7 x86 Корпоративная” на виртуальный диск оказался не очень сложным. Единственное, что не получилось сделать в системе, работающей с виртуального диска, так это определить индекс производительности – начинает мерить, потом говорит, что не может закончить оценку производительности дисковой системы. Жаль, но нам сейчас это не актуально.
P.S. Появилась статья с подробным описанием вариантов установки Windows 8.1 на виртуальный диск.
Использование физической памяти Windows 7 x86 с исходным ядром
Частично повторим то, что делали при исследовании 32-разрядной Windows 7 с 4 ГБ физической памяти >
Здесь все достаточно ожидаемо. Из 6 ГБ доступно 3,24 ГБ, что составляет всего 54% от установленной физической памяти. Потери складываются из 4 – 3,24 = 0,76 ГБ на адреса устройств и 2 ГБ, обрезанных выше 4 ГБ.
А вот “Монитор ресурсов” говорит, что под оборудование зарезервировано 2,8 ГБ, но мы этому, естественно, не поверим и запустим утилиту MemInfo:
Использование физической памяти Windows 7 x86 с ядром ntkr128g.exe
Теперь еще раз совершим противоправные действия против Microsoft во имя науки и уберем в ядре операционной системы 4 гигабайтное ограничение. В силу того, что в результате наших экспериментов с ноутбуком у меня уже есть готовое “исправленное” ядро, я не буду больше запускать патчер, а просто скопирую его в новую систему и подключу в загрузке. Для этого нужно сделать следующее:
- Копируем нужное нам ядро “ntkr128g.exe” в папку C:\Windows\System32;
- Запускаем в командной строке с правами администратора bcdedit.exe без параметров и находим секцию, которая отвечает за загрузку системы с виртуального жёсткого диска (эту секцию я прописал на предыдущем шаге, когда настраивал загрузку Windows 7 с VHD). В моем случае из основной 64-разрядной системы это будет выглядеть так >
Если загрузить систему с VHD и проделать то же самое, то мы увидим аналогичную картину, но только пути всех “device” поменяются. То, что описано ниже, можно делать из любой системы;
- Во избежание ошибки запускаем “Блокнот”, копируем в него содержимое экрана через буфер обмена (экран командной строки –> правая кнопка мыши –> “Выделить все” –> “Enter” –> “Блокнот” –> “Правка/Вставить”) и сохраняем в произвольный текстовый файл. Собственно говоря, нас интересует “Идентификатор”.
- Создаем новую загрузочную запись путем копирования найденной и даем новое имя этому варианту. Используем теперь сохраненное в блокноте в обратную сторону для удобства подстановки идентификатора:
bcdedit /copy <5c2a7c3c-a04e-11de-9dac-b90d3342b585>/d «Windows 7 VHD 128» — естественно, в вашем варианте идентификатор будет совершенно другим.
Запустим еще раз bcdedit без параметра и убедимся, что новая запись появилась. Пока она ничем кроме имени не отличается от исходной.
- Новую запись надо дополнить:
bcdedit /set <5c2a7c3c-a04e-11de-9dac-b90d3342b585>kernel ntkr128g.exe – указываем, какое ядро нужно грузить;
bcdedit /set <5c2a7c3c-a04e-11de-9dac-b90d3342b585>testsigning Yes – в связи с тем, что контрольная сумма ядра у нас изменилась, говорим, что работаем в тестовом режиме;
bcdedit /set <5c2a7c3c-a04e-11de-9dac-b90d3342b585>pae ForceEnable – на всякий случай;
Смотрим, что получилось >
Запускаем новую систему и смотрим результат >
Судя по тому, что говорит о себе система, она теперь работает со всеми 6 ГБ физической памяти.
“Монитор ресурсов” сообщает, что под оборудование практически ничего не зарезервировано. Как мы теперь хорошо понимаем, на самом деле зарезервированы все те же 0,76 ГБ адресного пространства, но оно теперь не вычитается из установленного объема памяти (надо будет при случае посмотреть, как это место звучит в оригинале на английском языке. Возможно это “трудности перевода”).
Смотрим диапазоны зарегистрированной в системе памяти >
Как и ожидалось, добавился новый большой диапазон памяти выше 4 ГБ.
Сравнительное тестирование работы Windows 7 x86 с ядром ntkr128g.exe
Для того, чтобы развеять последние сомнения и подвести окончательный итог наших изысканий, запустим что-нибудь требующее много оперативной памяти. Самое первое, что приходит на ум, это виртуальные машины в VirtualBox. У меня уже есть несколько готовых виртуальных машин, созданных в основной рабочей системе с Windows 7 x64.
Наша тестовая система с Windows 7 x86 хоть и работает с виртуального диска, но ничего общего, кроме диска VHD, с виртуальной машиной не имеет. Она прекрасно видит все физические диски, которые установлены в моем компьютере, благодаря чему подключить готовые виртуальные машины в VirtualBox не составляет труда. Естественно, в новой Windows 7 x86 предварительно надо установить сам VirtualBox.
Назначим каждой виртуальной машине, скажем, по 1 ГБ памяти и начнем запускать их по очереди, сначала в исходной системе, которая видит лишь 3,24 ГБ, а затем в “скорректированной”.
В исходной системе удалось стартовать четырем виртуальным машинам, однако, как видно из представленного фрагмента экрана, на этом все и закончилось – “Unable to allocate and lock memory… Please close applications to free up memory…”. Виртуальные машины ни на что не реагировали и выключать их пришлось аварийно.
А теперь повторим наш экстремальный эксперимент в “скорректированной” Windows 7 x86 >
Как видно из представленного фрагмента экрана, запущены четыре виртуальные машины Linux, которым отведено по 1 ГБ памяти, и одна Windows XP с 512 МБ ОЗУ.
Можете мне поверить, можете проверить, но все замечательно работало. Я поочередно переключался в разные виртуальные системы и запускал в них имеющиеся приложения, параллельно запустил браузер на хосте – ни торможения, ни каких либо ошибок не наблюдалось. Не знаю, как вам, а мне понравилось.
Стоит ли использовать Windows 7 x86 с модифицированным ядром (с поддержкой до 128 ГБ оперативной памяти)
Рекомендовать со страниц блога использовать рассмотренный вариант увеличения доступной физической памяти для 32-разрядных пользовательских версий Windows я, естественно, не могу и не буду. Тому есть две веские причины:
- Нарушение лицензионного соглашения с Microsoft, причем как бы не в трех местах, а мы ничего нарушать не хотим. Конечно, при желании можно найти несколько смягчающих вину обстоятельств. Например, таких как, то, что стоимость однотипных версий Windows разной разрядности одинакова и своими действиями мы не наносим финансового вреда Microsoft. Или то, что при установке в компьютере памяти размером 4 ГБ надо еще посмотреть, кто кому и что должен – в лицензии поддержка такого объема заявлена, но, как мы теперь знаем, на самом деле ее нет. Но, все же, нарушение оно нарушение и есть. Будем считать, что все, что мы делали, было временным и на благо науки ;
- Нет никакой гарантии, что в вашем компьютере не используются устройства с “глупыми” драйверами, работа которых в режиме PAE с адресами физической памяти выше 4 ГБ приведет к краху системы.
Видимо придется закончить наше обсуждение секретов большой памяти в 32-битных операционных системах банальной рекомендацией – если планируете увеличить оперативную память компьютера до 4-х и более ГБ, или собираетесь приобрести новый компьютер с таким объемом памяти, задумайтесь о переходе на 64-разрядную операционную систему.
Ну если уж с x64 отношения не складываются категорически – читайте все еще раз внимательнее.
Еще раз про Windows и четыре гигабайта
Прошло несколько лет с тех пор, как была написана статья «Четыре гигабайта памяти — недостижимая цель?», а вопросов, почему Windows не видит все четыре гигабайта, меньше не стало. К числу вопрошающих добавились и обладатели 64-разрядных систем, которых эта проблема, казалось бы, не должна была коснуться. И стало ясно, что пора писать новую статью на эту же тему. Как и раньше, речь пойдет только об операционных системах Windows, причем в основном клиентских, то есть Windows XP, Windows Vista, Windows 7 и грядущей Windows 8. В некоторых случаях намеренно будут использоваться несколько упрощенные описания тех или иных аспектов. Это даст возможность сосредоточиться на предмете данной статьи, не вдаваясь в излишние подробности, в частности, внутреннего устройства процессоров и наборов микросхем (чипсетов) для системных плат. Рекомендуем предварительно прочитать указанную выше статью, так как не всё, сказанное в ней, будет повторено здесь.
Хотя теоретически 32-разрядной системе доступны (без дополнительных ухищрений) до 4 ГБ физической памяти, 32-разрядные клиентские версии Windows не могут использовать весь этот объем из-за того, что часть адресов используется устройствами компьютера. Ту часть ОЗУ, адреса которой совпадают с адресами устройств, необходимо отключать, чтобы избежать конфликта между ОЗУ и памятью соответствующего устройства — например, видеоадаптера.
Оперативная память заполняет адреса, начиная с нулевого, а устройствам, как правило, отводятся адреса в четвертом гигабайте. Пока размер ОЗУ не превышает двух-трех гигабайт, конфликты не возникают. Как только верхняя граница установленной памяти входит в ту зону, где находятся адреса устройств, возникает проблема: по одному и тому же адресу находятся и ячейка оперативной памяти, и ячейка памяти устройства (того же видеоадаптера). В этом случае запись данных в память приведет к искажению изображения на мониторе и наоборот: изменение изображения — к искажению содержания памяти, то есть программного кода или данных (скажем, текста в документе). Чтобы конфликты не возникали, операционной системе приходится отказываться от использования той части ОЗУ, которая перекрывается с адресами устройств.
В середине девяностых годов прошлого века для расширения доступного объема ОЗУ была разработана технология PAE (Physical Address Extension), увеличивающая число линий адреса с 32 до 36 — тем самым максимальный объем ОЗУ вырастал с 4 до 64 ГБ. Эта технология первоначально предназначалась для серверов, однако позже появилась и в клиентской Windows XP. Некоторые особенности реализации этой технологии в современных контроллерах памяти дают возможность не только использовать PAE по ее прямому назначению, но и «перекидывать» память в другие адреса. Таким образом, часть памяти, которая ради предотвращения конфликтов не используется, может быть перемещена в старшие адреса, например в пятый гигабайт — и снова стать доступной системе.
В обсуждении первой статьи было высказано замечание, что некорректно отождествлять наличие в контроллере памяти системной платы поддержки PAE — и способность платы переадресовывать память; что это вполне могут быть вещи, друг с другом не связанные. Однако практика показывает, что в «железе» для настольных систем это понятия взаимозаменяемые. К примеру, Intel в документации к своему набору микросхем G35 ни слова не говорит о возможности (реально существующей) переадресации памяти, зато подчеркивает поддержку РАЕ. А не поддерживающий PAE набор i945 не имеет и переадресации памяти. С процессорами AMD64 и последними моделями процессоров Intel дело обстоит еще проще: в них контроллер памяти встроен в процессор, и поддержка PAE (и ОЗУ размером более 4 ГБ) автоматически подразумевает поддержку переадресации.
Рисунок достаточно условный, переадресация совсем не обязательно выполняется блоками именно по одному гигабайту, дискретность может быть другой и определяется контроллером памяти (который, напомним, является либо частью оборудования системной платы, либо частью процессора). В программе BIOS Setup компьютера обычно бывает настройка, разрешающая или запрещающая переадресацию. Она может иметь различные наименования — например, Memory remap, Memory hole, 64-bit OS и тому подобное. Ее название лучше всего выяснить в руководстве к системной плате. Необходимо отметить, что если используется 32-разрядная система, то на некоторых системных платах, преимущественно достаточно старых, переадресацию необходимо отключать — в противном случае объем доступного системе ОЗУ может уменьшиться.
По умолчанию в Windows XP режим РАЕ был отключен, поскольку реальной надобности в нем не было (напомним, что в 2001 году типичный объем памяти настольного компьютера составлял 128—256 МБ). Тем не менее, если его включить, то ХР могла бы использовать все четыре гигабайта памяти — при условии, конечно, что системная плата поддерживала бы РАЕ. Но, повторим, реальной надобности включать этот режим в те годы не было. При желании читатель может для пробы установить на современный компьютер Windows XP или Windows XP SP1 (делать это для работы, конечно, не стоит), включить режим PAE и своими глазами убедиться, что системе доступны четыре гигабайта ОЗУ.
В 2003 году «Майкрософт» начала разрабатывать второй пакет исправлений для Windows XP (вышедший в 2004 году), поскольку столкнулась с необходимостью существенно снизить число уязвимостей в компонентах ОС. Одним из путей было использование предотвращения выполнения данных (Data Execution Prevention, DEP) — набора программных и аппаратных технологий, позволяющих выполнять дополнительные проверки содержимого памяти и в ряде случаев предотвращать запуск вредоносного кода. Эти проверки выполняются как на программном уровне, так и на аппаратном (при наличии соответствующего процессора). AMD назвала эту функцию процессора «защита страниц от выполнения» (no-execute page-protection, NX), а Intel использовала термин «запрет на выполнение» (Execute Disable bit, XD).
Однако использование такой аппаратной защиты требует перевода процессора в режим PAE, поэтому Windows XP SP2 при обнаружении подходящего процессора стала включать этот режим по умолчанию. И вот тут «Майкрософт» столкнулась с довольно серьезной проблемой: оказалось, что не все драйверы могут работать в режиме PAE. Попробуем пояснить эту особенность, не слишком углубляясь в устройство процессоров и механизмы адресации.
В Windows используется так называемая плоская модель памяти. Тридцать два разряда адреса обеспечивают обращение к пространству размером четыре гигабайта. Таким образом, каждой ячейке ОЗУ или ячейке памяти другого устройства соответствует определенный адрес, и никаких двусмысленностей тут быть не может. Включенный режим PAE дает возможность использовать 36 разрядов адреса и увеличить количество ячеек памяти в 16 раз. Но ведь система команд процессора остается той же самой и может адресовать только 4 миллиарда (двоичных) байтов! И вот, чтобы обеспечить возможность доступа к любому из 64 миллиардов байтов, указав только 32 разряда адреса, в процессоре включается дополнительный этап трансляции адресов (те, кого интересуют подробности, могут обратиться к специальной литературе — например, книге Руссиновича и Соломона «Внутреннее устройство Windows»). В результате 32-разрядный адрес в программе может указывать на любой из байтов в 36-разрядном пространстве.
Прикладных программ эта особенность никак не касается, они работают в своих собственных виртуальных адресах. А вот драйверам, которые должны обращаться к реальным адресам конкретных устройств, приходится решать дополнительные задачи. Ведь сформированный этим драйвером 32-разрядный адрес может после дополнительного этапа трансляции оказаться совсем другим, и выданная драйвером команда может, например, вместо вывода значка на экран изменить значение в одной из ячеек таблицы Excel. А если окажутся запорченными какие-либо системные данные, то тут и до аварийного завершения работы с выводом синего экрана рукой подать. Поэтому для успешной работы в режиме PAE драйверы должны быть написаны с учетом особенностей этого режима.
Однако поскольку исторически сложилось так, что до того времени в клиентских компьютерах PAE не использовался, некоторые компании не считали нужным поддерживать этот режим в написанных ими драйверах. Ведь оборудование, которое они выпускали (звуковые платы, к примеру), не предназначалось для серверов, и драйверы не имели серверной версии — так зачем без необходимости эти драйверы усложнять? Тем более, что для тестирования работы в режиме PAE раньше требовалось устанавливать серверную ОС и использовать серверное оборудование (системные платы для настольных компьютеров лишь относительно недавно стали поддерживать PAE). Так что разработчикам драйверов проще и выгоднее было просто забыть про этот PAE и обеспечить работоспособность на обычных клиентских компьютерах с обычными персональными, а не серверными ОС.
И вот с такими драйверами и возникли проблемы в XP SP2. Хотя количество фирм, драйверы которых переставали работать или даже вызывали крах системы, оказалось невелико, количество выпущенных этими фирмами устройств исчислялось миллионами. Соответственно, и количество пользователей, которые могли бы после установки SP2 получить неприятный сюрприз, оказывалось весьма значительным. В результате многие пользователи и сами отказались бы устанавливать этот пакет, и разнесли бы о нем дурную славу, что повлияло бы и на других пользователей. Они, хоть и без каких-либо веских причин, тоже отказались бы его устанавливать.
А необходимость повышения безопасности ХР компания «Майкрософт» ощущала очень остро. Впрочем, рассуждения на тему, почему мы увидели Windows XP SP2 и не увидели чего-то наподобие Windows XP Second Edition, выходят за рамки данной статьи.
Главное, что нас интересует, это то, что для обеспечения совместимости с плохо написанными драйверами функциональность PAE в SP2 для Windows XP была обрезана. И хотя сам этот режим существует и, более того, на компьютерах с современными процессорами включается по умолчанию, никакого расширения адресного пространства он не дает, просто передавая на выход те же адреса, которые были поданы на вход. Фактически система ведет себя как обычная 32-разрядная без PAE.
То же самое поведение было унаследовано Windows Vista, а затем перешло к Windows 7 и будущей Windows 8. Конечно, 32-разрядным. Причина, по которой это поведение не изменилось, осталась той же самой: обеспечение совместимости. Тем более что необходимость выгадывать доли гигабайта отпала: те, кому нужны большие объемы памяти, могут использовать 64-разрядные версии ОС.
Иногда можно услышать вопрос: если именно этот обрезанный режим PAE мешает системе видеть все четыре гигабайта — так, может, отключить его вовсе, чтобы не мешал, и, вуаля, системе станут доступны 4 ГБ? Увы, не станут: для этого требуется как раз наличие PAE, притом полноценного. Другой не так уж редко задаваемый вопрос звучит так: если устройства действительно мешают системе использовать всю память и резервируют ее часть под свои нужды, то почему же они ничего не резервировали, когда в компьютере стояло два гигабайта ОЗУ?
Вернемся к первому рисунку и рассмотрим ситуацию подробнее. Прежде всего отметим, что нужно четко различать два понятия: размер адресного пространства и объем ОЗУ. Смешение их воедино препятствует пониманию сути вопроса. Адресное пространство — это набор всех существующих (к которым может обратиться процессор и другие устройства) адресов. Для процессоров семейства i386 это 4 гигабайта в обычном режиме и 64 ГБ с использованием PAE. У 64-разрядных систем размер адресного пространства составляет 2 ТБ.
Размер адресного пространства никак не зависит от объема ОЗУ. Даже если вытащить из компьютера всю оперативную память, размер адресного пространства не изменится ни на йоту.
Адресное пространство может быть реальным, в котором работает сама операционная система, и виртуальным, которое ОС создает для работающих в ней программ. Но особенности использования памяти в Windows будут описаны в другой статье. Здесь же отметим только, что к реальному адресному пространству программы доступа не имеют — по реальным адресам могут обращаться только сама операционная система и драйверы.
Рассмотрим, как же в компьютере используется адресное пространство. Сразу подчеркнем, что его распределение выполняется оборудованием компьютера («железом») и операционная система в общем случае не может на это повлиять. Есть только один способ: изменить настройки оборудования с помощью технологии Plug&Play. О ней много говорили в середине 90-х годов прошлого века, но теперь она воспринимается как что-то само собой разумеющееся, и всё увеличивается число людей, которые о ней даже не слышали.
С помощью этой технологии можно изменять в определенных, заданных изготовителем, пределах адреса памяти и номера портов, используемых устройством. Это, в свою очередь, дает возможность избежать конфликтов между устройствами, которые могли бы произойти, если бы в компьютере оказалось два устройства, настроенных на использование одних и тех же адресов.
Базовая программа в системной плате, часто обобщенно называемая BIOS (хотя на самом деле BIOS (базовой системой ввода-вывода) она не является) при включении компьютера опрашивает устройства. Она определяет, какие диапазоны адресов каждое устройство может использовать, потом старается распределить память так, чтобы ни одно устройство не мешало другому, а затем сообщает устройствам свое решение. Устройства настраивают свои параметры согласно этим указаниям, и можно начинать загрузку ОС.
Раз уж об этом зашла речь, заметим, что в ряде системных плат есть настройка под названием «P&P OS». Если эта настройка выключена (No), то системная плата выполняет распределение адресов для всех устройств. Если включена (Yes), то распределение памяти выполняется только для устройств, необходимых для загрузки, а настройкой остальных устройств будет заниматься операционная система. В случае Windows XP и более новых ОС этого семейства данную настройку рекомендуется включать, поскольку в большинстве случаев Windows выполнит требуемую настройку по крайней мере не хуже, чем BIOS.
Поскольку при таком самоконфигурировании распределяются адреса памяти, не имеет никакого значения, сколько ОЗУ установлено в компьютере — процесс все равно будет протекать одинаково.
Когда в компьютер вставлено некоторое количество ОЗУ, то адресное пространство для него выделяется снизу вверх, начиная с нулевого адреса и дальше в сторону увеличения адресов. Адреса устройств, наоборот, выделяются в верхней области (в четвертом гигабайте) в сторону уменьшения адресов, но не обязательно смежными блоками — чаще, наоборот, несмежными. Как только зоны адресов, выделяемых для ОЗУ (с одной стороны) и для устройств (с другой стороны), соприкоснутся, становится возможным конфликт адресов, и объем используемого ОЗУ приходится ограничивать.
Поскольку изменение адреса при настройке устройств выполняется с некоторым шагом, определяемым характеристиками устройства, заданными изготовителем, то сплошной участок адресов для устройств получить невозможно — между адресами отдельных устройств появляются неиспользуемые промежутки. Теоретически эти промежутки можно было бы использовать для обращения к оперативной памяти, но это усложнило бы работу диспетчера памяти операционной системы. По этой и по другим причинам Windows использует ОЗУ до первого адреса памяти, занятого устройством. ОЗУ, находящееся от этого адреса и выше, останется неиспользуемым. Если, конечно, контроллер памяти не организует переадресацию.
Иногда задают вопрос: а можно ли повлиять на распределение адресов, чтобы сдвинуть все устройства в адресном пространстве как можно выше и сделать как можно больше памяти доступной системе. В общем случае без вмешательства в конструкцию или микропрограммы самих устройств это сделать невозможно. Если же руки все-таки чешутся, а времени не жалко, можно попробовать следующий метод: в BIOS Setup включить настройку «PnP OS» (она может или вовсе отсутствовать или называться по-другому), чтобы адреса для большинства устройств распределяла Windows, а затем переустанавливать драйверы, используя отредактированные файлы inf с удаленными областями памяти, которые, на ваш взгляд, расположены слишком низко.
В интернете можно найти разные советы, которые, якобы, должны дать системе возможность использовать все четыре гигабайта, основанные на принудительном включении PAE. Как легко понять из изложенного, никакого выигрыша это дать не может, поскольку не имеет значения, включен ли PAE автоматически или принудительно — работает этот режим в обоих случаях одинаково.
Может возникнуть также вопрос: а что будет, если установить видеоадаптер с четырьмя гигабайтами памяти. Ведь тогда получается, что система останется совсем без ОЗУ и работать не сможет. На самом деле ничего страшного не произойдет: видеоадаптеры уже довольно давно используют участок адресного пространства размером 256 МБ, и доступ ко всему объему памяти видеоускорителя осуществляется через окно такого размера. Так что больше 256 мегабайт видеоадаптер не отнимет. Возможно, в каких-то моделях размер этого окна увеличен вдвое или даже вчетверо, но автору в руки они пока не попадали.
64 разряда
Итак, с 32-разрядными системами мы разобрались. Теперь перейдем к 64-разрядным.
Вот уж тут-то, казалось бы, никаких подводных камней быть не должно. Система может использовать куда больше четырех гигабайт, так что, на первый взгляд, достаточно воткнуть в системную плату память и установить систему. Но оказывается, не все так просто. Прежде всего, отметим, что специального оборудования, предназначенного только для 64-разрядных систем, найти не удастся (мы говорим об обычных ПК). Любая системная плата, сетевая плата, видеоадаптер и пр., работающие в 64-разрядной системе, должны с одинаковым успехом работать в 32-разрядной.
А это означает, что адреса устройств должны оставаться в пределах первых четырех гигабайт. И значит, все ограничения, накладываемые на объем памяти, доступный 32-разрядной системе, оказываются применимыми и к 64-разрядной — конечно, в том случае, если системная плата не поддерживает переадресацию или если эта переадресация отключена в настройках.
Не поддерживают переадресацию системные платы на наборах микросхем Intel до 945 включительно. Новыми их, конечно, не назовешь, но компьютеры на их базе еще существуют и используются. Так вот, на таких платах и 64-разрядная, и 32-разрядная системы смогут увидеть одинаковое количество памяти, и оно будет меньше 4 ГБ. Почему меньше — описано выше.
С 64-разрядными процессорами AMD дело обстоит проще: у них контроллер памяти уже довольно давно встроен в процессор, и переадресация отсутствует только в устаревших моделях. Все процессоры для 939-контактного гнезда и более новые поддерживают больше 4 ГБ и, соответственно, умеют выполнять переадресацию памяти. То же самое относится к процессорам Intel семейств Core i3, i5, i7.
Впрочем, и тут может быть загвоздка: если на системной плате не выполнена разводка дополнительных адресных линий, то не будет и возможности обратиться к переадресованной памяти. А некоторые младшие модели системных плат для удешевления выпускают именно такими, так что необходимо смотреть описание конкретной системной платы.
И здесь нас поджидает сюрприз, подобный тому, с которым мы сталкиваемся в 32-разрядной системе: использование адресного пространства для работы устройств может ограничить объем памяти, доступный Windows.
Например, если системная плата поддерживает до 8 ГБ ОЗУ (скажем, использующая набор микросхем G35), и установить все эти 8 ГБ, то использоваться будут только ≈7—7,25 ГБ. Причина заключается в следующем: на такой системной плате разведены 33 линии адреса, что, с точки зрения изготовителя, вполне логично — зачем усложнять конструкцию, если больше 8 ГБ плата все равно не поддерживает? Поэтому даже если контроллер памяти сможет перекинуть неиспользуемый участок ОЗУ в девятый гигабайт, обратиться к нему все равно будет невозможно. Для этого потребуется 34-разрядный адрес, который физически нельзя сформировать на 33-разрядной системной шине. Точно так же на платах, поддерживающих 16 ГБ, Windows сможет использовать ≈15—15,25 ГБ и так далее.
С переадресацией связан еще один малоизвестный нюанс. Ограничение размера памяти, выполняемое в программе msconfig (или соответствующими настройками конфигурации загрузки) относится не к собственно величине памяти, а к верхней границе адресов используемой памяти.
То есть если задать эту величину равной 4096 МБ, то память, расположенная выше этой границы (переадресованная в пятый гигабайт, например), использоваться не будет, и фактически объем памяти будет ограничен примерно тремя гигабайтами. Эту особенность в некоторых случаях удается использовать для диагностики того, работает переадресация или нет. Например, автору встретился случай, когда на ноутбуке Windows использовала 3,75 ГБ из четырех, и было неясно: то ли не работает переадресация, то ли память используется на какие-то нужды. Установка флажка и ограничение размера памяти четырьмя гигабайтами привели к тому, что стали использоваться только 3,25 ГБ. Из этого можно сделать вывод, что переадресация работала, а четверть гигабайта, следовательно, использовалась для видеоадаптера или каких-то других целей.
Ну и напоследок стоит сказать о том, что даже при работающей переадресации и 64-разрядной системе несколько десятков или даже сотен мегабайт памяти все равно могут оказаться зарезервированными для оборудования. Причины такого резервирования лучше всего выяснить у изготовителя системной платы, но чаще всего можно предположить, что она используется для встроенных видеоадаптера или контроллера RAID.