Виртуальная машина DOS

редактировать

Виртуальная машина DOS (VDM ) означает запуск 16-битной / 32-битной DOS под 32-битной Windows через КОМАНДА. COM.

Содержание

  • 1 Обзор
  • 2 Одновременный режим эмуляции DOS 8086
  • 3 VDM на основе DOS
  • 4 OS / 2 MVDM
  • 5 Windows NTVDM
    • 5.1 Команды
    • 5.2 Проблема безопасности
    • 5.3 Ограничения
  • 6 См. Также
  • 7 Примечания
  • 8 Ссылки
  • 9 Дополнительная литература
  • 10 Внешние ссылки

Обзор

Могут работать виртуальные машины DOS либо исключительно с помощью стандартных методов программной эмуляции (например, динамическая перекомпиляция ) или может полагаться на виртуальный режим 8086 процессора Intel 80386, который позволяет реальный режим Программное обеспечение 8086 для работы в контролируемой среде, перехватывая все операции, связанные с доступом к защищенному оборудованию, и перенаправляя их в обычную операционную систему (как исключения ). Затем операционная система может выполнить эмуляцию и возобновить выполнение программного обеспечения DOS.

VDM обычно также поддерживают выполнение программного обеспечения 16- и 32-bit защищенного режима (расширители DOS ), который должен соответствовать интерфейсу защищенного режима DOS (DPMI).

Когда программе DOS, запущенной внутри модуля VDM, требуется доступ к периферийному устройству, Windows либо разрешить это напрямую (редко) или представит программе DOS драйвер виртуального устройства (VDD), который имитирует оборудование с использованием функций операционной системы. VDM будет систематически иметь эмуляции для контроллеров прерываний Intel 8259A , микросхем таймера 8254, контроллера 8237 DMA и т. Д.

Concurrent Режим эмуляции DOS 8086

В январе 1985 года Digital Research вместе с Intel представили Concurrent DOS 286 1.0, версию Concurrent DOS, способную работать программы DOS реального режима в защищенном режиме 80286. Однако метод, разработанный на чипах процессора степпинга B-1, прекратил работу в мае 1985 года над процессором C-1 и последующими степпингами процессора незадолго до того, как Digital Research собиралась выпустить продукт. Хотя со степпингом E-1 Intel начала решать проблемы в августе 1985 года, так что Digital Research «режим эмуляции 8086» снова работал с использованием недокументированной инструкции процессора LOADALL, это было слишком медленно, чтобы быть практичным. Изменения микрокода для степпинга E-2 снова улучшили скорость. Эту раннюю реализацию можно рассматривать как предшественницу реальных виртуальных машин DOS.

В конце концов, Concurrent DOS 286 был преобразован из потенциальной настольной операционной системы в FlexOS 286 для промышленного использования в 1986 году. Он также был лицензирован IBM для их 4680 OS в 1986 году.

Когда Intel 80386 с его виртуальным режимом 8086 стал доступен (в виде образцов с октября 1985 года и в большом количестве с июня 1986 года), Digital Research переключилась на использование этого для работы в реальном режиме. Программы DOS на виртуальных машинах DOS в защищенном режиме под Concurrent DOS 386 1.0 (февраль 1987 г.) и FlexOS 386 1.0 (июнь 1987 г.). Однако архитектура этих многопользовательских многозадачных операционных систем с защищенным режимом сама по себе не была основана на DOS.

Concurrent DOS 386 позже был разработан, чтобы стать Multiuser DOS (с 1991 г.) и REAL / 32 (с 1995 г.). FlexOS 386 позже стала 4690 OS в 1993 году.

VDM на основе DOS

В отличие от этих операционных систем с защищенным режимом, DOS по умолчанию, представляет собой операционную систему реального режима, переключающуюся в защищенный режим и режим виртуального 86 только от имени менеджеров памяти и расширителей DOS, чтобы обеспечить доступ к расширенной памяти или преобразовать память в первый мегабайт, который доступен для обычных программ DOS.

VDM на основе DOS появились с Microsoft Windows / 386 2.01 в сентябре 1987 года. Виртуальные машины DOS на основе DOS также присутствовали в Windows 3.0, 3.1 x и Windows for Workgroups 3.1x работает в 386 Enhanced Mode, а также в Windows 95, 98, 98 SE и ME. Одной из характеристик этих решений, работающих поверх DOS, является то, что структура памяти, показанная внутри виртуальных машин DOS, представляет собой виртуальные экземпляры системы DOS, а конфигурация драйвера DOS запускается до загрузки многозадачности, и что запросы, которые не могут быть обработаны в защищенном режиме. передаются в системный домен для выполнения базовой системой DOS.

