dosemu/dosbox/qemu+freedos.
Ну и поставь affinity на один процессор, что мешает.

dosbox

Но ведь это всё эмуляторы и будет эмулироваться процессор?

qemu умеет kvm, dosemu использует какие-то плюшки ядра и работает довольно низкоуровнево.

dosbox да, проц эмулирует. Хотя там тоже не все так просто.

Ты бы хоть написал, для каких задач нужно так извращаться.

dosemu

Но ведь это всё эмуляторы и будет эмулироваться процессор?

И не только процессор. В досе часто практиковалась запись в видеопамять напрямую, обращение напрямую к видеокарточке, различным портам в/в. Тут только эмулятор.

Скорее просто интересно.

А windows 95/98 тоже так делала?

95/98 - надстройка над досом)

Ты так говоришь, как будто это плохо.

dosemu — не эмулятор, это почти аналог режима MS-DOS из Win98.

DOSEMU — представляет собой ПО для создания слоя совместимости для запуска MS-DOS систем и их клонов таких как FreeDOS, а также DOS совместимого ПО под GNU/Linux на компьютерах x86 архитектуры (IBM PC-совместимые компьютеры).

представь себе, что сейчас единственный способ запустить, что нибудь досовское под офтопиком (хп и выше) это dosbox. и да чтобы запустить что нибудь досовское на реальном процессоре его нужно переключать в реальный режим работы (из 64 битного в 16 битный), уж лучше пусть в своей эмулированной песочнице работает так по надёжней будет да и по быстрее.

Вообще-то режим VM86 появился еще в i386. Или из AMD64 его выкинули?

Проблема в том что DOS - однозадачная ОС?

Проблема в том, что DOS-программа напрямую работала с кучей железа и сейчас проще сэмулировать то железо, чем разрешать ей трогать настоящее.

Проблема в том что DOS - однозадачная ОС?

ОС - да, но многозадачные приложения под DOS писались, это называлось DPMI.

А есть ли DOS-не эмуляторы, не знаю. Не нужно.

Работающий по принципу wine - нет.

Дело в том, что функция wine сводится к загрузке приложения вместе с библиотеками в память, после чего приложение работает, как нативное линуксовое (естественно, ему вместо виндовых разделяемых библиотек подсовываются виношные, реализующие маздайные апи, используя никсовые). Из этого, кстати, есть интересное следствие: из приложения под wine можно невозбранно вызывать любые линуксовые системные вызовы (так что если линуксоид бросает тебе экзешник, будь готов к rm -rf ~, даже если все виртуальные диски wine направлены только внутрь .wine).

Но на DOS-приложения такой подход распространить нельзя. Начнем с того, что они хотят реальный режим, а все современные ОС работают в защищенном. Поэтому «как в wine» невозможно.

А для практических нужд тебе хватит dosemu, dosbox и, в крайнем случае, виртуалок.

На 32-битных системах dosemu использует vm86 (виртуализация, что уже не как wine), а на 64-битных - полностью эмуляция.

А для практических нужд тебе хватит dosemu, dosbox и, в крайнем случае, виртуалок.

А чем DOSBox принципиально отличается от Qemu кроме наличия встроенного DOS? Это не то же самое что классический эмулятор + DOS-подобная операционка?

Технически - ничем. Просто удобнее: ты сразу и без извращений получаешь доступ к своей линуксовой ФС, и ты лишаешься необходимости руками ставить этот самый дос.

А может одно ядро специально работать в защищенном режиме?

Не понял вопроса. Под современными ОС все ядра работают либо в защищенном (32-бит), либо в длинном (64-бит) режиме.

А какой во всем этом смысл? Тебе не хватает производительности DosBox? А если хватает, зачем делать аналог Wine, когда уже есть эмулятор, полноценная песочница, в которой все можно настроить так, чтобы программы работали, а не делать хак-прослойку между глючной программой и глючным окружением?

А чем DOSBox принципиально отличается от Qemu

Умеет динамически управлять скоростью эмуляции. Это важно во многих старых играх (например Wing Commander, ЕМКНИП), где скорость игры зависит от скорости процессора.

То есть это просто полноценная виртуалка, как и Qemu, только ещё и с дополнительной фичей?

