2015-12-03 5 views
0

Обычно, когда вы запускаете DOS-программы в среде Windows, вы используете эмулятор DOS. Однако это медленное и жаркое решение с множеством ограничений. Идея меня поразила; не было бы более эффективным для CPU просто перевести/адаптировать машинный код, предназначенный для запуска в DOS, чтобы он работал в Windows? Есть ли какие-либо инструменты для выполнения этой работы, насколько вам известно?Есть ли инструменты для перевода машинного кода DOS в среду Windows?

Было бы возможно создать exe-файлы, которые могут работать как в DOS, так и в Windows. Это возможно благодаря тому, что все exe-файлы Windows из PE-формата содержат начальный DOS-заголовок, за которым следует DOS-код, который инструктирует компьютер показывать сообщение об ошибке, если файл запущен в DOS. Затем после DOS-кода следуют другие PE-заголовки, а затем код, совместимый с Windows. Можно было бы заменить DOS-код, отображающий сообщение об ошибке с реальным кодом из DOS-программы, а затем в коде, совместимом с Windows, который следует после PE-заголовков, вы можете разместить переводчик, который переводит DOS- кода, а затем передает ему выполнение.

Обратный, хотя и более сложный, также был бы возможен. Вы просто берете программу Windows и заменяете отображающий код dos-кодом кодом, который преобразует/адаптирует совместимый с Windows код в DOS-среду, а затем передает на него выполнение.

+0

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

ответ

0

В теории это возможно. На практике, я думаю, я видел только обратное: DOS Extenders, эмулируя подмножество Win32 API и позволяя простым приложениям Windows работать в DOS.

Есть две проблемы с DOS:

  1. все доступные (привилегированные инструкции, все/большинство аппаратных средств)
  2. он работает в режиме реального адресации от части времени, чтобы большую часть времени

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

x86 системы идут 64-бит. Это связано с недостатком процессора. Когда процессор находится в режиме 64-битного (AKA long), он больше не может выполнять 16-битный код в режиме реальной адресации или в режиме виртуального 8086. Совместимость для этого не была спроектирована или реализована в CPU (скажем, благодаря AMD и Intel). Таким образом, вы потеряете 64 бита и все, что требуется, или вы потеряете DOS. Существует аппаратная виртуализация (intel-VT/AMD-Pacifica), которая возвращает 16 бит, но для этого вам нужен гипервизор, и, поскольку нет никакой магии (гипервизор сам по себе не выводит два компьютера из одного) вам все равно нужно эмулировать/виртуализировать много вещей, которые делает DOSBox.

Нет дешевого и эффективного решения. Помимо отдельного старого ПК, предназначенного исключительно для материалов DOS. И их все труднее получить и поддерживать.

Я думаю, что вы сильно недооцениваете объем необходимой работы и сложность. Если вы не можете переписать программу, используйте эмулятор или виртуальную машину. Если вы можете, перепишите его для работы в Windows изначально. Другим вариантом может быть просто объединение DOSBox или некоторых из них с программой, что делает ее просто одной программой Windows, возможно, только одним .exe со всем внутри.

+0

Поскольку DOS-программы имеют доступ только к небольшому количеству памяти, даже в реальном режиме, я думаю, что было бы легко перенести эту память в виртуальный режим под Windows, так что память, доступная под DOS, будет использоваться одним приложением в виртуальном режиме в Windows. Я думаю, что прямой доступ к аппаратным средствам не будет проблемой, вы просто замените его различными API-функциями в Windows для доступа к аппаратным средствам. Я думаю, что перевод кода мог бы работать и в 64-битном режиме. Это будет классный проект. Я удивлен, что никто раньше не думал об этом гениальном решении. – user504882

+0

@ user504882 Программы DOS могут получить доступ к довольно небольшой памяти с помощью устройств himem.sys и DPMI. Что «API-функция в Windows» вы вызываете для «mov dword [0xb8000], eax» или для «out 0x20, al»? И вам не нужно сначала перехватывать и расшифровывать такие инструкции, даже не думая о Windows API? –

 Смежные вопросы

  • Нет связанных вопросов^_^