Ms dos for windows 95

Опубликовано: 26.08.2020
Категории: [Софт]
Метки: [Windows 98], [Мой ретро-ПК], [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:\WINDOWS\COMMAND\display.sys con=(ega,,1)
Country=007,866,C:\WINDOWS\COMMAND\country.sys
Device=C:\WINDOWS\Himem.Sys
DEVICE=C:\WINDOWS\EMM386.EXE
DEVICE=C:\DOSDRV\OAKCDROM.SYS /D:MSCD001

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

mode con codepage prepare=((866) C:\WINDOWS\COMMAND\ega3.cpi)
mode con codepage select=866
keyb ru,,C:\WINDOWS\COMMAND\keybrd3.sys
SET winbootdir=C:\WINDOWS
SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND
SET TMP=C:\WINDOWS\TEMP
SET TEMP=C:\WINDOWS\TEMP
SET PROMPT=$p$g
SET BLASTER=A220 I5 D1 H5 P330 T6
SET CTSYN=C:\WINDOWS
C:\PROGRA~1\CREATIVE\DOSDRV\SBEINIT.COM
LH C:\DOSDRV\MSCDEX.EXE /D:MSCD001 /L:E
c:\dosdrv\mouse

Сохраняем настройки ярлыка. Теперь по его запуску система запросит перезагрузку и перед нами будет чистый и незамутненный 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 использовать можно, но осторожно — опять же можно потерять длинные имена файлов, если использовать его бездумно.

Добавить комментарий

Время на прочтение
5 мин

Количество просмотров 59K

MS-DOS в составе Windows 95 использовалась для двух целей:

• Она служила загрузчиком.
• Она выступала в качестве слоя совместимости с 16-битными драйверами.

Когда Windows 95 стартовала, сначала загружалась специальная версия MS-DOS, именно она обрабатывала ваш файл CONFIG.SYS, запускала COMMAND.COM, который выполнял ваш AUTOEXEC.BAT и в конце концов выполнял WIN.COM, который в свою очередь начинал процесс загрузки 32-битного менеджера виртуальных машин VMM.

Эта специальная версия MS-DOS была полностью функциональна в той мере, в которой слова «полностью функциональна» вообще применимы к MS-DOS. По-другому и быть не могло, при выходе в режим эмуляции MS-DOS только эта версия и оставалась работать.

Программа WIN.COM начинала загрузку того, что большинство людей называют собственно «Windows». Посредством копии MS-DOS она загружала менеджер виртуальных машин, считывала файл SYSTEM.INI, загружала драйверы виртуальных устройств, затем выключала EMM386 (если таковой был) и переключалась в защищённый режим. «Настоящая Windows» с точки зрения большинства людей — именно защищённый режим.

В защищённом режиме драйверы виртуальных устройств творили свою магию. В числе их действий было вытаскивание всего состояния MS-DOS, перевод его в состояние 32-битной файловой подсистемы и отключение MS-DOS. Все дальнейшие файловые операции направлялись в 32-битную файловую подсистему. Когда программа обращалась к int 21h, ответственной за обработку оказывалась 32-битная файловая подсистема.

Здесь вступает в игру вторая роль MS-DOS. Видите ли, программы и драйверы MS-DOS любили встраиваться в глубины операционной системы. Они могли заменять обработчик прерывания 21h, они могли патчить код системы, они могли заменять низкоуровневые дисковые обработчики int 25h и int 26h. Они могли также творить умопомрачительные вещи с прерываниями BIOS типа int 13h, ответственного за работу с дисками.

Когда программа обращалась к int 21h, сначала запрос направлялся в 32-битную файловую подсистему, где проходил некоторую предобработку. Затем, если файловая подсистема обнаруживала, что кто-то перехватил вектор int 21h, она переходила назад в 16-битный код, чтобы позволить перехватчику выполниться. Замена вектора int 21h идеологически похожа на сабклассинг окна. Вы получаете старый вектор и устанавливаете новый вектор. Когда установленный вами обработчик вызывается, вы что-то делаете, а затем вызываете старый обработчик. После возврата из старого обработчика вы можете ещё что-нибудь сделать, прежде чем вернуть управление.

Одним из 16-битных драйверов, загружавшихся из CONFIG.SYS, был IFSMGR.SYS. Его задачей было перехватить MS-DOS первым, прежде чем все остальные драйверы и программы получат свой шанс! Этот драйвер был в сговоре с 32-битной файловой подсистемой, возвращаясь из 16-битного кода назад в 32-битный, чтобы файловая подсистема могла продолжить свою работу.

Другими словами, MS-DOS была всего лишь исключительно искусной подсадной уткой. 16-битные драйверы и программы патчили и перехватывали обработчики, которые для них выглядели совсем как настоящая MS-DOS, но в действительности были приманкой. Если 32-битная файловая подсистема видела, что кто-то купился на приманку, она заставляла подсадную утку крякать.

Начнём с системы без «злобных» драйверов и программ, внедрившихся в MS-DOS.

Это рай. 32-битная файловая подсистема оказалась способной проделать всю работу, не взаимодействуя с надоедливыми драйверами, творящими причудливые вещи. Обратите внимание на дополнительный шаг обновления переменных состояния MS-DOS. Хотя мы и извлекли их в ходе загрузки, мы поддерживаем их в актуальном состоянии, поскольку драйверы и программы часто «знали» о них, обходили операционную систему и работали непосредственно с переменными состояния. Следовательно, файловая подсистема должна была поддерживать иллюзию ответственности MS-DOS (несмотря на то, что на самом деле MS-DOS уже не работает), чтобы такие драйверы и программы видели то, что ожидали.

Обратите ещё внимание на то, что переменные состояния разные для разных виртуальных машин. (То есть каждый открытый сеанс MS-DOS получал свою собственную копию переменных состояния.) В конце концов, у каждого сеанса MS-DOS была отдельная текущая папка, отдельная таблица файлов и тому подобное. Впрочем, всё это было спектаклем, потому что настоящий список открытых файлов хранился в 32-битной файловой подсистеме. Иначе и быть не могло, поскольку дисковые кэши должны были быть согласованы, а ограничения совместного доступа к файлам должны были проверяться глобально. Если один сеанс MS-DOS открыл файл для монопольного доступа, то попытка программы, работающей в другом сеансе MS-DOS, открыть тот же файл должна была завершиться с ошибкой.

Хорошо, это был простой случай. Сложный случай: у вас был драйвер, перехвативший int 21h. Я не знаю, что этот драйвер делает, допустим, это сетевой драйвер, перехватывающий ввод-вывод для сетевых дисков и обрабатывающий его как-то особенно. Предположим также, что какая-то TSR-программа, запущенная в сеансе MS-DOS, перехватила int 21h, чтобы печатать на экран 1, когда int 21h вызывается, и 2, когда int 21h завершается. Проследим обращение к локальному диску (не сетевому, так что сетевой драйвер ничего не делает):

Заметьте, что всю работу по-прежнему делает 32-битная файловая подсистема. Вызов проходит по всей 16-битной цепочке только для поддержания иллюзии ответственности 16-битной MS-DOS. В 16-битном мире выполнялся только код, установленный TSR и драйвером, плюс маленький кусочек IFSMGR, связывающий компоненты. Никакой код 16-битной MS-DOS не выполнялся. 32-битная файловая система перехватила у MS-DOS всю работу.

Аналогичный танец «перехватить нормальную работу, но позволить необычные действия, если кто-то попросил необычные действия» происходил, когда подсистема ввода-вывода принимала управление вашим жёстким диском от 16-битных драйверов устройств. Если подсистема распознавала драйверы, она собирала их состояние и обрабатывала все операции так же, как 32-битная файловая подсистема обрабатывала операции вместо 16-битной MS-DOS. С другой стороны, если подсистема не распознавала какой-то драйвер, она оставляла его ответственным за диск. Компонент, передающий команды из 32-битной среды 16-битному драйверу, назывался RMM.

Если вам не повезло использовать RMM для какого-то диска, вы, вероятно, заметили, что производительность операций с этим диском ужасна. Причиной тому использование старого неуклюжего 16-битного драйвера вместо быстрого многопоточного 32-битного. (Пока 16-битный драйвер обрабатывал одну операцию ввода-вывода, невозможно было обрабатывать другой ввод-вывод, потому что 16-битные драйверы не были рассчитаны на многопоточность.)

RMM, как ни странно, оказался полезен своей ужасностью, потому что его использование было ранним признаком заражения вашего компьютера MS-DOS-вирусом. В конце концов, MS-DOS-вирусы делали то же, что и TSR и драйверы: они перехватывали векторы прерываний и получали контроль над вашим жёстким диском. С точки зрения подсистемы ввода-вывода, они выглядели в точности как 16-битные драйверы жёсткого диска! Когда люди жаловались «Windows внезапно начала ужасно тормозить», мы направляли их на страницу производительности системы в панели управления и спрашивали, есть ли там строка «Часть дисков работает в режиме MS-DOS» или «Все диски используют режим совместимости с MS-DOS». Если есть, то за диски отвечал RMM, и если вы не меняли «железо», это, вероятно, означало вирус.

Наконец, некоторые части MS-DOS не имели отношения к вводу-выводу. Например, были функции выделения памяти, разбора строки с возможными шаблонными символами в формат FCB и тому подобные. Такие функции по-прежнему обрабатывались MS-DOS, поскольку это всего лишь функции «вспомогательной библиотеки» и ничего не выигрывали от переписывания в 32-битном коде, кроме возможности сказать «да, мы это сделали». Старый 16-битный код прекрасно работал, и использование готового кода позволяло сохранить совместимость с программами, патчившими MS-DOS с целью изменить поведение таких функций.

Первый комментарий к оригинальной статье: «Больше всего впечатляет, что бо́льшая часть этого бо́льшую часть времени действительно работала (в основном).»

It is useful to position Win95 in the marketplace.

The IBM-Microsoft agreement fully lapsed in 1993.12.31, which meant that IBM and Microsoft were largely free to go their ways with their DOS and Windows stuff. IBM had been free to market their DOS on the upgrade market at this stage, DOS 5.00.02 was the first, but 5.02, 6.10 and 6.30 were fairly successful. 7.00 had hit the market. OS/2 for Windows was doing a pretty good job at running Windows for DOS, so there was not dual royalties coming in for Win-OS2 and Windows. But in essence, IBM and DR-DOS were begining to take share from MSFT.

In order to kill the DOS upgrade market, it is necessary to demonstrate that the new windows is not a DOS application, but runs on its own bootsector, dos emulation, etc. Of course, it also needs to be compatible with the bulk of the DOS/Windows stuff out there. So, they built a DOS that allowed you to keep a ‘real’ dos (ie one bought in a box with DOS on the label), as well as have their ‘dos emulation’, (ie the MS-DOS 7 with the funny boot block).

Let’s be blunt about this. Win95 is MS-DOS 7.0 + Windows 3.95 + Win32s, with enough comingling of code that you can’t plug in DR-DOS 7.0 or PC-DOS 7.0, but not enough to prevent MS-DOS 7.0 running as a fully fledged OS on its own. Because it uses a different boot-sector to DOS, and is presented as a different OS, the WINBOOT.SYS proggie had to have the smarts to swap the boot to a pre-existing IBMBIO / IBMDOS or IO / MSDOS. They found out there were bugs in some apps that expected to see IBMBIO or IO in memory, and an IBMDOS/MSDOS > 1K. So they had to fiddle that too.

The version numbers are there to tell programs they’re running in DOS 7 and Windows 3.95, and you can’t use your DOS 6 or Windows 3.11 to upgrade me. Likewise, i’m not taking your Mouse 8.2 driver off you, but vers 9,0 is ok. The himem.sys happily reports as 3.95 or 3.99 under ME, but the himem services inside Windows is at 2.77.

MS-DOS 7.0 will run a version of Windows 3.11 in ‘separate application mode’. This is where you boot out of windows, and start in ‘native dos’. This is the main reason, for proggies like mscdex.exe (which have no use in Windows).

As with Windows 3.11, the pre-loaded DOS is actually run as a VxD, the DOS window you see actually comes from a program called ‘WINOLDAP.MOD’ or ‘WINOA386.MOD’. This passes calls down to Windows, which *might* pass them onto DOS. On the other hand, DOS in Win311 or Win9x, sees plenty of calls that start life in Windows, eg clock.exe.

That is, as Schuhmann notes in ‘undocumented DOS’, Win95 to all purposes and intent, is Windows 4.0 and DOS 7,0, with enough comingling of code to prevent DR-DOS from running. (eg, DR-DOS might not load LFN once windows is loaded).

The DOS emulation is not the same as in say, OS/2 or WinNT (which both use DOS 5)

In WinNT, DOS is a hacked former vm-application (like virtual pc), but the hardware calls (disk, screen, console), are now handled in the OS, rather than in a virtual system. IO.SYS and MSDOS.SYS are hacked to NTIO.SYS and NTDOS.SYS. There is a command.com, but this is not really loaded. Edlin.com, kbd16.com, and a number of other files are straight out of MS-DOS 5.0, and most of the stuff from MS-DOS 5 will run without mods in WinNT. NTDOS runs in a cmd.exe session, and command.com, if loaded, just passes calls down to the win32 command processor.

If you replace the Windows command processor with 4NT, and then load the NT command.com, it will pass all options supplied with internal commands that command.com knows of. So you can use extended 4nt switches for commands in command.com, but not extended commands. That is, ‘cd /d …’ works, but ‘cdd …’ does not.

In OS/2, DOSKRNL is ibmbio.com and ibmdos.com, in a single binary, which flicks calls out to the underlying OS. Likewise, there is krnlos2.exe for Windows, which does the same thing. Because the console api is not emulated in OS/2, you can run real games like civ1 in an OS/2 window. Because also, OS/2 DOS and OS2 sessions are separate, you don’t here OS/2 folk calling the command prompt a ‘dos window’. You have a ‘dos window’ for DOS apps, and an ‘os2 window’ for OS/2 apps.

OS/2’s command.com is a fully blown command.com. You can patch it to disable the version check (vers 14:2D = 20.45), and run it directly under Windows NT. Here is a sample.

E:\CDROM\COMMAND>dir /w

The volume label in drive E is DOS        .
The Volume Serial Number is 8B63:C8E8.
Directory of E:\CDROM\COMMAND

[.]             [..]            CMDP500.COM     CMDP501.COM     CMDP502.COM
CMDP545.COM     CMDP600.COM     CMDP610.COM     CMDP630.COM     CMDP632.COM
CMDP700.COM     CMDP701.COM     CMDP710.COM     CMDP401.COM     CMDM410.COM
CMDM401.COM     CMDM500.COM     CMDM501.COM     CMDM631.COM     CMDM805.COM
CMDM714.COM     CMDM713.COM     CMDM712.COM     CMDM701.COM     CMDM607.COM
CMDM600.COM     CMDM620.COM     CMDM621.COM     CMDM622.COM     CMDM717.COM
CMDM807.COM     CMDM550.COM     CMD.TXT
      33 file(s)    1833548 bytes used
                  299368448 bytes free

E:\CDROM\COMMAND>ver

The Operating System/2 Version is 4.50

E:\CDROM\COMMAND>

comment

Reviews

March 28th, 2016

A lot of games of the pre-Windows 95 era use so-called MS-DOS Extenders, which are libraries that provide a protected-mode environment to MS-DOS applications. The application is technically two programs glued together: The first program is the MS-DOS Extender itself, also known as the server, and the second program is the game that is a client of the MS-DOS Extender.

The interface that the client uses to talk to the extender takes a variety of forms. There were a handful of extenders that made up their own interface from scratch, but most extenders implement either the VCPI or DPMI interface. The main difference that mattered to me is that VCPI gives the application full control of the CPU at ring zero, which means that it cannot coexist with any other operating system. DPMI is a much friendlier interface to a host operating system, since it allows the host operating system to remain in control while still granting the client access to protected mode.

One nice feature of the DPMI extenders is that when they start up, they look to see if they are already running inside a DPMI extender. If so, then the extender shuts itself off and allows the client to talk directly to the existing DPMI extender. (In the case of a program running inside an MS-DOS virtual machine created by Windows, the existing DPMI extender is the Windows virtual machine manager.)

Now things get interesting: The client application was written with the assumption that it is using the MS-DOS extender that is included with the application, but in reality it is talking to the DPMI host that comes with Windows. The fact that programs seem to run mostly okay in spite of running under a foreign extender is either completely astonishing or totally obvious, depending on your point of view. It’s completely astonishing because, well, you’re taking a program written to be run in one environment, and running it in a different environment. Or it’s totally obvious because they are using the same DPMI interface, and as long as the interface has the same behavior, then naturally the program will continue to work, because that’s why we have interfaces!

In practice, the issues that arose with running under Windows DPMI instead of the built-in extender’s DPMI fell into a few categories, all due to differences between the implementations, despite both adhering to the documented interface.¹

One is virtual memory.

The built-in extender didn’t implement virtual memory, and client applications often use programming techniques that don’t work well in a virtual memory environment.

Virtual memory introduced latency that applications hadn’t been designed for. They would allocate memory and put an interrupt handler in it. This works fine if there is no virtual memory, but once you enable virtual memory, the memory for the interrupt handler might get paged out, and then bad things would happen, usually race conditions.

A more common programming pattern that falls down in the face of virtual memory is an application that simply allocates all the memory in the system and adds it to a memory pool. (As a bonus, the applications often initialize the memory as it was allocated.) If you have virtual memory, the client application can go a very long time before it runs out of memory because each “memory” allocation is really a disk allocation. This typically manifested itself by the application taking a long time to start up, accompanied by heavy disk activity as the operating system swapped out tons of pages until you ran out of disk space.

As I recall, we fixed this by setting a default policy for MS-DOS applications to limit EMS and XMS memory usage to the actual amount of physical RAM installed in the computer. (The DPMI memory quota defaulted to 8MB or a little bit less than physical memory, whichever is lower.) That way, these programs that try to allocate all the memory in the system would give up before the swap file spiraled out of control. This was the setting known as Auto in the memory properties page.

Bonus chatter: There was one program that not only allocated all the memory in the system and added it to a memory pool. Later during the execution of the program, it would ask for still more memory, and if the call succeeded, the program crashed!

¹These issues were called out in the DPMI documentation, but since the applications assumed that they were running under their built-in extender, they figured that the warnings in the DPMI documentation didn’t apply to them. It never occurred to them that their preferred DPMI extender would not actually be the one in charge.