Какой ms dos нужен для windows 95

Написать меня сей материал сподвигло практически полное отсутствие информации о том, как получить полноценный MS-DOS в Windows 95/98. Что бы был звук, мышь работала и игрушки тоже полноценно запускались. Пришлось собирать информацию по крупицам из разных источников и адаптировать под свои нужды.

Итак, дано: все тот же самый мой ретро-ПК и желание все же получить рабочий режим DOS для некоторых экспериментов. Тут стоит сделать оговорку, что полноценным он не будет никогда. Даже для некоторых игр начала 90-х этот компьютер слишком быстрый и стоит ждать различных сложностей. Например, игру Lotus 3 мне пришлось самому патчить через шестнадцатеричный редактор, что бы она заработала на моем компьютере. А если вести речь о совсем старых играх 80-х годов, то с ними были проблемы даже на 486-х системах, что уж говорить о моем Athlon XP (хотя тут есть обходной маневр — о нем в конце поста). Впрочем, MS-DOS для меня вторичен. Что мне нужно в принципе идет и под Windows 98. Но с другой стороны хотелось бы выжать максимум из этого компьютера, поэтому почему бы и DOS туда не запилить. Тем более, что в Windows 98 он все еще имеется и вполне полноценен для совместимости с играми.

Для начала надо будет сделать некие приготовления. Во-первых, нужны драйверы моей звуковой карты (а это Sound Blaster Live! 5.1) под DOS. К счастью они нашлись здесь. По идее они были на диске с драйвером для моей Live, но почему-то не хотели ставиться. Проще и быстрее было взять их по ссылке. Тем более, что сей архив с приятным бонусом. В нем включен драйвер для привода компакт-дисков и для мыши. Теперь начинаем творить магию.

Для начала распаковываем архив в любую удобную папку для вас. Содержимое папки PROGRA~1 можно сразу скопировать в Program Files. Как и содержимое папки WINDOWS (кроме файлов emm386.exe и himem.sys). Из корня архива файлы mscdex.exe, oakcdrom.sys и mouse.com копируем в папку c:dosdrv. Далее идем в меню «Пуск» и на рабочий стол (или в любое удобное для вас место) копируем ярлык «Сеанс MS-DOS».

Идем в его свойства на вкладку «Программа» и нажимаем кнопку «Дополнительно». Меняем настройки конфигурации сеанса DOS переключив опцию «Режим MS-DOS» на «Выбрать новую конфигурацию MS-DOS».

В поле для «файла» config.sys копируем вот это:

DOS=HIGH,UMB
device=C:WINDOWSCOMMANDdisplay.sys con=(ega,,1)
Country=007,866,C:WINDOWSCOMMANDcountry.sys
Device=C:WINDOWSHimem.Sys
DEVICE=C:WINDOWSEMM386.EXE
DEVICE=C:DOSDRVOAKCDROM.SYS /D:MSCD001

В поле для «файла» autoexec.bat копируем вот это:

mode con codepage prepare=((866) C:WINDOWSCOMMANDega3.cpi)
mode con codepage select=866
keyb ru,,C:WINDOWSCOMMANDkeybrd3.sys
SET winbootdir=C:WINDOWS
SET PATH=C:WINDOWS;C:WINDOWSCOMMAND
SET TMP=C:WINDOWSTEMP
SET TEMP=C:WINDOWSTEMP
SET PROMPT=$p$g
SET BLASTER=A220 I5 D1 H5 P330 T6
SET CTSYN=C:WINDOWS
C:PROGRA~1CREATIVEDOSDRVSBEINIT.COM
LH C:DOSDRVMSCDEX.EXE /D:MSCD001 /L:E
c:dosdrvmouse

Сохраняем настройки ярлыка. Теперь по его запуску система запросит перезагрузку и перед нами будет чистый и незамутненный MS-DOS. В котором, если вы все сделали правильно (при необходимости замените драйвер для звуковой карты на соответствующий вашей модели и пути к нему), будет работать звук, доступна поддержка CD-ROM и мыши. При желании можно еще поставить старый и добрый Norton Commander для пущего удобства и прописать команду его запуска в наш autoexec.bat в свойствах ярлыка.

Теперь важная ремарка. Если вы перезагрузите или даже выключите компьютер, то он все равно вернется в сеанс DOS. Для запуска Windows и последующей нормальной загрузки надо дать команду win и утвердительно ответить на вопрос системы.

