В управлении памятью DOS верхняя область памяти ( UMA ) — это память между адресами 640 КБ и 1024 КБ ( 0x A0000–0xFFFFF) в IBM PC или совместимом компьютере. IBM зарезервировала верхние 384 КБ из 1024 КБ адресного пространства процессора 8088 для BIOS ROM , Video BIOS , дополнительных ПЗУ , видео RAM, RAM на периферийных устройствах, отображенного в память ввода-вывода и устаревшего ROM BASIC . [1]
Однако даже с видеопамятью, ПЗУ BIOS , видеобиосом , дополнительными ПЗУ и портами ввода-вывода для периферийных устройств большая часть этого 384 КБ адресного пространства не использовалась. Поскольку ограничение памяти в 640 КБ становилось все большим препятствием, были найдены методы заполнения пустых областей ОЗУ. Эти области назывались верхними блоками памяти ( UMB ).
Следующим этапом в развитии DOS стало использование операционной системой верхних блоков памяти (UMB) и верхней области памяти (HMA). Это произошло с выпуском DR DOS 5.0 в 1990 году. [2] Встроенный менеджер памяти DR DOS, EMM386.EXE , мог выполнять большую часть основных функций QEMM и сопоставимых программ.
Преимущество DR DOS 5.0 над комбинацией старого DOS и QEMM состояло в том, что само ядро DR DOS и почти все его структуры данных могли быть загружены в верхнюю память. Это оставляло практически всю базовую память свободной, позволяя создавать конфигурации со свободными до 620 КБ из 640 КБ.
Конфигурация не была автоматической — свободные UMB приходилось определять вручную, вручную включать в строку, которая загружала EMM386 из CONFIG.SYS , а затем драйверы и т. д. приходилось вручную загружать в UMB из CONFIG.SYS и AUTOEXEC.BAT . Эта конфигурация не была тривиальным процессом. Поскольку она была в значительной степени автоматизирована программой установки QEMM, эта программа выжила на рынке; действительно, она хорошо работала с собственной поддержкой HMA и UMB от DR DOS и стала одной из самых продаваемых утилит для ПК.
Эта функциональность была скопирована Microsoft с выпуском MS-DOS 5.0 в июне 1991 года. [2] В конечном итоге, еще больше структур данных DOS были перемещены из обычной памяти, что позволило оставить свободными до 631 КБ из 640 КБ. Начиная с версии 6.0 MS-DOS, Microsoft даже включила программу MEMMAKER , которая использовалась для автоматической оптимизации обычной памяти путем перемещения программ terminate-and-stay-resident (TSR) в верхнюю память.
В течение некоторого периода в начале 1990-х годов ручная оптимизация карты памяти DOS стала высоко ценимым навыком, позволяя запускать самые большие приложения даже на самых сложных конфигурациях ПК. Метод заключался в том, чтобы сначала создать как можно больше UMB, включая перераспределение выделенных, но неиспользуемых блоков памяти, таких как область монохромного дисплея на цветных машинах. Затем многочисленные подкомпоненты DOS должны были быть загружены в эти UMB в правильной последовательности, чтобы использовать блоки памяти максимально эффективно. Некоторые программы TSR требовали дополнительной памяти во время загрузки, которая снова освобождалась после завершения загрузки. К счастью, между этими модулями было мало зависимостей, поэтому их можно было загружать практически в любой последовательности. Исключениями было то, что для успешного кэширования CD-ROM большинство дисковых кэшей должны были быть загружены после любых драйверов CD-ROM, и что модули большинства сетевых стеков должны были быть загружены в определенной последовательности, по сути, постепенно проходя через уровни модели OSI .
Базовый, но эффективный метод, используемый для оптимизации обычной памяти, заключался в загрузке HIMEM.SYS как устройства, а затем в загрузке EMM386.EXE как устройства с опцией "RAM AUTO", которая позволяет получить доступ к UMA, загружая драйверы устройств как devicehigh. Этот метод эффективно загружает основные менеджеры памяти в обычную память, а затем все остальное в UMA. Обычные программы-обжоры памяти, такие как MSCDEX, также могли быть загружены в UMA аналогичным образом, тем самым освобождая большой объем обычной памяти.
Растущая популярность Windows 3.0 сделала необходимость верхней области памяти менее актуальной, поскольку приложения Windows не были напрямую затронуты ограничениями базовой памяти DOS, но программы DOS, работающие под Windows (при этом сама Windows выступала в качестве менеджера многозадачности), все еще были ограничены. С выпуском Windows 95 это стало еще менее актуально, поскольку эта версия Windows предоставляет большую часть функциональности драйверов устройств DOS для приложений DOS, работающих под Windows, таких как поддержка CD, сети и звука; карта памяти окон DOS Windows 95 была автоматически оптимизирована. Однако не все программы DOS могли выполняться в этой среде. В частности, программы, которые пытались напрямую переключиться из реального режима в защищенный режим, не работали, поскольку это не разрешалось в виртуальном режиме 8086, в котором они работали. Кроме того, программы, которые пытались выполнить переключение с помощью API Virtual Control Program Interface (VCPI) (который был введен, чтобы позволить программам DOS, которым требовался защищенный режим, переходить в него из виртуального режима 8086, настроенного диспетчером памяти, как описано выше), не работали в Windows 95. Поддерживался только API DOS Protected Mode Interface (DPMI) для переключения в защищенный режим.
Верхние блоки памяти могут быть созданы путем отображения расширенной памяти в верхнюю область памяти при работе в виртуальном режиме 8086. Это похоже на то, как расширенная память может быть эмулирована с помощью расширенной памяти , поэтому этот метод предоставления верхних блоков памяти обычно предоставляется менеджером расширенной памяти (например, EMM386 ). Интерфейс прикладного программирования для управления верхними блоками памяти указан в спецификации eXtended Memory .
На многих системах, включая современные, можно использовать память, зарезервированную для теневого ПЗУ карты расширения, как верхнюю память. Многие чипсеты резервируют до 384 КБ ОЗУ для этой цели, и поскольку эта ОЗУ обычно не используется, ее можно использовать как верхнюю память реального режима с помощью специального драйвера устройства, например UMBPCI. [3]
На компьютерах IBM XT можно было добавить больше памяти на материнскую плату и использовать пользовательский декодер адреса PROM , чтобы он появился в верхней области памяти. [4] Как и в случае с верхней памятью на основе 386, описанной выше, дополнительная RAM могла использоваться для загрузки файлов TSR или в качестве RAM-диска .
AllCard, дополнительный блок управления памятью для компьютеров класса XT, позволял отображать обычную память в адресном диапазоне 0xA0000-EFFFF, предоставляя до 952 КБ для программ DOS. Такие программы, как Lotus 1-2-3 , которые обращались к видеопамяти напрямую, нуждались в исправлении для обработки этой структуры памяти. Поэтому барьер в 640 КБ был снят за счет совместимости программного обеспечения. Такое использование верхней области памяти отличается от использования верхних блоков памяти, которое использовалось для освобождения обычной памяти путем перемещения драйверов устройств и резидентных программ в верхние 384 КБ адресного пространства 1 МБ , но оставляло объем адресуемой памяти (640 КБ) нетронутым.
[…] Одним из важнейших стимулов для добавления функций было конкурентное давление со стороны
DRDOS 5.0
, о котором мы впервые узнали весной 1990 года. Набор функций DRDOS побудил нас добавить поддержку
UMB
, обмен задачами и функцию Undelete. […] Значительная часть внимания руководства команды была отвлечена на новые функции, такие как программное обеспечение для передачи файлов, функция восстановления и сетевая установка […] В конце концов эта ситуация достигла критической точки в конце июля 1990 года, и под руководством
BradS
руководство команды провело серию напряженных совещаний, чтобы закрепить график и процесс закрытия проекта […](1+32 страницы)