16-битная сборка на 64-битной Windows?

Question

Я решил начать изучать ассемблер некоторое время назад, и поэтому я начал с 16-битной сборки, используя FASMW.Однако недавно я получил действительно новый компьютер под управлением Windows 7 64-bit, и теперь ни один из скомпилированных файлов .COM, которые собирает программа, больше не работает.они выдают сообщение об ошибке, в котором говорится, что .COM не совместим с 64-битными окнами.32-битные сборки все еще работают, но я бы предпочел начать с 16 и идти дальше ... Можно ли запустить 16-битную программу на Windows 7?или есть конкретный способ их компилировать?или я должен сдаться и перейти на 32-битный вместо этого?

Answer 1

Причина, по которой вы не можете использовать 16-разрядную сборку, заключается в том, что 16-разрядная подсистема была удалена из всех 64-разрядных версий Windows.

Единственный способ исправить это - установить нечто вроде DOSBox или пакет виртуальной машины, такой как VirtualBox, а затем установить FreeDOS в него.Таким образом, вы все равно получите настоящую DOS.( NTVDM не соответствует действительности DOS )

Лично я бы рекомендовал написать 16-разрядную сборку для DOS?Нет. Я бы использовал 32- или даже 64-разрядную сборку - причина в том, что существует разный набор вызовов функций для разных операционных систем (называемых ABI).Таким образом, ABI для 64-битных приложений Linux отличается от 32-битных.Не уверен, что это так с Windows.Тем не менее, я гарантирую, что значение прерываний, вероятно, отличается.

Кроме того, у вас есть все, что нужно учитывать в 16-битной сборке, например, используемая модель памяти.Я могу ошибаться, но я верю, что DOS дает вам 64 Кбайт памяти для игры «и все».Все, вся ваша куча и стек вместе с кодом должны вписываться в это пространство, насколько я понимаю, что заставляет задуматься, как что-либо вообще работало, на самом деле.

Answer 2

Мой совет - написать 32-битный код. Хотя вначале может показаться, что имеет смысл научиться писать 16-битный код, а затем «перейти» к 32-битному коду, на самом деле я бы сказал, что на самом деле все наоборот: написание 32-битного кода на самом деле проще потому что довольно много произвольных архитектурных ограничений (например, на то, что вы можете использовать в качестве базового регистра) в основном исчезли в 32-битном коде.

В этом отношении я считаю открытым вопрос о том, существует ли когда-либо реальная причина для написания 16-битного кода x86 вообще. Для большинства практических целей это мертвая платформа - для настольных машин она серьезно устарела, а для встраиваемых машин вы с большей вероятностью увидите такие вещи, как ARM или микросхемы PIC. Если вы не имеете в виду конкретную цель и не знаете наверняка, что это будет 16-битный x86, я бы, наверное, забыл, что он существовал, как и большинство остального мира.

Answer 3

32-битная Windows 7 и более ранние версии включают / включают NTVDM по умолчанию. На 32-битном Win8 + вы можете включить его в Windows Features .

В 64-битной Windows (или любой другой 64-битной ОС) вам необходим эмулятор или полная виртуализация.

Ядро в длинном режиме не может использовать режим vm86 для обеспечения виртуальной среды реального режима 8086. Это ограничение архитектуры AMD64 / x86-64.

При работающем 64-битном ядре единственный способ для вашего центрального процессора работать в 16-битном режиме - это 16-битный защищенный режим (да, это существует; нет, никто не использует его, и AFAIK основные операционные системы не предоставляют способ его использования). Или для ядра, чтобы переключить процессор из длинного режима обратно в унаследованный режим, но 64-битные ядра этого не делают.

Но на самом деле, при аппаратной виртуализации (VirtualBox, Hyper-V или любой другой, использующий Intel VT-x или AMD SVM), 64-разрядное ядро ​​может быть гипервизором для всей виртуальной машины , будь то Виртуальная машина работает в 16-битном реальном режиме или работает на 32-битной ОС (например, Windows 98 или 2000), которая, в свою очередь, может использовать режим vm86 для запуска 16-битных исполняемых файлов реального режима.

Особенно в 64-битном ядре, обычно проще просто полностью эмулировать 16-битный ПК (как это делает DOSBOX) , вместо того, чтобы использовать виртуализацию HW для естественного выполнения обычных инструкций, но перехватывать прямой аппаратный доступ (in / out, загрузка / сохранение в памяти VGA и т. Д.) И int инструкции, которые делают системные вызовы DOS / вызовы BIOS / что угодно.