Подобно расширенному режиму Windows 3.x 386 в архитектуре, EMM386 3.xx из Novell DOS 7, Caldera OpenDOS 7.01, DR-DOS 7.02 (и более поздние версии) также использует модули VDM на основе DOS для поддержки упреждающей многозадачности нескольких приложений DOS, когда используется опция EMM386 / MULTI. Этот компонент разрабатывается в Digital Research / Novell с 1991 года под кодовым названием «Владивар» (изначально это был отдельный драйвер устройства KRNL386.SYSвместо модуля из EMM386). Хотя изначально он был разработан для следующей основной версии DR DOS, выпущенной как Novell DOS 7 в 1994 году, он также использовался в никогда не выпускавшейся DR DOS "Panther" и "Star Trek " проект 1992/1993 гг.

OS / 2 MVDM

VDM, называемые MVDM (множественная виртуальная машина DOS), используются в OS / 2 2.0 и позже с 1992 года. OS / 2 MVDM значительно больше мощнее, чем НТВДМ. Например, поддерживаются блочные устройства, и различные версии DOS можно загружать в OS / 2 MVDM. В то время как модуль OS / 2 1.x DOS был основан на DOS 3.0, OS / 2 2.x MVDM эмулируют DOS 5.0.

Полная интеграция Windows 3.1 и более поздних версий Win32s приложения в OS / 2 - это концепция, внешне похожая на бесшовную интеграцию XP Mode на основе Windows Virtual PC в Windows 7. Редиректор в «гостевом» VDM или NTVDM разрешает доступ к дискам OS / 2 или NT «хоста». Приложения в «гостевой системе» могут использовать именованные каналы для связи со своим «хостом».

Из-за технических ограничений приложения DOS и 16-битные Windows под OS / 2 не могли увидеть более 2 ГБ места на жестком диске, это было исправлено в ArcaOS 5.0.4.

Windows NTVDM

COMMAND.COM, запущенном в NTVDM Windows 8

NTVDM является системным компонентом всех выпусков IA-32 семейства Windows NT с 1993 года, что позволяет запускать 16-битную Windows и 16-битную / 32-битную Приложения DOS. Он не входит в 64-битные версии. 32-разрядный исполняемый файл пользовательского режима Windows NT, который составляет основу единой среды DOS (или Windows 3.x ), называется ntvdm.exe.

. Для выполнения программ DOS, NTVDM загружает NTIO.SYS , который, в свою очередь, загружает NTDOS.SYS , который выполняет измененный COMMAND.COMдля запуска приложения, переданного NTVDM в качестве аргумента командной строки. 16-битные системные файлы реального режима представляют собой урезанные производные от их эквивалентов MS-DOS 5.0 IO.SYS , MSDOS.SYS и COMMAND.COM с удаленными всеми аппаратными предположениями о файловой системе FAT и с использованием недопустимого кода операции 0xC4 0xC4 до bop в 32-битный NTVDM для обработки запросов. Первоначально NTDOS сообщала программам версию DOS 30.00, но вскоре это было изменено, чтобы сообщать о версии 5.00 при INT 21h / AH = 30hи 5.50 при INT 21h / AX = 3306h, чтобы позволить большему количеству программ работать без изменений. Это верно даже для новейших выпусков Windows; многие дополнительные функции и команды MS-DOS, представленные в версиях MS-DOS 6.x и Windows 9x, отсутствуют.

16-битные приложения Windows по умолчанию запускаются в собственном потоке в рамках одного процесса NTVDM. Хотя сам NTVDM представляет собой 32-битный процесс и выполняет многозадачность с упреждением по отношению к остальной части системы, 16-битные приложения в нем совместно выполняют многозадачность по отношению друг к другу. Когда опция «Запускать в отдельном пространстве памяти» отмечена в поле «Выполнить» или в файле ярлыка приложения, каждое 16-разрядное приложение Windows получает свой собственный процесс NTVDM и, следовательно, является многозадачным по отношению к другим процессам, включая другие 16-разрядные. битовые приложения Windows. NTVDM эмулирует вызовы и таблицы BIOS, а также ядро ​​Windows 3.1 и 16-битные заглушки API. 32-битный WoW уровень трансляции преобразует 16-битные процедуры API.