P.S. Значительно повысить совместимость со старыми «досовскими» игрушками и софтом можно простым трюком. Надо выключить все кэши (L1 и L2) процессора в BIOS, и тогда даже мой Athlon XP+ 2400, становится по мощности примерно как 386-й процессор. Только делать это рекомендую после активации загрузки в DOS, иначе будут жуткие тормоза и ооочень долгая загрузка Windows. И помните, что файловые утилиты для MS-DOS даже в режиме эмуляции оного на компьютерах с Windows 9x использовать ни в коем случае нельзя. Как минимум, вы потеряете все длинные имена файлов! Особенно это относится к проверяльщикам диска, дефрагментаторам, оптимизаторам и прочему. Файловые менеджеры вроде Norton Commander использовать можно, но осторожно — опять же можно потерять длинные имена файлов, если использовать его бездумно.

DOSBox as a project generally targets games, and as such its built-in DOS implements only the subset of DOS used by games, which is mostly memory management (including XMS and EMS memory), high-level file system access (files and directories, not disk sectors, aside from the occasional PC booter) and process spawning. Other than that, games typically need access to sound, video and network hardware, with which DOS itself has little involvement. Windows 9x, on the other hand, requires a much larger and deeper API/ABI surface of DOS to function, some of which is very poorly documented and understood. As such Windows 9x is much more intimately tied to the version of MS-DOS it came with, unlike Windows 3.x, which can run pretty well even on DR DOS, despite Microsoft’s best intentions. It is for this reason that you need to install Windows 95 on a disk image and tell DOSBox to boot from it: so that the bundled version of MS-DOS is available to Windows, which provides the necessary interface.⁰ But then, because it was designed to run on real hardware and expects to read and write disk sectors directly, it will not be able to access directory mounts, which are normally provided by DOSBox.

And even with the right version of MS-DOS, DOSBox doesn’t emulate PC hardware with the necessary fidelity to allow Windows to run reliably, though an unofficial guide to make it work has been written. A fork, DOSBox-X, explicitly targets general DOS software and Windows 95, and provides much more stable hardware emulation. There is a thread on vogons.org detailing the improvements included in that fork. With the upstream DOSBox, I barely managed to run Windows 95 in Safe Mode (from a disk image), and even then it froze basically at first opportunity upon moving the mouse.

But what happens if you ignore all the above advice and attempt to start Windows from within DOSBox’s built-in DOS? When I followed the steps in the question, DOSBox exited and put this message in the log:

Exit to error: DOS:Illegal 0x33 Call  7

DOSBox terminates when it sees the guest attempt to invoke interrupt 0x21, service 0x3307. Here’s what Ralf Brown’s has to say about this call:

INT 21 — Windows95 — SET/CLEAR DOS_FLAG

• AX = 3307h
• DL = subfunction
  • 00h clear bit 5 of «DOS_FLAG»
  • 01h set bit 5 of «DOS_FLAG»

Return: ???

What is it supposed to do? I have no idea. RBIL has no idea. I presume DOSBox developers have no idea either, so they did not implement it. (There is actually a patch in the development branch which at least stops DOSBox from entirely exiting, but it is not part of any release yet.) Suppose, however, that it’s not actually very important: I can have a TSR turn it into a dummy call that does nothing. Is Windows 95 going to work then?

Windows 9x relies on MS-DOS to locate the Registry file. There is an actual dedicated system call for it. DOSBox, of course, does not implement it, triggering the error above. But that is also easily patched by a TSR, which can have it return a fixed path to SYSTEM.DAT. Will that make Windows work?

This informs us of the failure to start up the I/O Supervisor, which is basically Windows 9x’s disk driver layer. Despite the relatively reassuring error message, it is pretty crucial component, without which Windows will not be able to run. Getting it to work will be much harder than a quick-and-dirty one-off TSR: one will probably have to implement a substantial amount of DOS’s disk services, not just calls that provide high-level access to files and directories.

If we also intercept calls to interrupt 0x2f service 0x4a17 to capture the text that Windows tries to direct to BOOTLOG.TXT, we see this:

VTD stands for the Virtual Timer Device: this is a driver managing the system clock, and is also required to get Windows running. This driver fails to start because it depends on the underlying DOS providing the little-known CLOCK$ character device. Though somewhat obscure and rarely used, this device should be relatively easy to implement. DOSBox however doesn’t, since games make no use of it: if they ever need to read the system clock, interrupt 0x21 services 0x2a and 0x2c are just enough for their purposes.

None of those functionality gaps are inherently insurmountable (though getting IOS to work may be harder than the rest), but since they fall outside DOSBox’s scope, you should not expect DOSBox to cover them any time soon; upstream DOSBox developers are known to reject patches that don’t address problems with a specific DOS game (not general software, game). These issues are most probably not the only ones that prevent running Windows 95 under DOSBox’s DOS: they were just the ones easiest to discover. DOSBox is just the wrong DOS, and the wrong box.

