Comments 74
мдя
Вот это я понимаю — глубоко копнул
Насколько же другим мог быть DOS 5.x, если бы MS решились сломать обратную совместимость с софтом, делающим специфические штуки напрямую…
Хочу заметить что и «обычный» MS DOS 4.0 нес много изменений и неплохо ломал совместимость. Но эта версия была практически принципиально иной операционной системой, по странной случайности получившая совместимость с DOSом. Поэтому у нее и была отдельная дорога инновация под названием OS/2. А еще о досе 1988 есть замечательная цитата, которая мне очень нравится:
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.
Была же шутка, что Microsoft выпускает нормальные десктопные OS через одну: 95 — 98 — Me — XP — Vista — 7 — 8…
Хочу заметить что и «обычный» MS DOS 4.0 нес много изменений и неплохо ломал совместимость
а можно делатли?
как мне помнится, писать программы, совместимые со всеми версиями старше 3.3, было несложно.
Мне больше всего нравится, что наконец-то нашлась ОС, в которой сбылись страшики учебников по программированию того времени. Тогда во всех учебниках писали, что прямое программирование оборудования и прямой доступ в видеопамять — страшная бяка, совместимость с которой рано или поздно будет потеряна… а в следующих главах эта самая прямая запись в видеопамять подробнейшим образом разбиралась, что доставляло. В какой-то из книг Нортона, по-моему, упоминался DesqView, умевший многозадачность раньше остальных, и уже тогда наталкивавшийся на несовместимость, но на практике с ним сталкиваться не доводилось.
С появлением 386-х процессоров задача виртуализации DOS была решена фактически аппаратно, и страшилки из книг так и остались страшилками, — смешно и обидно одновременно. Статьи вроде этой — прям как бальзам на душу. И интересно, само собой.
С появлением 386-х процессоров задача виртуализации DOS была решена фактически аппаратно, и страшилки из книг так и остались страшилками, — смешно и обидно одновременно. Статьи вроде этой — прям как бальзам на душу. И интересно, само собой.
Писать в видеопамять напрямую? Черт а где я был в это время?
Последний раз писал напрямую на Спектруме, но там собственно вариантов было мало.
На х86 сразу int10 и собственно без вариантов. Уж слишком разнообразный был зоопарк видиков, даже в те исторические времена.
Вот пытаюсь сейчас вспомнить когда бы это было реально, но не могу. Сразу как в х86 познакомился — зоопарк был разнообразный.
Нет, реально, тогда всё было другое. Как в «Песня о программистской молодости» от YuN (а он еще и поет).
И да, мы действительно тогда мало чего боялись. И всяких там несовместимостей в первую очередь.
Но все равно не припомню чтобы вот так писать напрямую.
Последний раз писал напрямую на Спектруме, но там собственно вариантов было мало.
На х86 сразу int10 и собственно без вариантов. Уж слишком разнообразный был зоопарк видиков, даже в те исторические времена.
Вот пытаюсь сейчас вспомнить когда бы это было реально, но не могу. Сразу как в х86 познакомился — зоопарк был разнообразный.
Нет, реально, тогда всё было другое. Как в «Песня о программистской молодости» от YuN (а он еще и поет).
И да, мы действительно тогда мало чего боялись. И всяких там несовместимостей в первую очередь.
Но все равно не припомню чтобы вот так писать напрямую.
какой зоопарк? только CGA/EGA Hercules и не понятная видеокарта в EC-1840
При обсуждении подобных тем важным аргументом является дата рождения в профиле. :-)
Владислав, не думаю что шесть лет разницы что-то решают в данном случае. Первую программу я написал в 89-ом, на СМ-1800.
Конечно это был редкостный лапшекод на бейсике, но не суть. Мне было 9, Вам 15, так что осмелюсь предположить что в то время это для Вас было тоже хобби как и для меня.
Тут скорее больше влияет кто с каким парком сталкивался и какие задачи решались.
Для меня три вида карточек тогда казались большим зоопарком, а работа через инт10 в сравнении с родным для меня спектрумом — очень быстрой.
ПЫСЫ: а вообще я не спорю. Думаю если бы я не ограничивался фаном от того что я на спектруме в интерпретируемом бейсике собрал леталку-стрелялку, или «круто я пишу на ассемблере», а писал всё это на продажу, то вероятно я бы таки да уперся в скорость и прочее.
Но реально под простые игрушки (тем более на черно-зеленых мониторах) и под вывод разных графиков для расчетов вполне хватало инт10. Я бы если не это обсуждение и не узнал о том, что оно дескать медленное… :)
Конечно это был редкостный лапшекод на бейсике, но не суть. Мне было 9, Вам 15, так что осмелюсь предположить что в то время это для Вас было тоже хобби как и для меня.
Тут скорее больше влияет кто с каким парком сталкивался и какие задачи решались.
Для меня три вида карточек тогда казались большим зоопарком, а работа через инт10 в сравнении с родным для меня спектрумом — очень быстрой.
ПЫСЫ: а вообще я не спорю. Думаю если бы я не ограничивался фаном от того что я на спектруме в интерпретируемом бейсике собрал леталку-стрелялку, или «круто я пишу на ассемблере», а писал всё это на продажу, то вероятно я бы таки да уперся в скорость и прочее.
Но реально под простые игрушки (тем более на черно-зеленых мониторах) и под вывод разных графиков для расчетов вполне хватало инт10. Я бы если не это обсуждение и не узнал о том, что оно дескать медленное… :)
ЧСХ, эти самые 6 лет приходятся на то время в жизни человека, когда каждый год решает. В послесловии вы это косвенно и признали.
У меня «Спектрума» не было, зато в 1989-м я программировал на уже упоминавшемся тут «Поиске», и его неполноценную реализацию CGA познал на практике. А через 6 лет зоопарк различных SVGA не вызывал удивления — на дворе-то стоял 1995-й год. Ассемблер я тогда уже забросил, не до него было.
У меня «Спектрума» не было, зато в 1989-м я программировал на уже упоминавшемся тут «Поиске», и его неполноценную реализацию CGA познал на практике. А через 6 лет зоопарк различных SVGA не вызывал удивления — на дворе-то стоял 1995-й год. Ассемблер я тогда уже забросил, не до него было.
Вы прям альтернативную историю рассказываете. Это обычное стандартное дело лезть в видеопамять. До 1990 зоопарка не было совсем, четкие стандарты: CGA, EGA, VGA, MDA. Четкое расположение видеопамяти в памяти. Даже когда произошел кембрийский взрыв видеокарт все они поддерживали VGA очень хорошо, даже всех их баги и неточности, вспомните хотя бы ModeX. Во всех книгах по программированию писали как лазить в память. До сих пор помню 0xB800 и в путь. Одно время я тестировал различный софт по CTTY, который нормально работал только с абстагированным от железа софтом. Если текстовые/графические возможности программы хоть на шаг уходят от printf, то она лезла напрямую в видеокарту. Все игры лезли тоже, через int10 было банально медленно.
У IBM PC очень стандартное железо и это породило потом очень много проблем с совместимостью. Даже если вспомнить, около начала 1980х многие производители поставляли свои машины с 8088/8086, но все очень быстро начали мимикрировать под IBM PC для получения совместимости по софту, других вариантов не было. Скажу даже больше, я знаю очень мало программ, которые действительно делали графику через int10.
У IBM PC очень стандартное железо и это породило потом очень много проблем с совместимостью. Даже если вспомнить, около начала 1980х многие производители поставляли свои машины с 8088/8086, но все очень быстро начали мимикрировать под IBM PC для получения совместимости по софту, других вариантов не было. Скажу даже больше, я знаю очень мало программ, которые действительно делали графику через int10.
Да пусть даже и текстовый режим. На CGA вывод был совсем медленным, и даже текст приходилось выводить напрямую в видеопамять. В библиотеках вроде Turbo Vision так и осталось наследие синхронизации обратного хода луча, хоть на современных ей видеокартах «снега» уже не наблюдалось.
А MCGA и Hercules когда появились? Помню, в Airborne Rangers та-а-а-кой список был — и CGA, и EGA, и MCGA, и VGA, и Hercules…
Уж слишком разнообразный был зоопарк видиков, даже в те исторические времена.
возню по установке режимов помню, от неё действительно старались уйти, вызывая функции bios.
а вот после установки режима какой-то проблемы с прямым доступом к видеопамяти не помню, более того, это было основным способом вывести что-то на экран. даже с появлением svga при всём многообразии режимов, если откинуть разрешение, то способы организации данных в памяти можно было пересчитать по пальцам (включая текстовые режимы).
в общем-то, ничего нового с тех пор не придумали, оно ровно в том же виде до сих пор и работает.
.> Писать в видеопамять напрямую?
.> Черт а где я был в это время?
.> Последний раз писал напрямую на Спектруме,
.> но там собственно вариантов было мало.
Я в во времена прямого писания в память году эдак в ≈ 1987 учился в школе классе соответственно тоже эдак в ≈ 7-м. На Корветах УПКовских и на Электрониках школьных писал на Бейсике прямо в память для создания звуков на нужной частоте и нужной длины. Потом из этого собирал мелодии. :-)
У дос был многозадачный режим. dos shell назывался. Представлял из себя графический менеджер, использующий функции виртуализации 286 процессора. Защищённой и страничной памяти 386 тогда ещё не было, но какие-то переключалки были. Именно для него были pif-файлы, которые потом винда поддерживала (в режиме обратной совместимости!, нативные виндовые ярлыки — lnk).
en.wikipedia.org/wiki/DOS_Shell
en.wikipedia.org/wiki/DOS_Shell
Но ведь это был обычный сваппер, а не вытесняющая многозадачность, он позволял заменить одно текущее приложение на другое, а не их работу в паралели. это два совершенно разных MSDOS, совершенно разные способы достижения даже схожих, а не одинаковых целей. Код из доса 1985 не попал в код 1988 года, он ушел целиком в OS/2. Отдельно замечу, у 286 не было совсем виртуализации. Вообще никакой. DOS SHELL одна из моих любимых тем, но это не многозадачность, это сваппинг задач. Но возможности 286 она не использовала.
Ага. Но вытеснение всё-таки было (т.к. не было кооперативного режима — софт не в курсе был). Можно было нажать кнопочку и переключить задачу, если повезёт и ничего не повиснет. Насколько я помню, у 286 довольно много всего было.
ru.wikipedia.org/wiki/Intel_80286
* Защищённый режим
* 24-битные адреса
* MMU
* Кольца защиты
Так что serious business.
ru.wikipedia.org/wiki/Intel_80286
* Защищённый режим
* 24-битные адреса
* MMU
* Кольца защиты
Так что serious business.
Да, все это было, действительно. НО: Виртуализации не было, это раз. А два, не было многозадачности. Это было переключение задач, вытесняющая переключаемость софта, а не многозадачность. А этот дос истинно многозадачен, задачи выполняются паралельно. И совершенно без защиты, все происходило в реальном режиме, от программ требовалось быть паиньками.
DesqView даже на 8086/80186 мог параллельно выполнять процессы. И графические программы очень неплохо переключал в отличие от dos shell и Win95. В DesqView только в окошках (не в полный экран) некоторые графические программы могли криво работать.
Ну… все же про многозадачность я бы не судил так строго. Примерно в те времена мне попалась книжка про 80286 процессор, желтая такая. Автора к сожалению не назову. Так вот, там описывались все нововведения, включая кольца защиты, сам защищенный режим и среди прочего — реализация на ассемблере программы-монитора, переключавшей задачи по таймеру. Если пороюсь в хламе, может быть и найду эту книгу.
Дело в том, что без виртуализации, появившейся в 386, невозможно было принудительно переключать программы реального режима, а ОС без поддержки существующих программ для DOS — никому не была нужна. (Как и доказала история этой 4.00M)
virtual режим 386 всего лишь позволял управлять 16-битными виртуальными машинами из 32-среды. У 286 было всё, для того, чтобы реализовывать вытесняющую многозадачность: уровни приоритета (читай — чужая программа таймер не перехватит), программируемый MMU. Не было 32-битного режима и IOMMU, но iommu появился где-то в районе P4 и назывался VT-D.
В нём не было многозадачности. т.е. одновременно ничего не выполнялось. Выполнялась только одна программа а остальные свопились в расширенную память или на диск. Настоящая многозадачность тогда была только в en.wikipedia.org/wiki/DESQview — можно было даже дискетки фоном форматировать в отличие от Win95.
Ну это, на самом деле, не показатель. Многозадачности бывают разные. Была оболочка — Dos Navigator — которая могла одновременно форматировать, играть музыку с CD, показывать кучу окошек с файлами, текстом и прочим. Кроме того была сама Windows, которая была уже честно многозадачной, но многозадачность была кооперативной, каждая программа должна была отдать добровольно управление следующей. В вытесняющей многозадачности программы как бы не знают о своих соседей и от выполнения на процессоре отстраняются насильно.
В DOS Navigator это делалось в одной программе а не разными процессами. Да и event-driven все это, как и javascript в браузере, какая уж тут многозадачность.
Если уж докапываться до правды, а не судить о том, тормозит ли система при форматировании, то Windows 95 была очень многозадачной системой. Тогда, конечно, я на нее тоже плевался, ибо был обычным пользователем. Но сейчас, когда я стал программистом, я понимаю, какие титанические усилия вложила Microsoft для обратной совместимости в Windows 95. Впрочем, даже тут уже об этом писали весьма детально: http://habrahabr.ru/post/188554/
Пробовал DesqView в своё время. Технически я тогда не особо разбирался в тонкостях системной архитектуры и не могу сказать, что там свопилось, а что — нет, но на моей памяти крутилось только активное DOS-приложение, а остальные приостанавливались. Тестил я это дело, насколько помню, на T-Mail, тоссере (не помню, каком) и GoldEd.
Специально скомпилированные приложения работали под DesqView параллельно на моем 80286. :)
Увы, специально скомпилированных под DesqView приложений увидеть и даже поискать тогда толком не довелось — мысли по молодости были заняты другим. Обходился досовскими, а с ними только по очереди работать получалось, хоть даже так было уже проще — не требовалось каждый раз запускать программу и выходить из неё.
Скомпилировать приложение под DesqView было крайне непросто. Но хуже этого, что многозадачность в DesqView управлялась не операционной системой, а… самими приложениями. Приложению нужно было поработать чуть-чуть, а затем с помощью специального вызова «отдать» процессор операционке. Смутно помню, что можно было в качестве параметра сказать, сколько примерно времени тебе не потребуется процессор. Это было похоже на вызов sleep().
В общем, я осилил только программку, которая писала на экран «A» или «B», запустил ее дважды, насладился потоками «ABABBABAABABBABABA» на экране и больше под DesqView ничего не писал. :-)
В общем, я осилил только программку, которая писала на экран «A» или «B», запустил ее дважды, насладился потоками «ABABBABAABABBABABA» на экране и больше под DesqView ничего не писал. :-)
286? На 386 все прекрасно работало параллельно.
Защищённой и страничной памяти 386 тогда ещё не былоЗащищённая память в 286 уже была (как вы ниже сами и отмечаете).
нативные виндовые ярлыки — lnklnk появились в Win95, pif поддерживались начиная с Win 1.0
Насколько я помню, .lnk появились только в Win 9x / NT 4. В 3.1 были только PIF.
DOS Shell же вышел на год позже Windows 2.0.
DOS Shell же вышел на год позже Windows 2.0.
Когда-то я считал себя нубом, т. к. ни разу не работал с os/2. Теперь, вероятно, многие о ней и не слышали:(…
В очень старой Компьютерре, года примерно 95 (почти 20 лет назад! ужас!) была небольшая заметка, кажется в письмах читателей, про сакральный смысл третьей версии ОС. Речь шла про ДОС, Вин и полуось. И смысл был такой, что при переходе от 2.0 к 3.0 система превращается из непонятно чего в прекрасного лебедя.
Хм, а если вспомнить ещё и Winamp 2.х/3.х, Android 2.x/3.x, Firefox 2.x/3.x…
То-то после выхода ядра Linux 3.0 на него стим пришёл, игры появились и невидия понемногу поддержку Optimus докручивать начала.
Нумерология типа «лысый-волосатый» и «каждая вторая ОС Майкрософта — удачная»? :)
iPhone OS при переходе от версии 2.0 к 3.0 получила буфер обмена, горизонтальную клавиатуру, поиск по айфону и internet tethering (использование айфона как модем).
А у Android переход 2.x -> 3.x как-то не задался — это была практически отдельная ОС для планшетов, прекрасной лебедью он стал (начал становиться) где-то с 4.1.х.
iPhone OS при переходе от версии 2.0 к 3.0 получила буфер обмена, горизонтальную клавиатуру, поиск по айфону и internet tethering (использование айфона как модем).
А у Android переход 2.x -> 3.x как-то не задался — это была практически отдельная ОС для планшетов, прекрасной лебедью он стал (начал становиться) где-то с 4.1.х.
Только Valve никак до трех не досчитаются.
Очень интересная информация. Если бы не было столь детального анализа, подумал бы, что шутка.
У меня был DOS 4.0 в дистрибутиве на двух дискетах в комплекте с оригинальным IBM PS/2 386SX20. Конечно, не многозадачный, а обычный.
Но какой-то навороченный по тем временам шелл там был.
У меня был DOS 4.0 в дистрибутиве на двух дискетах в комплекте с оригинальным IBM PS/2 386SX20. Конечно, не многозадачный, а обычный.
Но какой-то навороченный по тем временам шелл там был.
Даже не слышал об этой ДОС, только «настоящую» немного поюзал.
UFO just landed and posted this here
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 не многозадачная система, вы говорите о MS DOS образца 1988 года, а не 1985, об этом и статья. Версия 1985 года позволяла работать программам параллельно, а не просто менять активную задачу на другую.Так что это совсем другая история и все же вы не видели то, что я вам описал. Могу заключить с вами пари.
На эту тему спорить не буду — проиграю. Как минимум потому, что у меня все весомые вещественные доказательства на флоппи-дисках, начиная с 8-ми дюймовых, безвозвратно утрачены. Нам, в таком техническо-историческом споре нельзя будет полагаться на любые «экспертные» или «авторитетные» мнения. А судя по скриншотам в статье, у Вас «все карты на руках».
Согласен, «фоновый режим» для DOS Shell это я некорректно написал. Правильнее было бы мне написать «отложить задачу». Хотя, если пофилосовствовать, то можно рассмотреть «работу» отложенной задачи под DOS Shell, как её выполнение в фоном режиме. Просто она неминуемо будет находится в состоянии простоя из-за недоступности необходимого для её выполнения ресурса под названием CPU.
Согласен, «фоновый режим» для DOS Shell это я некорректно написал. Правильнее было бы мне написать «отложить задачу». Хотя, если пофилосовствовать, то можно рассмотреть «работу» отложенной задачи под DOS Shell, как её выполнение в фоном режиме. Просто она неминуемо будет находится в состоянии простоя из-за недоступности необходимого для её выполнения ресурса под названием CPU.
И возник переломный момент только с появлением принципиально новой платформы Windows 3.1. Именно тогда у многих пришло осознание необходимости обновления OC.
Ну не скажите. На четверку («настоящую», а не сабж статьи) действительно мало кто переходил, но вот на 5.0 переходили довольно бодро. Там было и продвинутое управление памятью >640 Мб, и русификация из коробки, и много других плюшек.
Я и пытался сказать про феномен игнорирования пользователями всех версий 4.x. А переход на следующие версии даже консервативных пользователей в большинстве случаев определялся именно потребностями в свободной памяти для выполнения приложений. И да, даже на фоне существования Windows, следующие версии MS-DOS продолжали широко использоваться.
UFO just landed and posted this here
Кстати да. Я точно помню, когда еще в школе учился, у нас прекрасно работала IPX/SPX сеть в классе информатики под MS DOS 6.22 с Netware сервером в качестве файлопомойки. Более того, все компы были бездисковыми и грузились именно с этого netware, и на нем-же были индивидуальные папки для каждого ученика, для его файлов с решениями. Так что сеть в «голом однозадачном MS DOS» работала на ура.
За давностью лет могло многое конечно забыться и я сам себе уже не доверяю в этих вопросах :-)
Но, постараюсь пояснить. Тот механизм «многозадачности», о котором я упомянул, имел скорее не прямое, а косвенное отношение к процессам сетевого обмена. Конечно точно утверждать не могу. Как Вы можете догадаться, эта реализация изучалась совсем не по спецификациям производителя или с привлечением коллективного разума энтузиастов из Интернет, которые всегда знают правильный ответ. Аппаратные прерывания точно не были завязаны на этот механизм многозадачности. Но, этому механизму можно было поручить выполнение дополнительных фоновых процессов (нескольких!) в режиме разделения времени, которые при «правильной реализации» не оказывали существенного влияния на выполнение процессов основного приложения в MS-DOS.
Надеюсь, нет необходимости доказывать, что перехват управления для выполнения фоновых процессов осуществлялся на основании прерывания от таймера.
Знания о таком механизме у меня появились только потому, что мне нужен был такой механизм. Я его нашел в сетевом драйвере от Novell и успешно использовал тогда в своих корыстных целях на благо клиентам нашей конторы.
Но, постараюсь пояснить. Тот механизм «многозадачности», о котором я упомянул, имел скорее не прямое, а косвенное отношение к процессам сетевого обмена. Конечно точно утверждать не могу. Как Вы можете догадаться, эта реализация изучалась совсем не по спецификациям производителя или с привлечением коллективного разума энтузиастов из Интернет, которые всегда знают правильный ответ. Аппаратные прерывания точно не были завязаны на этот механизм многозадачности. Но, этому механизму можно было поручить выполнение дополнительных фоновых процессов (нескольких!) в режиме разделения времени, которые при «правильной реализации» не оказывали существенного влияния на выполнение процессов основного приложения в MS-DOS.
Надеюсь, нет необходимости доказывать, что перехват управления для выполнения фоновых процессов осуществлялся на основании прерывания от таймера.
Знания о таком механизме у меня появились только потому, что мне нужен был такой механизм. Я его нашел в сетевом драйвере от Novell и успешно использовал тогда в своих корыстных целях на благо клиентам нашей конторы.
UFO just landed and posted this here
В просак попасть не страшно, если в душе имеешь железный стержень. Ведь сколько веревочке не виться, а конец-то найдется :-)
Я могу понять ваше возмущение. Причина тому слово «драйвер». А написанное мной, ну никак не ложиться на ваши каноническо-академические знания о драйверах для MS-DOS. Это вполне нормально, если не желать знать о большем…
Если Вам все-таки захочется разобраться в этом вопросе, то взгляните, например, на статью "Рабочая станция NetWare". Там достаточно хорошо описано, во что мог превратиться персональный компьютер с MS-DOS, если в него добавить «драйвер» от Novell.
Когда будете читать пусть Вас смутит и заставит задуматься о чем-то светлом и грандиозном, например, описание конфигурационного параметра:
MAX TASKS — определение максимального количества одновременно запущенных задач (для Windows, DESQview и т. д.);
Думаю, все-таки это не верное утверждение. В самой MS-DOS не было же никаких механизмов, гарантирующих время исполнения задач и процессов!? Иначе бы в то время F-16 летали бы под управлением MS-DOS, а не QNX :-)
Я могу понять ваше возмущение. Причина тому слово «драйвер». А написанное мной, ну никак не ложиться на ваши каноническо-академические знания о драйверах для MS-DOS. Это вполне нормально, если не желать знать о большем…
Если Вам все-таки захочется разобраться в этом вопросе, то взгляните, например, на статью "Рабочая станция NetWare". Там достаточно хорошо описано, во что мог превратиться персональный компьютер с MS-DOS, если в него добавить «драйвер» от Novell.
Когда будете читать пусть Вас смутит и заставит задуматься о чем-то светлом и грандиозном, например, описание конфигурационного параметра:
MAX TASKS — определение максимального количества одновременно запущенных задач (для Windows, DESQview и т. д.);
MS-DOS — это realtime система
Думаю, все-таки это не верное утверждение. В самой MS-DOS не было же никаких механизмов, гарантирующих время исполнения задач и процессов!? Иначе бы в то время F-16 летали бы под управлением MS-DOS, а не QNX :-)
UFO just landed and posted this here
Отчего же, я признаю свою ошибку молодости.
Разумеется глупо было рассматривать Event Control Block (ECB) какого-то сетевого драйвера в качестве Process Control Block (PCB) настоящей многозадачной ОС. Это меня не оправдывает, но это Novell спровоцировал меня.
Они реализовали в своем драйвере asynchronous event scheduler (AES) и достаточный набор функций для планирования и исполнения всяких routine.
Да, я не должен был указывать адрес процедуры своей резидентной программы (TSR) в структуре AESECB в поле
И, да, это было ошибкой передать такую структуру в функцию драйвера ScheduleAESEvent, чтобы вовлечь в мой корыстный процесс таймер и никаким образом не использовать контролеры прерывания и прямого доступа к памяти. И, тем более, использовать сетевой драйвер не по назначению это вообще преступление. Каюсь!
Если бы мне был доступен документ "Novell ODI Specification: NetWare 16-Bit DOS Protocol Stacks and MLIDs", то я, возможно, не сделал бы такой грязный хак.
Хотя, тогда я осознанно выбрал это решение и не стал писать свой планировщик задач.
Так что меня можно судить по всей строгости ;-)
Разумеется глупо было рассматривать 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) и добавить нужное.
Вот про последовательные и блочные помню точно — они были видны всей системе от IO.SYS. Ну и так, наверное, можно было представить сетевую карту как последовательное устройство. Но вроде так называемые «сетевые драйвера» с самой ОС взаимодействовали постольку поскольку, обычные резидентные программы, максимум использующие «драйверный» способ загрузки (были нюансы, кажется первые 256 байт не резервировалось в отличии от .com) вешающиеся на какое-то софтовое прерывание для предоставления API сетевому стэку и железное для работы с картой.
Так вот как разрабатывалась подсистема VDM (Virtual DOS Machine) для первой версии OS/2.
Круто.
Так и представляется R&D отдел Microsoft, где вышеупомянутому лиду поручили потратить 20% времени на «что-то новенькое».
Потом это «что-то» выросло, и немного не вписалось в политику DOS, и его решили развить и продать как OS/2. А линейку DOS продолжать в том же духе.
Теперь пазл сложился.
Так и представляется R&D отдел Microsoft, где вышеупомянутому лиду поручили потратить 20% времени на «что-то новенькое».
Потом это «что-то» выросло, и немного не вписалось в политику DOS, и его решили развить и продать как OS/2. А линейку DOS продолжать в том же духе.
Теперь пазл сложился.
Еще из «оболочек», помнится, был GeoWorks. Но я не припоминаю, чтобы у нас его использовали.
Sign up to leave a comment.
MS-DOS, который мы никогда не видели