Установка MS-DOS 6.22

Рыжий Тигра, ты ещё забыл указать, как именно MS-DOS выделяет память и почему в результате этого даже при свободных 600Kb может не запуститься программа занимающая всего 100Kb. Я не шучу.

 

Код:

Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  SYSTEM       4 189    (4K)    737 629  (720K)   4 294 23 (4

Значит Ваш mem сильно глючит. Используйте mem от freedos или map3.

Не пробовал, но dosdata.sys присутствует даже в QEMM9. Реального железа для dos у меня нет, в dosbox что-ли попробовать когда время будет?

На одной, так что уверен проблема именно в железе.

Вот видите, даже искать не пришлось пример программы, которая не понимает перемещение DOSDATA в umb. А адресс сегмента данных dos проще всего узнать через 21/52.

Да, действительно, нужная и полезная особенность.

Резидентная часть MSDOS 7.1 (с FAT32) больше резидентной части DOS 5/6 на десяток K, но это вобщем-то не имеет значения, т.к. большая часть все равно в HMA, которое традиционно использует только dos, а в основной памяти 7.x занимает меньше места, если не шаманить с DOSDATA. Основную часть winboot.sys занимает лого и intel plug&play manager который вызывается при DOS инициализации и после загрузки в памяти не присутствует.

Опять же, я никогда не видел программ, которые требовали больше 600K основной памяти. Те которым нужно больше использовали dpmi и dos-расширители, оверлеи или unreal-mode.

 

Штатный DOS-6.22'шный. :-) Вроде бы глючит не он - выпендривается сам QEMM, запихивая в поле длины блока памяти отрицательное число. Насколько сейчас помню, конечно, - когда-то заглядывал в заголовок блока, было весьма потешно.

Сенькс, гляну при случае.

Его и юзаю.

Не уловил. Нет под руками пофигусколькиразрядного писюка???

По идее - сработать не должно: он уже в виртуальном режиме, а интелский "микропроцессор для посудомоек" с его уродской архитектурой (сокращённый комплект привилегированных команд, разная длина команды в реальном и защищённом режимах и т.д.) не позволяет "дважды виртуализацию", как можно было на ЕСке в старом добром СВМ. :-(

Я видел две: какую-то простенькую, но красивую игрушку (без 620 кил не взлетала) и какую-то банковскую разгребалку авизовок (но там понятно - её автор был чудовищно ленив изучать DPMI). Да и сам наклепал для себя не один десяток мелких инструментальных софтинок, среди них были и безобразно прожорливые. :-)

---------- Сообщение добавлено в 14:06 ---------- Предыдущее сообщение размещено в 14:03 ----------

А-аа. Классика жанра: блоки выделяются подряд, соединяются в односвязный список и нет виртуальной адресации. В результате достаточно накрошить память на мелкие блоки и поудалять через один - и приплыли: всего свободной памяти дофига, но ни одного достаточно крупного кусочка. :-((((((

 

720K явно появилось не от отрицательного числа.

У меня только один x86 с mbr и тот казенный ноутбук с XP
Да vm и удобней.

dosbox не использует v86, только интерпретацию и если повезет динамическую рекомпиляцию.
Насколько я знаю, длина инструкций в реальном/защищенном режимах одинакова. Вот в 16/32 битных режимам один и тот же опкод, например 33 CC будет обозначать xor ax, ax в 16b и xor eax, eax в 32b. Возможно Вы имели ввиду это, а также префиксы переопределения размера операнда и адреса (66/67)? Но данная особенность никак не мешает эмуляции.

 

Это понятно. Но я не помню случаев, когда принципиально нельзя было бы настроить DOS 7.10 для их запуска.

См. выше — обычно несколько килобайт всё равно погоды не сделают.
И не надо упускать из виду, что уже намного позже, чем DOS 6.22, появилось множество драйверов мыши/кэшей/диспетчеров памяти, которые занимают места на порядок меньше, чем штатные. Так что весь выигрыш по памяти при их использовании нивелируется.
Offtop

Чиво-чиво?

 

Нет, конечно. В заголовке блока 0070:0000 в поле длина наверняка написано что-то вроде "B3A6". Буду перезагружаться под QEMM - проверю.

Нельзя переразметить винт и сделать в начале махонький, на пару гиг, :-) раздел с FAT16?

Хм? Насколько помню, своим быстродействием (сравнительно с полными интерпретаторами типа bochs'а) dosbox обязан именно прямому выполнению кода. Впрочем, доку по нему и какие-никакие сырцы я читал лет хорошо если лет пять назад, могу и спутать.

Я про команды с адресами и/или операндами: длина последних таки определяется битностью режима.

Эмуляция медленна, поэтому даже для одноуровневой виртуализации годится только как последний шанс.
ЕС ЭВМ работали интереснее.

Два режима - задачи и супервизора; команды одинаковы; попытка выполнить в режиме задачи т.н. "привилегированную" команду (чтение-изменение состояния проца, ввод-вывод, обращение к запертым областям памяти и, кстати, собственно переход из режима в режим) вызывали исключение (обработчик какового, ясен перец, работает в режиме супервизора).
А дальше просто: ядро (монитор виртуальных машин - МВМ, работающий в режиме супервизора) создаёт "виртуальную машину" (ВМ), которая загружает операционку - пофигу какую; ОС при загрузке себя выполняет в т.ч. и привилегированные команды типа "прочитать с носителя", каковые команды перехватываются и эмулируются МВМом. Окончательно загрузившись, ядро ОС (обычно) переходит в режим супервизора, этот переход тоже перехватывается МВМом и... процессор остаётся в режиме задачи! :-) А любая привилегированная команда (в т.ч. и попытка выяснить режим) по-прежнему перехватывается МВМом и подделывается. Непривилегированные же команды, которых подавляющее большинство, МВМ не дёргают и поэтому не тормозят.
А самый смак - под ВМ можно загрузить ещё одну копию МВМ, который будет работать совсем ка настоящий и сможет создавать ВМы второго порядка, под ними - третьего и т.д.

Интеловский проц так не умеет. :-((((((

Я знаю: основной код - в памяти защищённого режима, наружу в DOS торчит только несколько десятков байт команд передачи управления. Или, к примеру, эмуляторы отсутствующего "в железе" оборудования - "виртуальный" SB16 у меня был. Соответственно, без VM86 все эти штуки неработоспособны. :-(
А про размер всего ядра гамузом в dosbox'е я вообще скромно умолчу. :-)))))
Кстати, были и нехилые memory optimizer'ы без своей поддержки VM86 - qram, lastbyte... Приятные штучки и в среднем даже толковее, чем QEMM'ский optimize и тем более DOS'овский memmaker.

 

При чём тут VM86? CTMOUSE весит ≈5 кб, MOUSE.COM мне попадались и по 50. UIDE вообще сохраняет в основной памяти мизерную свою часть. Ну и так далее. Без всякого VM86.

 

Нет никакого mcb по адресу 70:0. Первый mcb в Вашем случае: 00146 112 (0K) LOADHI

Просто mem.exe так определяет размер IO сегмента:
00070 735 840 (719K) IO System Data
0B416 4 294 23 (419358 MSDOS System Data

Получить адрес DOSDATA (int 21/52), отнять 0x700: 0xB4160 - 0x700 = 735840

Где, на NAS с zfs или на рабочей машине с gpt? Я уже не говорю о корпоративном ноутбуке. Да и смысла нет.

Быстродействие и dosbox в одном предложении? Вам им приходилось пользоваться?
Впрочем, допускаю что он быстрее bochs, что угодно быстрее bochs.
Но самая быстрая dosbox core - dynamic (от dynamic recompilation) намного уступает qemu/vbox с вкюченной паравиртуализацией (прямое исполнение).

Разумеется, очень трудно загрузить в регистр 32 битное число если операнд имеет размерность в 16 бит. Но я повторяю, это никак не мешает эмуляции.

Вы только что описали, плюс-минус некоторые детали, работу win9x (win 3.11). При загрузке vmm32(virtual machine manager) инициализирует супервизор(ring0) и создает vm(ring3), в первой(system vm) запускаетcя ядро windows(krnl386/user/gdi/etc), которое обслуживает приложения, все последующие vm это dos машины. Более того нет теоретических препятствий для запуска vmm из vmm, MS не cтал делать vmm32 'честным' dpmi-клиентом чтобы улучшить производительность и упростить код.

 

А-аа. Так это ж не на порядок: обычный мышиный резидент - более-менее 15 кил. А этот поищу, гляну, что умеет. :-)
А дисковый кэш объёмом в пару-пятОк кил мне бы оч' и оч' пригодился.

Не уловил юмора ситуации. Имел в виду, что очень трудно корректно выполнить 16-битную команду загрузки константы в регистр в 32-битной среде - не, ну младшие 16 загрузятся, но в старшие-то улетит следующая команда. :-(((((((
Равно и наоборот - реальный режим не прикинется защищённым: команда с 32-битным операндом будет обработана криво, а в качестве следующей "команды" пойдёт выполняться старшая половина операнда. :-( А монитором виртуальных машин эмулировать почти каждую команду - лучше застрелиться. :-(

Таки не. DOS-машина выполняется в V86, а не в реальном режиме, и её попытка перейти в защищённый будет в лучшем случае остановлена, но никак не сэмулирована. Или таки можно запустить OS/2 или Linux как отдельный процесс в win95 и я что-то упустил? :-)))))))

Оставайся при своих, я не против...

 

Игрушки тем не менее прекрасно запускаются.

 

Ё-пс, глянул отладчиком - MCB таки нету. А mem откуда "знает", что после "IO System Data" должен идти "MSDOS System Data", а затем опять "IO System Data"? И считает смещения в 32-битной арифметике. Оттуда и длина в почти 4 гига.

---------- Сообщение добавлено в 18:32 ---------- Предыдущее сообщение размещено в 18:28 ----------

DPMI'йные? не проблема, '95 тоже предоставляет DPMI. А загрузить другую ОС поверх '95 - таки йок. И даже '95 поверх '95 - тоже йок. Это таки не ЕСка с ейным СВМ. :-(

 

Но ведь теоретически-то можно?

 

Ну. А СВМ под СВМом (часто было нужно для поиграться с новой версией, пока всё остальное обсчитывается под старой) уступал "голой" ЕСке редко когда пару процентов на чисто вычислительных задачах и обгонял - когда на полпорядка, а было и на на 4 порядка - на расчётах с вводом исходных данных с диска.

---------- Сообщение добавлено в 18:54 ---------- Предыдущее сообщение размещено в 18:50 ----------

Не проблема. Если непрерывно чесать код и заменять "неудобные" инструкции на безобидные. Но это таки dosbox со всеми его извратами, тормозами, несовместимостями и необходимостью подгонки операционной среды под уже готовые игры, а не честная аппаратная виртуализация.
Или тоже считаешь, что в 46-м посте я описал "мастдайку"? :-)

 

Да ну. Просто ставите префикс переключения режима и работаете с 16 битными командами. Например mov ax, 5 в 32 битном режиме будет 66 B8 05 00

Мне кажется Вы мешаете в одну кучу реальный/защищенный и 16/32 режимы.

Нет, все vm в win9x начинают свою работу в v86. Но они могут переключаться потом в PM16/PM32, что и делает krnl386 в system vm/dpmi-программа в dos машине. Почитайте Unauthorized Windows 95 А. Шульмана

Нет, но это особенности реализации. На i386 можно сделать рекурсивную виртуальную машину.

Я же Вам говорю, небезопасно полностью перемещать DOSDATA. Некоторые утилиты принимают по умолчанию, что IO начинается с 70:0 и за ним должен идти сегмент данных dos.

 

В дохренадцать лет назад скомпилированной игре с давным-давно погибшими исходниками, ага. :-(

Реальный - по жизни 16. А 16 защищённый ни на что толковое не годится, кроме того, в нём иначе работают как минимум команды загрузки сегментных регистров (которые к тому же тоже привилегированными не являются и исключений не вызывают) и отсутствует виртуализация адреса.

Чисто аппаратно, без программной эмуляции массовых команд и без чесания кода? Где можно посмотреть?

Ну так в моём случае он и лежит после - аж в UMB. Как раз из этих соображений?

 

Совершенно не понимаю о чем Вы говорите.

Многие программы в 80х - начале 90х использовали PM16, включая Borland (pascal/c) и Microsoft (windows 3.11/win9x). PM16 позволял адресовать 16M физической памяти и 1G виртуальной. Трансляция адресов осуществлялась с помощью сегментации, а не страничной адресации как обычно на i386.

Вот Вам выдержка из Intel 80386 Reference Programmer's Manual/Chap 17 MOV Move to/from Special Registers:

Код:

Loading a segment register under 80386 Protected Mode results in special checks and actions, as desc
IF SS is loaded;
THEN
   IF selector is null THEN #GP(0);
FI;
   Selector index must be within its descriptor table limits else #GP(selector);
   Selector's RPL must equal CPL else #GP(selector);
AR byte must indicate a writable data segment else #GP(selector);
   DPL in the AR byte must equal CPL else #GP(selector);
   Segment must be marked present else #SS(selector);
   Load SS with selector;
   Load SS with descriptor.
FI;
IF DS, ES, FS or GS is loaded with non-null selector;
THEN
   Selector index must be within its descriptor table limits else #GP(selector);
   AR byte must indicate data or readable code segment else #GP(selector);
   IF data or nonconforming code segment
   THEN both the RPL and the CPL must be less than or equal to DPL in AR byte;
   ELSE #GP(selector);
   FI;
   Segment must be marked present else #NP(selector);
   Load segment register with selector;
   Load segment register with descriptor;
FI;
IF DS, ES, FS or GS is loaded with a null selector;
THEN
   Load segment register with selector;
   Clear descriptor valid bit;
FI;

#GP это general protection exception, #NP - not present exception.

Например Nested KVM. Что Вы понимаете под 'чисто аппаратно'? Любой vmm эмулирует/обратывает как минимум привилегированные инструкции.
Более того в Вашей любимой СВМ аппаратная поддержка была опциональна:

"В наихудших случаях скорость обработки заданий на ВМ может уменьшиться в несколько раз, по сравнению с реальной ЭВМ. В связи с этим необходимы средства повышения быстродействия операционных систем, работающих на ВМ. Такие средства встраиваются и в МВМ, и в операционную систему ОС ЕС. Средства, встраиваемые в МВМ, позволяют повысить как эффективность работы СВМ ЕС в целом, так и быстродействие отдельных виртуальных машин. Первым, наиболее важным средством этого типа является микропрограммная поддержка СВМ ЕС. Это комплекс микропрограмм, дополнительный по отношению к базовому, которым оснащается конкретная модель ЕС ЭВМ. Предусмотрена возможность работы СВМ без микропрограммной поддержки. В этом случае необходимые функции реализуются подпрограммами МВМ, что как правило, оказывается во много раз медленнее."

Кстати о производительности виртуальных машин на ЕС:

"Единственное, что замечает пользователь при работе ОС ЕС на ВМ - это существенное замедление выполнения задания, по сравнению с работой ОС ЕС на реальной ЭВМ. Имеются два основных фактора, определяющих это замедление.
Первый фактор - в составе СВМ, как правило, работает не только та ВМ, на которой функционирует ОС ЕС, но и ряд других, также использующих ресурсы реальной машины, так что для ОС ЕС достается меньше времени.
Второй фактор связан с моделированием средствами МВМ привилегированных команд, выполняемых на ВМ, обработки прерываний, происходящих на ВМ, обслуживания виртуальной памяти и т.п. Для операционной системы ОС ЕС, характерной чертой которой является мультипрограммирование, т.е. одновременное выполнение нескольких задач, большое значение имеет прерывание из-за отсутствия в оперативной памяти страницы, к которой произведен запрос. Дело в том, что МВМ, обрабатывая данное прерывание, ставит в ожидание необходимой страницы всю ВМ в целом, тогда как на реальной ЭВМ в состояние ожидания попала бы только задача, затребовавшая эту страницу, а задачи, выполняющиеся параллельно с последней, могли бы выполняться и дальше. На ВМ же все эти задачи перейдут в состояние ожидания."

Отмечу, что сам я СВМ не пользовался, у нас в нии была старая ЕС1045 с мегабайтом памяти на ней и SVS со скрипом шла, но вышенаписанное больше похоже на правду чем Ваши:

Некоторые утилиты предполагают, что IO начинается с 70:0 и сразу за ним должен идти сегмент данных dos. Так понятней?

 

О предварительной подготовке кода к загрузке в ВМ путём дописывания префиксов к командам при отсутствии исходника.

Согласен - при ошибках генерируются исключения. Но при их отсутствии-то не генерируются - загрузка сегментного регистра не привилегированная операция! Т.е. перехватить и виртуализировать сегментные регистры можно только предварительно подпатчив код. :-(

Я неудачно выразился. Не модифицировать никакой код, предназначенный к выполнению на ВМ: ни её ОС, ни прикладуху.

Я знаю. Полезная вещь! :-) И никаких геморроев - всех делов-то после подачи питания загрузить микропрограмму не со штатной кассеты, а с СВМовской. (Я хоть и был системным программистом, но операторствовать тоже пришлось, по крайней мере в первые месяц-два.)
А кто запускал на ЕСке за день поочерёдно то СВМ, то MVT, не хотел переходить с MVT на БОС и ленился при переходе перезагружать микропрограмму - СВМовскую просто не грузил, но тогда кто этому злобному Пиноккио должен быть папой Карло? :-((((((

Так и без СВМ тоже ж на машине ходило сразу несколько программ и точно так же ресурсы разделялись между ними. Просто СВМ это делает эффективнее, не отдавая ресурс (периферийное устройство, блок ОЗУ или ещё какой кусок железа) в монополь одной задаче (а остальные отстаиваются в очереди на него), а расшаривая между.

А это хорошо или плохо? :-) Пока одна ВМ стоит - другие выполняются, делов-то. Кроме того, это не принципиальное архитектурное ограничение, а всего лишь действие по умолчанию; ОС, знающая о том, что её выполняют под СВМ, вполне могла договориться с МВМ о самостоятельной обработке ситуации. БОС (базовая операционная система, совместима с SVS) это умел и даже в случае чего мог полностью выползти из ВМ на реальную машину (режим V=R).
А грамотно распределить задачи между ВМами всё-таки проще, чем распределить память, проц и периферийные устройства между многими параллельно выполняющимися задачами. "Я сам проделывал это сотни раз" (L). :-)

Сочувствую. У меня на заводском ВЦКП были 1036, 1046 и немножко 1055, нигде меньше четырёх метров не было, СВМ на них ходил как ляля - на 8-метровой 1046, к примеру, под ПДО сидели одновременно более-менее полсотни пользователей и помех друг от друга не испытывали. :-)

Может, автор статьи просто привык к MVT или SVS, с самого начала сопротивлялся установке СВМ и потом либо не работал на нём, либо работал из-под палки? У нас такие тоже были, палки в колёса вставляли на всех уровнях - от порчи резервных копий системы до ябед директору о перерасходе бумаги и электроэнергии из-за снижения простоев АЦПУ и дисководов. :-) Но поскольку сопровождали СВМ не они, а мы, энтузиасты, то узкие места расшивались быстро и красиво, а пропускная способность ВЦ выросла за год хорошо если не впятеро.
Кстати, насчёт четырёх порядков - я не шучу. Была задачка, что-то вроде расчёта карты загрязнений атмосферы, исходные данные - файлик на полста с гаком тыщ строк, время расчёта под MVT - 5-7 часов, периодичность расчёта - дважды в сутки. Первый же её пробный запуск со вчерашними данными на ВМ с БОС закончился через полторы процессорных секунды и примерно 4-5 секунд реальных; сравнили результат (несколько сотен листов распечатки; сравнивали, ясен перец, не с бумаги глазами, а файлы в спуле) со специально сохранёнными результатами, полученными накануне под MVT, - совпало. В конце концов разобрались: строки исходных данных считывались много раз вразброс, MVT тупо молотил головками, а БОС кэшировал. И потом подобных задач приносили новых каждую неделю, так что не я один стал энтузиастом СВМ. :-)

Ну. В моём случае - тоже сразу, просто IO несколько непривычно крупноват... :-)))))))
Кстати, а какие именно утилиты? Надо будет при случае глянуть. Ни разу не видел утилиту, которая бы систематически падала/глючила именно при dosdata=high.

 

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

Вопрос: каким боком линейка ЕС имеет отношение к установке МС-ДОС ?

 

(огрызается) Не я её писал. И туеву хучу коммерческих тормозных программ, требующих всё более и более дорогостоящего железа, тоже не я.

:-) Исторически развилась из общего трёпа о виртуализации, каковой, в свою очередь, начался c DOSBox'а с QEMM'ом. :-)

 

Исключение генерируется когда в сегментный регистр загружают некорректный дескриптор (не содержащийся в GDT/LDT), так как этих дескрипторов обычно всего несколько дюжин и они нумеруються по порядку, то практически любая запись в регистр будет вызывать исключение. Но я все еще не слишком понимаю зачем это нужно.
Возможно Вы пытаетесь найти способ запустить 16 бит код в 32-бит режиме? Это малореально. Множество технических проблем да и нет особых выгод.

Значит все еще проще, куда не ткнись, везде рекусивная vm. Например virtualbox, dosbox (если запустить в нем win9x а в ней вторую копию dosbox или через hxdos).

Да так как свопилась не одна задача а целая vm, на медленное ЗУ.

Готов поверить, что с управлением ресурсами в СВМ было легче, особенно по сравнению с MVT. У нас ради этого рискнули перейти на SVS, хотя памяти было впритык.

Существует феномен аномальной производительности виртуальных машин. Но проявляеться он только на IO интенсивных задачах (диск медленный и хорошо сериализуеться, не говоря уже о пользователях) и только если гостевая OS не умела кешировать/разделять доступ сама. Сейчас это уже не актуально. Оверхед же от переключения гость/супервизор никуда не делся.

К сожалению конкретной утилиты я не знаю. Я читал о двух сценариях. Первый, утитита поставляемая с dos использует сегмент 70:X для доступа к данным в IO/DOSDATA, т.е. читала данные по указателю 70:8 из IO и по указателю 70:800 из DOSDATA. Звучит глупо, но от MS можно ожидать. Второй сценарий, старые программы вроде sidekick или portofentry сканируют память от 70:0 до первого mcb в поисках сигнатур, чтобы найти DOSDATA. также звучит довольно глупо, но эти программы создавались до dos в HMA и во время недокументированной 21/52. И что самое главное, этот метод описан в DOS энциклопедии и я находил описанную сигнатуру (36 F6 06 20 03 FF 75 0C 36 FF 36 58 03 CD 28) в DOS 5/6/7.