⁰ It is also this bundled version of MS-DOS which produces the ‘Starting Windows 95…’ message, not the WIN.COM loader itself, as is implied by the question.

DOSBox as a project generally targets games, and as such its built-in DOS implements only the subset of DOS used by games, which is mostly memory management (including XMS and EMS memory), high-level file system access (files and directories, not disk sectors, aside from the occasional PC booter) and process spawning. Other than that, games typically need access to sound, video and network hardware, with which DOS itself has little involvement. Windows 9x, on the other hand, requires a much larger and deeper API/ABI surface of DOS to function, some of which is very poorly documented and understood. As such Windows 9x is much more intimately tied to the version of MS-DOS it came with, unlike Windows 3.x, which can run pretty well even on DR DOS, despite Microsoft’s best intentions. It is for this reason that you need to install Windows 95 on a disk image and tell DOSBox to boot from it: so that the bundled version of MS-DOS is available to Windows, which provides the necessary interface.⁰ But then, because it was designed to run on real hardware and expects to read and write disk sectors directly, it will not be able to access directory mounts, which are normally provided by DOSBox.

And even with the right version of MS-DOS, DOSBox doesn’t emulate PC hardware with the necessary fidelity to allow Windows to run reliably, though an unofficial guide to make it work has been written. A fork, DOSBox-X, explicitly targets general DOS software and Windows 95, and provides much more stable hardware emulation. There is a thread on vogons.org detailing the improvements included in that fork. With the upstream DOSBox, I barely managed to run Windows 95 in Safe Mode (from a disk image), and even then it froze basically at first opportunity upon moving the mouse.

But what happens if you ignore all the above advice and attempt to start Windows from within DOSBox’s built-in DOS? When I followed the steps in the question, DOSBox exited and put this message in the log:

Exit to error: DOS:Illegal 0x33 Call  7

DOSBox terminates when it sees the guest attempt to invoke interrupt 0x21, service 0x3307. Here’s what Ralf Brown’s has to say about this call:

INT 21 — Windows95 — SET/CLEAR DOS_FLAG

• AX = 3307h
• DL = subfunction
  • 00h clear bit 5 of «DOS_FLAG»
  • 01h set bit 5 of «DOS_FLAG»

Return: ???

What is it supposed to do? I have no idea. RBIL has no idea. I presume DOSBox developers have no idea either, so they did not implement it. (There is actually a patch in the development branch which at least stops DOSBox from entirely exiting, but it is not part of any release yet.) Suppose, however, that it’s not actually very important: I can have a TSR turn it into a dummy call that does nothing. Is Windows 95 going to work then?

Windows 9x relies on MS-DOS to locate the Registry file. There is an actual dedicated system call for it. DOSBox, of course, does not implement it, triggering the error above. But that is also easily patched by a TSR, which can have it return a fixed path to SYSTEM.DAT. Will that make Windows work?

This informs us of the failure to start up the I/O Supervisor, which is basically Windows 9x’s disk driver layer. Despite the relatively reassuring error message, it is pretty crucial component, without which Windows will not be able to run. Getting it to work will be much harder than a quick-and-dirty one-off TSR: one will probably have to implement a substantial amount of DOS’s disk services, not just calls that provide high-level access to files and directories.

If we also intercept calls to interrupt 0x2f service 0x4a17 to capture the text that Windows tries to direct to BOOTLOG.TXT, we see this:

VTD stands for the Virtual Timer Device: this is a driver managing the system clock, and is also required to get Windows running. This driver fails to start because it depends on the underlying DOS providing the little-known CLOCK$ character device. Though somewhat obscure and rarely used, this device should be relatively easy to implement. DOSBox however doesn’t, since games make no use of it: if they ever need to read the system clock, interrupt 0x21 services 0x2a and 0x2c are just enough for their purposes.

None of those functionality gaps are inherently insurmountable (though getting IOS to work may be harder than the rest), but since they fall outside DOSBox’s scope, you should not expect DOSBox to cover them any time soon; upstream DOSBox developers are known to reject patches that don’t address problems with a specific DOS game (not general software, game). These issues are most probably not the only ones that prevent running Windows 95 under DOSBox’s DOS: they were just the ones easiest to discover. DOSBox is just the wrong DOS, and the wrong box.

⁰ It is also this bundled version of MS-DOS which produces the ‘Starting Windows 95…’ message, not the WIN.COM loader itself, as is implied by the question.