Кстати, ты уверен, что в qemu так нельзя?

То есть это просто полноценная виртуалка

Это неполноценная виртуалка :) Он заточен под игрушки, в первую очередь, поэтому то, что игрушкам не надо, или что сложно делается, или что отрицательно сказывается на производительности, не реализуется. Так, игрушкам печатать не надо, так что параллельный порт не эмулируется.

То есть одно ядро будет работать в реальном режиме (и то что нужно будет исполняться на нём) . Простите.

Half-life 1 тормозит же)

Так, игрушкам печатать не надо, так что параллельный порт не эмулируется.

не знаю как в досовых, но в виндовых игрушках встречал такое

Half-life 1 тормозит же)

так он под вайном отлично работает

А вот Colobots нет(

только ещё и с дополнительной фичей?

Ещё прямой доступ к дискам хоста, игра по «модему» в обычной сети (в игрушке настраиваешь игру через модем, а передача идёт по обычному TCP/IP), прозрачная трансляция IPX в UDP/IP.

Но ведь это всё эмуляторы и будет эмулироваться процессор?

Ты не поверишь, но для нормальной работы некоторых старых приложений нужен именно 386 процессор с тактовой частотой <200 Мгц. Про ошибку 200 слышал? Да даже при переезде хрюши с 32 битного проца на x86-64 часть виндовых приложений фактически накрылась медным тазом.

Допускает ли такое процессор технически - не знаю (вряд ли, но ручаться не могу, т.к. маны по реализации многоядерности в x86 пока не изучал).

Но даже если это возможно, то на практике не используется и никогда не будет использоваться абсолютно нигде.

Первая, и уже сама по себе более, чем достаточная причина: такое решение очень небезопасно. Запущенная программа имеет 100%-й доступ к любому харду. Помимо этого, программа может перейти в защищенный, длинный или нереальный режим и спокойно похерить всю твою память. Кроме того, одновременно ты сможешь использовать только одну программу, и не будешь иметь штатных средств ее прибить, помимо сброса.

Вторая: решение чрезмерно сложное и довольно-таки медленное (ты же хочешь дос-в-окошке, а не просто параллельный дос на твоем железе).

Третья: это не виноподобное решение. Требуется запуск на этом самом ядре с реальным режимом самого настоящего ДОСа.

Четвертая: это нафиг никому не нужно. На всех 32-битных процессорах есть vm86 - технология виртуализации, позволяющая иметь виртуализированный реальный режим и решающая все вышеупомянутые проблемы. В длинном режиме 64-битных процессоров эта функция недоступна, но там обычно доступны гораздо более серьезные и универсальные средства виртуализации: Intel VT либо AMD V. vm86 используется dosemu (только на 32-битных системах, на 64-битных используется эмуляция). Intel VT и AMD V используются KVM, VirtualBox и другими.

Так, игрушкам печатать не надо, так что параллельный порт не эмулируется.

Была в досе игрушка, ЕМНИП типа пазла, в которой можно было распечатать картинки на матричном принтере, причём для этого не требовалась установка драйвера принтера.

Ну вот соберутся фанаты этой игрушки и проспонсируют dosbox для реализации lpt. А пока эмуляция не предусмотрена, ибо остальным игрушкам не нужна.

386 процессор с тактовой частотой <200 Мгц

386 - 200МГц??? Да у них максимум 40 МГц.

Про ошибку 200 слышал?

Это та, которая по вине криворуких кодеров из борланда?

386 - 200МГц??? Да у них максимум 40 МГц.

Но ведь 40<200 :)

Это та, которая по вине криворуких кодеров из борланда?

Она самая - вычисление скорости по тактовой частоте и возможное деление на ноль на быстрых процах. Был патч для устранения ошибки в скомпиленных бинарниках, KB2 работает именно благодаря ему.

Ещё был какой-то ассемблерный хак, обошлось без Борланда, для Legend of the Evil Dragon который работает только при точной эмуляции 386 проца. Ошибка 2000 тоже случилась не из-за Борланда, нашлись другие любители экономии байтов.

Да там вообще без эмуляции никак будет. Ибо Linux никогда не был на 16 бит.

Был. ELKS.

Официальный порт, или так?