|
Ну, а как, по-вашему, передать в материнку адрес ячейки памяти с номером свыше 4294967295 по 32-разрядной шине? Тут никакая "светлая голова" не поможет.
В DOS было проще: и материнка с процессором, и ОС фактически поддерживали 4 МБ памяти (адресная шина позволяла), ограничивал только БИОС. Поэтому была возможность расширить пределы адресации с помощью дополнительных драйверов emm386.exe и himem.sys.
В 32-разрядных ОС уже обеспечена полная поддержка физических возможностей адресации всех 4 ГБ.
Другое дело - ограничение в доступных 3-3,5 Гб. Это связано с тем, что драйвера устройств работают на физическом уровне, с прямой адресацией, и занятые ими адреса отдавать для работы программ категорически не хотят. И программным путем это не обйти (разве что, использовать "дыры" - свободные области между адресами, занятыми устройствами, но эти "дыры" маленькие, сильно дефрагментированы и их использовать нерационально - пойдут тормоза при переадресации).
Как вывод: аналог emm386.exe и himem.sys в Винде есть, и он называется режимом PAE (Physical Address Extension). До версии Windows XP sp1 он был по умолчанию выключен, а при включении можно было получить доступ ко всем 4 ГБ (а не к 3 с копейками). Однако при этом при обращении к адресам свыше 3 ГБ могли быть конфликты с драйверами устройств, которые не желали отдавать свои адреса оперативке.
С версии Windows XP sp2 и выше, вплоть до Windows 7 и 8 PAE по умолчанию включен, но в урезанном виде - доступна память до самого нижнего адреса, используемого драйверами. Это ограничение введено именно для того, чтобы конфликты не могли возникнуть в принципе.
А больше этого (свыше 4 ГБ) не сможет обеспечить никакая, даже самая умная ОС, если она 32-разрядная (без аппаратной поддержки со стороны материнской платы с аппаратным диспетчером памяти, устанавливаемом на серверных платформах, благодаря чему серверные ОС могут работать и с более 4 ГБ, если, конечно, есть аппаратная поддержка).
Что касается последнего резерва - использования дыр памяти между драйверами.
В emm386.exe была такая фича - режим verbose, который сканировал память на наличие дыр и затем, при работе, отображал эти дыры в адресное пространство. Но практика показала, что из-за "дефрагментации" памяти - постоянного переключения маленьких окон - возникали тормоза, а выигрыш в увеличении объема памяти был незначителен. Так что режим verbose умные люди и не использовали, а оптимизировали память другими способами (например, перемещением драйверов в верхнюю память).
Так что Майкрософт на этот раз поступил правильно - не стал второй раз наступать на те же грабли и использовать "дыры", тем более, выигрыш составлял бы несколь сот мегабайт, а быстродействие и стабильность падали.
Так что обсуждать тут больше нечего - либо смиряемся с физическим пределом в 4 ГБ и фактичесим пределом в 3-3,5 ГБ, либо переходим на другую ОС - 64-битную либо (если материнка позволяет) на Windows Server (только учтите, если в материнке нет диспетчера памяти, то и Windows Server не спасет - будет видеть те же 3-3,5 ГБ)
|