32-битная эмуляция DOS присутствует для интерфейса защищенного режима DOS (DPMI) и 32-битного доступа к памяти. Этот уровень преобразует необходимые вызовы расширенной и расширенной памяти для функций DOS в вызовы памяти Windows NT. wowexec.exe- это слой эмуляции, эмулирующий 16-битную Windows. Windows 2000 и Windows XP добавили эмуляцию Sound Blaster 2.0. 16-разрядные драйверы виртуальных устройств и драйверы блочных устройств DOS (например, RAM-диски) не поддерживаются. Межпроцессное взаимодействие с другими подсистемами может осуществляться через OLE, DDE и именованные каналы.

Поскольку виртуальный режим 8086 недоступен на других - Процессоры на базе x86 (более конкретно, MIPS, DEC Alpha и PowerPC ) Вместо этого NTVDM был реализован как полный эмулятор в эти версии NT с использованием кода, лицензированного Insignia SoftPC. До Windows NT 3.51 была доступна только эмуляция 80286. В Windows NT 4.0 была добавлена ​​эмуляция 486.

Команды

Следующий список команд является частью Подсистема Windows XP MS-DOS.

Проблема безопасности

В январе 2010 года исследователь безопасности Google Тэвис Орманди обнаружил серьезную уязвимость безопасности в Реализация VDM в Windows NT, которая позволила непривилегированным пользователям повышать свои привилегии до уровня SYSTEM, отмечена как применимая к безопасности всех x86-версий ядра Windows NT с 1993 года. Это включало все 32-разрядные версии Windows NT, 2000, XP, Server 2003, Vista, Server 2008 и Windows 7. Орманди опубликовал экспериментальный эксплойт для этой уязвимости. До выпуска исправления безопасности Microsoft обходным путем для этой проблемы было отключение поддержки 16-битных приложений, что препятствовало запуску старых программ (написанных для DOS и Windows 3.1). 64-битные версии Windows не пострадали, поскольку подсистема NTVDM не установлена ​​по умолчанию. После того как исправления безопасности Microsoft были применены к уязвимым операционным системам, VDM можно было безопасно снова включить.

Ограничения

В 16-разрядной подсистеме Windows XP существует ограничение (но не в более ранних версиях). из Windows NT) из-за повышенного предела для каждого сеанса для объектов GDI, что приводит к смещению дескрипторов GDI вправо на два бита при их преобразовании из 32 в 16 бит. В результате фактический дескриптор не может быть больше 14 бит, и, следовательно, 16-битные приложения, которые обслуживаются дескриптором больше 16384 из-за сбоя системы GDI, завершаются с сообщением об ошибке.

В x86-64 ЦП, виртуальный режим 8086 доступен как подрежим только в его устаревшем режиме (для работы 16- и 32-разрядных операционных систем), а не в собственном, 64 -bit длинный режим.

NTVDM не поддерживается в версиях Windows x86-64, включая программы DOS, потому что NTVDM использует режим ЦП VM86 вместо локальной таблицы дескрипторов, чтобы включить 16-битный сегмент, необходимый для адресации. и AAarch64, поскольку Microsoft не выпустила полный эмулятор для этого несовместимого набора инструкций, как это было в предыдущей несовместимой архитектуре. Однако их по-прежнему можно запускать с использованием программного обеспечения виртуализации, например Windows XP Mode в Windows 7, или путем установки NTVDMx64, неофициального порта более старой эмулируемой реализации. NTVDM, который был предоставлен на NT 4 для платформ, отличных от x86. Другой вариант - OTVDM (WineVDM), 16-битный интерпретатор Windows, основанный на эмуляции i386 MAME и 16-битной части популярного уровня совместимости Windows Wine.

В общем, VDM и аналогичные технологии не позволяют удовлетворительно запускать большинство старых игр DOS на современных компьютерах. Эмуляция предусмотрена только для самых основных периферийных устройств, зачастую реализованных не полностью. Например, эмуляция звука в NTVDM очень ограничена. Версии Windows семейства NT обновляют реальный экран только несколько раз в секунду, когда программа DOS пишет на нем, и они не эмулируют графические режимы с более высоким разрешением. Поскольку программное обеспечение в основном работает на скорости центрального процессора, все циклы синхронизации истекают преждевременно. Это либо заставляет игру работать слишком быстро, либо заставляет программное обеспечение даже не замечать эмулируемые аппаратные периферийные устройства, потому что оно недостаточно долго ждет ответа.

См. Также

Примечания

Ссылки

Дополнительная литература

Внешние ссылки

Последняя правка сделана 2021-06-18 03:34:49
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте