CaptainFlint
Gold Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
metatrop
Цитата: И в серверных, и в несерверных. Если не перейти в режим PAE, то не поддерживается бит Data Execution Prevention (DEP/NX), а эта "антивирусная технология" доступна и в обычной XP.
В несерверных системах (без самопальных т.н. "PAE-патчей") ограничивается объём памяти. |
Там хитрее. Я же говорю, обширная и сложная область, и для общего обзора вполне можно давать упрощённую картину. Да, формально PAE был и в десктопных виндах, но по сути он не работал, а обеспечивал только вторичные функции. Связано это было с тем, что под десктопы драйверы писались без учёта PAE, и при попытке разрешить уходить за пределы 4 гигов такие драйверы начинают дружно падать, ибо не ожидают подобной подлянки. Заставить всех вендоров переписать драйверы — задача невыполнимая. Поэтому данная возможность была заблокирована, и ни одна десктопная 32-битная винда не поддерживает больше 4 гигов оперативки. Драйверы же, сертифицируемые под серверные системы, тестируются более продвинутым набором тестов, учитывающим функциональность в PAE-режиме. В них ограничения объёма памяти вызваны уже исключительно маркетинговыми соображениями, для разделения рыночных ниш. (Disclaimer: это то, что я слышал; сам всю эту информацию не проверял.)
Цитата:| Строго говоря, AWE - это просто выделение страниц на физическому уровне. Выделенные страницы становятся "Locked" и не могут быть сброшены в файл подкачки. На самом деле AWE не требует ни большого кол-ва памяти, ни включённого режима PAE. |
Возможно. Но даже если это так, это ничего не меняет. Я говорил об использовании AWE исключительно в контексте вопроса о доступе за пределы 4 гигов. Остальные его возможности только загромождают ответ, не добавляя ничего по сути заданного вопроса.
Цитата:| Не стали бы, наверное, но здесь специальной поддержки не требуется, само собой работает. |
Как оно может работать само собой, если в коде программы требуется 32-битными указателями обращаться к памяти за пределами 4 гигабайт? Разработчик должен явным образом управлять отображением верхней памяти в это окно, потому что только он знает, куда ему сейчас надо лезть. Конечно, можно придумать какие-нибудь библиотеки, использующие 64-битные указатели и автоматически конвертирующие обращения по ним в последовательность вызовов, смещающих окно и выполняющих обращение внутри этого окна по пересчитанному смещению. Но во-первых, переписать 32-битный код на использование 64-битных указателей — это тоже далеко не элементарная задача, особенно в сложном проекте. Во-вторых, такие автоматические конверсии могут прыгать по всему адресному пространству и окажутся жутко неэффективными, тогда как при ручной реализации разработчик будет учитывать эту особенность и группировать операции доступа, чтобы они как можно чаще находились в пределах одного окна, минимизируя сдвиги самого окна.
Цитата:| AWE работает и на обычной XP, и под VirtualBox. Единственное, что на XP/2003 сперва надо разрешить в политиках прав доступа "Lock Pages in Memory" (на Windows 7 x64 - уже не надо, сразу работает, равно как и на WinPE 2003 c DVD 2k10_Live из-под VirtualBox). |
Вопрос был не о том, работает ли AWE внутри виртуалки, а о том, сможет ли 32-битный VBox на 32-битной хостовой системе, в которой установлено больше 4 гигов памяти, запустить 64-битную гостевую операционку, выделив для этой гостевой системы больше 4 гигов памяти. Я писал о том, что для такого сценария разработчикам VBox'а пришлось бы использовать в своём коде AWE-механизмы, чтобы процесс VBox'а имел возможность управлять всем объёмом памяти, выделенным под гостевую систему.
----------
Почему же, ё-моё, ты нигде не пишешь "ё"? |
|
Всего записей: 5484 | Зарегистр. 11-11-2002 | Отправлено: 04:00 22-05-2022 | Исправлено: CaptainFlint, 04:03 22-05-2022 |
|
, но хочется и не сильно отставать от прогресса