Комментарии 74
А ядро «NT OS/2», как известно, создавалось с нуля, хоть и с оглядкой на существующие системы (VMS, OS/2, и прочие)
The Vista of DOS
There are interesting parallels between Windows Vista and DOS 4.0. Like Windows Vista, DOS 4.0 was highly unpopular for many reasons. Like Vista, DOS 4.0 was often considered less preferable than the previous version (DOS 3.3/Windows XP) until the successor version (DOS 5.0/Windows 7), not radically different, won the hearts and minds of the press and users.
As with Vista, the software compatibility issues were hammered out by vendors, and by the time the next version came out, everything just worked. Not so much because the new version magically solved all problems, but rather because incompatibilities had been quietly fixed while the world wasn’t paying attention.
And much like with Windows 7, the resource requirements of DOS 5.0 seemed modest in 1991, while similar requirements of DOS 4.0 had been deemed outrageous in 1988. High memory support in DOS 5.0 relieved much of the conventional memory pressure, but it also required at least a 286. By the time DOS 5.0 was released, the the typical system was in fact a 286 or better, but that had not been the case when DOS 4.0 was released.
Хочу заметить что и «обычный» MS DOS 4.0 нес много изменений и неплохо ломал совместимость
а можно делатли?
как мне помнится, писать программы, совместимые со всеми версиями старше 3.3, было несложно.
С появлением 386-х процессоров задача виртуализации DOS была решена фактически аппаратно, и страшилки из книг так и остались страшилками, — смешно и обидно одновременно. Статьи вроде этой — прям как бальзам на душу. И интересно, само собой.
Последний раз писал напрямую на Спектруме, но там собственно вариантов было мало.
На х86 сразу int10 и собственно без вариантов. Уж слишком разнообразный был зоопарк видиков, даже в те исторические времена.
Вот пытаюсь сейчас вспомнить когда бы это было реально, но не могу. Сразу как в х86 познакомился — зоопарк был разнообразный.
Нет, реально, тогда всё было другое. Как в «Песня о программистской молодости» от YuN (а он еще и поет).
И да, мы действительно тогда мало чего боялись. И всяких там несовместимостей в первую очередь.
Но все равно не припомню чтобы вот так писать напрямую.
Конечно это был редкостный лапшекод на бейсике, но не суть. Мне было 9, Вам 15, так что осмелюсь предположить что в то время это для Вас было тоже хобби как и для меня.
Тут скорее больше влияет кто с каким парком сталкивался и какие задачи решались.
Для меня три вида карточек тогда казались большим зоопарком, а работа через инт10 в сравнении с родным для меня спектрумом — очень быстрой.
ПЫСЫ: а вообще я не спорю. Думаю если бы я не ограничивался фаном от того что я на спектруме в интерпретируемом бейсике собрал леталку-стрелялку, или «круто я пишу на ассемблере», а писал всё это на продажу, то вероятно я бы таки да уперся в скорость и прочее.
Но реально под простые игрушки (тем более на черно-зеленых мониторах) и под вывод разных графиков для расчетов вполне хватало инт10. Я бы если не это обсуждение и не узнал о том, что оно дескать медленное… :)
У меня «Спектрума» не было, зато в 1989-м я программировал на уже упоминавшемся тут «Поиске», и его неполноценную реализацию CGA познал на практике. А через 6 лет зоопарк различных SVGA не вызывал удивления — на дворе-то стоял 1995-й год. Ассемблер я тогда уже забросил, не до него было.
У IBM PC очень стандартное железо и это породило потом очень много проблем с совместимостью. Даже если вспомнить, около начала 1980х многие производители поставляли свои машины с 8088/8086, но все очень быстро начали мимикрировать под IBM PC для получения совместимости по софту, других вариантов не было. Скажу даже больше, я знаю очень мало программ, которые действительно делали графику через int10.
Уж слишком разнообразный был зоопарк видиков, даже в те исторические времена.
возню по установке режимов помню, от неё действительно старались уйти, вызывая функции bios.
а вот после установки режима какой-то проблемы с прямым доступом к видеопамяти не помню, более того, это было основным способом вывести что-то на экран. даже с появлением svga при всём многообразии режимов, если откинуть разрешение, то способы организации данных в памяти можно было пересчитать по пальцам (включая текстовые режимы).
в общем-то, ничего нового с тех пор не придумали, оно ровно в том же виде до сих пор и работает.
.> Писать в видеопамять напрямую?
.> Черт а где я был в это время?
.> Последний раз писал напрямую на Спектруме,
.> но там собственно вариантов было мало.
Я в во времена прямого писания в память году эдак в ≈ 1987 учился в школе классе соответственно тоже эдак в ≈ 7-м. На Корветах УПКовских и на Электрониках школьных писал на Бейсике прямо в память для создания звуков на нужной частоте и нужной длины. Потом из этого собирал мелодии. :-)
en.wikipedia.org/wiki/DOS_Shell
ru.wikipedia.org/wiki/Intel_80286
* Защищённый режим
* 24-битные адреса
* MMU
* Кольца защиты
Так что serious business.
В общем, я осилил только программку, которая писала на экран «A» или «B», запустил ее дважды, насладился потоками «ABABBABAABABBABABA» на экране и больше под DesqView ничего не писал. :-)
Защищённой и страничной памяти 386 тогда ещё не былоЗащищённая память в 286 уже была (как вы ниже сами и отмечаете).
нативные виндовые ярлыки — lnklnk появились в Win95, pif поддерживались начиная с Win 1.0
DOS Shell же вышел на год позже Windows 2.0.
iPhone OS при переходе от версии 2.0 к 3.0 получила буфер обмена, горизонтальную клавиатуру, поиск по айфону и internet tethering (использование айфона как модем).
А у Android переход 2.x -> 3.x как-то не задался — это была практически отдельная ОС для планшетов, прекрасной лебедью он стал (начал становиться) где-то с 4.1.х.
У меня был DOS 4.0 в дистрибутиве на двух дискетах в комплекте с оригинальным IBM PS/2 386SX20. Конечно, не многозадачный, а обычный.
Но какой-то навороченный по тем временам шелл там был.
MS-DOS, который мы никогда не видели
Спасибо за статью! Заставили вспомнить таки прошлый век :-)
Может и правильно. И пора уже!?
У меня всё отчетливее возникает ощущение, что развитие компьютерной отрасли пошло на следующий виток спирали развития, но на новом технологическом уровне. И тогда действительно требуется переосмысление предыдущего опыта…
Видели, видели мы этот MS DOS 4.0, но сознательно не использовали по причине глючности (или несовместимости!?) на фоне стабильной работы необходимых приложений в весьма «вылизанной» версии MS DOS 3.30.
И, да, потом ещё была версия 4.01, но с теми же отрицательными эффектами. Все кто мог откладывали переход на эти новые версии. А, по факту могли это отложить практически все. Так как большинство прикладного ПО было всё-таки рассчитано на работу с версией 3.30, которая воспринималась, как некий стандарт де-факто. И возник переломный момент только с появлением принципиально новой платформы Windows 3.1. Именно тогда у многих пришло осознание необходимости обновления OC.
Я понимаю увлеченность историей того времени. Действительно интересно было наблюдать за широкомасштабными и резкими прорывами в компьютерной области.
Тут выше была дискуссия о многозадачности… были упомянуты различные настольные программы и ОС, поддерживавшие переключение задач и многозадачность «различной степени». Все это было круто конечно. Но, по факту мы начали пользоваться этой многозадачностью только с появлением Windows 3.0. Вся многозадачность в MS-DOS воспринималась не более, чем баловство. Например, был большой риск отправить задачу в фоновый режим в этом DOS Shell и не вернуть её оттуда, потеряв результаты.
На фоне этой дискуссии, вспомнилось, что в то время была компания, не упомянутая здесь, которая своими достижениями (в т.ч. в области многозадачности) поражала меня больше, чем все остальные… это Novell. Их сетевая ОС Novell NetWear с примочками типа Novell NetWear Connct воспринимались в доИнтернетовское время, как настоящее техническое чудо. Но самый интересный компонент их сетевого решения, с моей точки зрения, это был драйвер IPX\SPX для MS-DOS. Пришлось с этим драйвером плотно повозиться тогда. Каково же было моё изумление, когда я понял, что этот «драйвер» превращает примитивную (собственно CP\M подобную!) операционную систему MS-DOS в многозадачную. И ведь действительно, как без многозадачности можно было обеспечить полноценный сетевой обмен в однозадачной ОС, если не все, что надо обеспечивалось сетевыми платами на аппаратном уровне. Конечно же переключение задач происходило по таймеру и никакого защищенного режима, но это решение прекрасно работало даже на PC с 8086\88 процессорами.
И все же многозадачность для многих не была тогда потребностью № 1. Основным «двигателем прогресса» была острая нехватка оперативной памяти. Ограничение в 640К, накладываемое ОС, была существенной проблемой для многих прикладных задач. Дополнительная память в любом объеме и любым способом воспринималась, как благо. Именно в этих обстоятельствах появилось большое количество пользователей PC, которые тратили бОльшую часть своего рабочего времени на оптимизацию системы на своем PC для получения дополнительных Кбайт свободной памяти. И это очень раздражало их начальников… Наверно именно из числа таких пользователей возникла гильдия оверклокеров, а их начальники превратились в менеджеров…
Согласен, «фоновый режим» для DOS Shell это я некорректно написал. Правильнее было бы мне написать «отложить задачу». Хотя, если пофилосовствовать, то можно рассмотреть «работу» отложенной задачи под DOS Shell, как её выполнение в фоном режиме. Просто она неминуемо будет находится в состоянии простоя из-за недоступности необходимого для её выполнения ресурса под названием CPU.
И возник переломный момент только с появлением принципиально новой платформы Windows 3.1. Именно тогда у многих пришло осознание необходимости обновления OC.
Ну не скажите. На четверку («настоящую», а не сабж статьи) действительно мало кто переходил, но вот на 5.0 переходили довольно бодро. Там было и продвинутое управление памятью >640 Мб, и русификация из коробки, и много других плюшек.
Но, постараюсь пояснить. Тот механизм «многозадачности», о котором я упомянул, имел скорее не прямое, а косвенное отношение к процессам сетевого обмена. Конечно точно утверждать не могу. Как Вы можете догадаться, эта реализация изучалась совсем не по спецификациям производителя или с привлечением коллективного разума энтузиастов из Интернет, которые всегда знают правильный ответ. Аппаратные прерывания точно не были завязаны на этот механизм многозадачности. Но, этому механизму можно было поручить выполнение дополнительных фоновых процессов (нескольких!) в режиме разделения времени, которые при «правильной реализации» не оказывали существенного влияния на выполнение процессов основного приложения в MS-DOS.
Надеюсь, нет необходимости доказывать, что перехват управления для выполнения фоновых процессов осуществлялся на основании прерывания от таймера.
Знания о таком механизме у меня появились только потому, что мне нужен был такой механизм. Я его нашел в сетевом драйвере от Novell и успешно использовал тогда в своих корыстных целях на благо клиентам нашей конторы.
Я могу понять ваше возмущение. Причина тому слово «драйвер». А написанное мной, ну никак не ложиться на ваши каноническо-академические знания о драйверах для MS-DOS. Это вполне нормально, если не желать знать о большем…
Если Вам все-таки захочется разобраться в этом вопросе, то взгляните, например, на статью "Рабочая станция NetWare". Там достаточно хорошо описано, во что мог превратиться персональный компьютер с MS-DOS, если в него добавить «драйвер» от Novell.
Когда будете читать пусть Вас смутит и заставит задуматься о чем-то светлом и грандиозном, например, описание конфигурационного параметра:
MAX TASKS — определение максимального количества одновременно запущенных задач (для Windows, DESQview и т. д.);
MS-DOS — это realtime система
Думаю, все-таки это не верное утверждение. В самой MS-DOS не было же никаких механизмов, гарантирующих время исполнения задач и процессов!? Иначе бы в то время F-16 летали бы под управлением MS-DOS, а не QNX :-)
Разумеется глупо было рассматривать Event Control Block (ECB) какого-то сетевого драйвера в качестве Process Control Block (PCB) настоящей многозадачной ОС. Это меня не оправдывает, но это Novell спровоцировал меня.
Они реализовали в своем драйвере asynchronous event scheduler (AES) и достаточный набор функций для планирования и исполнения всяких routine.
Да, я не должен был указывать адрес процедуры своей резидентной программы (TSR) в структуре AESECB в поле
AESESR
This field specifies a routine that is to be invoked when the specified time has expired.
This field must point to a valid routine and only needs to be initialized once.
The ESR must complete quickly because it is executing in the context of a timer interrupt.
The ESR can reschedule itself after it resets the MSecondValue, thus creating a simple polling function.
И, да, это было ошибкой передать такую структуру в функцию драйвера ScheduleAESEvent, чтобы вовлечь в мой корыстный процесс таймер и никаким образом не использовать контролеры прерывания и прямого доступа к памяти. И, тем более, использовать сетевой драйвер не по назначению это вообще преступление. Каюсь!
Если бы мне был доступен документ "Novell ODI Specification: NetWare 16-Bit DOS Protocol Stacks and MLIDs", то я, возможно, не сделал бы такой грязный хак.
Хотя, тогда я осознанно выбрал это решение и не стал писать свой планировщик задач.
Так что меня можно судить по всей строгости ;-)
все, что надо обеспечивалось сетевыми платами на аппаратном уровне
IRQ, DMA
Это разве не аппаратный уровень?
устройство сетевого драйвера под MS-DOS
А разве MS-DOS как-то регламентировала устройства сетевых драйверов? Было несколько конкурирующих сетевых стэков (навскидку IPX/SPX от Netware, NetBIOS от MS и несколько реализаций TCP/IP) и каждый использовал свои виды драйверов.
А разве MS-DOS как-то регламентировала устройства сетевых драйверов?
Я в то время натыкался на файл-документ от Microsoft, где подробно описывались принципы построения драйверов под MS-DOS для устройств различных типов: последовательных и блочных. И, если мне не изменяет память, там был отдельный раздел, посвященный драйверам для сетевых устройств. Но, вряд ли уместно говорить от том, что этот и подобные ему документы что-то «регламентировали». Функции ОС были весьма скромны и многие разработчики не воспринимали их, как существенные ограничение. Если что-то требовалось, то это делалось. Например, считалось абсолютно нормальным перехватить программное прерывание INT21 (основные функции DOS) и добавить нужное.
Так и представляется R&D отдел Microsoft, где вышеупомянутому лиду поручили потратить 20% времени на «что-то новенькое».
Потом это «что-то» выросло, и немного не вписалось в политику DOS, и его решили развить и продать как OS/2. А линейку DOS продолжать в том же духе.
Теперь пазл сложился.
MS-DOS, который мы никогда не видели