Примечание
Нужно отметить, что эта часть легенды несколько расходится с достоверными историческими сведениями. В описываемый период Microsoft занимался не только и даже не столько ВАSIC'ом, сколько собственной ОС, основанной на Unix v.6 -- Microsoft Xenix. Эта система была реализована для нескольких микропроцессорных систем на 32-разрядных микропроцессорах, таких, как MC68000, NS32032 и даже 18086/8086.
По другой версии легенды, Билл Гейтс первоначально предложил Xenix, но представители IBM хотели что-нибудь похожее на СР/М. Гейтс приобрел за 13 тысяч долларов лицензию на систему QDOS клон СР/М, разработанный компанией Seattle Computer Products. По легенде. QDOS расшифровывается как Quick and Dirty Operating System "Быстро [сделанная] и Грязная Операционная Система".
Фирма Microsoft переделала загрузчик и дисковую подсистему QDOS для работы с IBM PC и использования сервисов ПЗУ этого компьютера (эти сервисы также называются BIOS, хотя имеют довольно мало общего с BIOS СР/М), и предложила результат фирме IBM. Заказчики оказались довольны и Билл быстро стал миллионером.
К версии 3.30 MS DOS (такое название получила новая система) уже накопила очень много отличий от оригинальной СР/М. В качестве файловой системы была использована изобретенная лично Б. Гейтсом для применения в интерпретаторе BASIC ФС FAT. Эта ФС была переделана так, чтобы в ней можно было создавать вложенные каталоги. Был добавлен новый формат загрузочного модуля вдобавок к абсолютным загрузочным файлам формата СОМ (совместимых с СР/М) были реализованы относительные загрузочные файлы ЕХЕ (известные также как файлы MZ). Были реализованы загружаемые драйверы внешних устройств. Динамическая загрузка и выгрузка драйверов не поддерживалась, но, по крайней мере, изменение номенклатуры драйверов теперь не требовало перегенерации системы. Список загружаемых драйверов задавался текстовым файлом C:\CONFIG.SYS. Позднее был даже реализован интерфейс для драйверов файловых систем.
Была разрешена загрузка нескольких программ в стековом порядке (впрочем, не допускалось их параллельного исполнения). Система приобрела многие черты, аналогичные примитивным версиям Unix так, каждая загруженная программа в MS DOS снабжается дополнительным сегментом памяти, так называемым PSP (Program Segment Prefix заголовок программного сегмента), который аналогичен User area (пользовательской области, сегменту данных ядра ОС, относящихся к конкретному процессу) в Unix. В некоторых документах сегментный адрес PSP даже называют pid (Process Identifier, по аналогии с идентификатором процесса в Unix). Как и в Unix, исполнение системного вызова сопровождалось переустановкой стека. В состав системы были включены:
файловый API, очень похожий на интерфейс файловых системных вызовов в Unix;
переменные среды;
переназначение ввода-вывода;
и даже конвейеры (последовательности задач, в которых поток стандартного вывода предыдущей задачи является потоком стандартного ввода следующей), реализуемые через промежуточный файл.
По одной из легенд, нежелание Microsoft реализовать в DOS вытесняющую многозадачность обусловлено не столько технической некомпетентностью, сколько соглашением с фирмой SCO в соответствии с ним, передавая права на торговую марку Xenix, Microsoft обязалась не разрабатывать и не продавать функциональных эквивалентов UNIX. Такое соглашение существовало в действительности: через много лет, в 1997 г., SCO отсудила у Microsoft принадлежавшую последней долю своих акций и ряд других обязательств (упоминание Microsoft в списке держателей авторских прав, поддержку бинарной совместимости с Xenix/286) на том основании, что Microsoft рекламировала Windows NT как замену и даже "убийцу" UNIX и, таким образом, нарушала соглашение.
Со времен DOS 3.30 архитектура системы не подверглась сколько-нибудь заметным изменениям [Панкратов 2001]. Так, DOS 7, входящая в состав Windows 98/ME в качестве вторичного загрузчика, отличается от 3.30 только поддержкой файловой системы FAT32.
Digital Research не смотрела на это развитие безучастно. К концу 80-х система DR DOS, основанная на исходных текстах оригинальной СР/М, обеспечивала полную программную совместимость с MS DOS и включала в себя все новшества не только версии 3.30, но и более поздних версий.
Ряд полезных идей, впервые реализованных в DR DOS, такие, как загрузка в верхнюю память, условные операторы в CONFIG.SYS и упакованная файловая система, появились в MS DOS лишь на одну или две версии позже, а некоторые идеи например, экранный редактор командной строки (возможность, знакомая пользователям командных процессоров DCL, bash и 4DOS/4OS2/4NT) и загрузка из расширенного раздела не были реализованы в MS DOS и Windows 95/98/МЕ никогда.
Ближе к середине 90-х стало очевидно, что дни DOS как платформы сочтены (впрочем, мало кто ожидал в то время, что в той или иной форме эта платформа сможет прожить до самого конца столетия). В 1993 г. Digital Research вместе с авторскими правами на DR DOS была приобретена фирмой Novell. В 1995 г., вскоре после того, как собрание акционеров выгнало Р. Нурду с поста СЕО, авторские права на этот продукт были переданы созданной им компании Caldera. Несколько позднее Caldera опубликовала исходные тексты системы на условиях GPL под называнием Caldera OpenDOS [www.caldera.com]. С тех пор эта система широко используется в составе DOS-эмуляторов различных дистрибутивов Linux.
Win16
Вскоре после анонса Apple Macintoch в 1984 г., Microsoft выпустила электронную таблицу Excel и текстовый процессор Word для этой системы Автор не может подтвердить это официальными данными, но трудно избавиться от впечатления, что основной задачей при разработке Win 16 былс максимальное облегчение переноса приложений Мае на IBM PC. Версии Windows 2.x3.x воспроизводят почти все характерные черты Mac OS. П Событийно-ориентированную кооперативно многозадачную архитектуру П Единое адресное пространство
Сборку программ в момент загрузки с использованием DLL "Ручечное" управление памятью
И даже соглашение о вызовах у процедур системного API: параметры помещаются в стек, начиная с первого, стек очищается вызываемой процедурой
Ядро системы было собрано в виде загрузочного модуля DOS (win.exe). После загрузки этот модуль брал на себя управление памятью и осуществлял загрузку собственных и пользовательских модулей формата NE (так называемые сегментированные модули). DOS, однако, сохранялась в оперативной памяти и использовалась в качестве дисковой подсистемы.
Первые версии системы были совершенно неудовлетворительными не только с точки зрения надежности, но и по производительности. Довольно большие требования к ресурсам не позволяли запустить сколько-нибудь ресурсоемкое приложение в 640К ОЗУ, системы же с большим объемом памяти были в то время редкостью. Больший объем памяти был доступен только на машинах IBM PC AT с процессором 80286. На таких компьютерах обращения к DOS требовали переключения в реальный режим процессора и поэтому происходили очень медленно.
Значительный прорыв в эксплуатационных характеристиках Windows 3.x обеспечил процессор 80386, на котором можно было создать для DOS виртуальный 8086. Это позволило избежать переключений режима процессора на каждом системном вызове и резко повысило производительность. Еще большее повышение производительности было достигнуто в Windows 3.11 с появлением так называемого 32-разрядного доступа к диску собственной дисковой подсистемы, которая работала целиком в защищенном режиме. Тем не менее, надежность даже этих версий системы оставляла желать много лучшего.
В Win 16 впервые была реализована технология, без упоминания которой описание этой системы было бы не полным не только потому, что это одна из немногих оригинальных концепций, впервые реализованных в системах семейства СР/М, но и потому, что эта технология оказала значительное влияние на современные методики разработки прикладного программного обеспечения. Речь идет о технологии COM (Common Object Model общая объектная модель).
Идея, лежащая в основе СОМ, довольно проста и решает весьма насущную проблему: точки входа DLL не хранят сведений не только о семантике соответствующих процедур, но даже о количестве и типах параметров, передаваемых этим процедурам. Различные системы программирования используют разные соглашения о способе передачи параметров заголовок DLL не хранит информации и об этом. Отсутствие перечисленных сведений затрудняет взаимодействие между подсистемами, реализованными на разных языках, и делает невозможным синтаксическую проверку допустимости вызова внешних процедур из интерпретируемых языков.
СОМ предполагает снабжение DLL внешним описателем, который перечисляет все процедуры, реализуемые данной DLL, и типы данных, используемые этими процедурами. Описание формируется на специальном языке IDL (Interface Definition Language язык описания интерфейса), который затем компилируется в двоичное представление, используемое объектными средами и интерпретирующими системами программирования. Современные системы программирования выполняют автоматическую генерацию IDL и "болванок"(заготовок) кода, реализующего данный интерфейс, на конкретном языке программирования.
IDL является довольно простым языком, на котором можно описывать объекты структуры данных, с которыми ассоциированы наборы процедур-методов. Поля структур (атрибуты) могут принадлежать одному из нескольких скалярных типов (целое число, число с плавающей точкой, дата и время, строка последний тип в большинстве компилируемых ЯВУ не является скалярным). Допустимы также атрибуты, являющиеся объектами других классов. Методы объекта в качестве параметров могут получать как значения скалярных типов, так и объекты, и используют стандартное соглашение о вызовах тем самым облегчается взаимодействие подсистем, реализованных на разных языках программирования.
Объектно-ориентированный стиль описания интерфейсов является популярной методологией описания и разработки сложных программных систем, поэтому, несмотря на многочисленные недостатки технологии СОМ (например, не поддерживается контроль версии интерфейса и наследование) она была хорошо принята сообществом разработчиков. Впрочем, заявленная в начале работ над этой технологией цель переход от монолитных приложений к компонентным средам, составляемым из взаимозаменяемых объектов СОМ достигнута не была. Достижению этой цели не способствовала также техническая политика Microsoft, состоявшая в низкокачественной и неполной документации и хаотических сменах флагманской объектной среды (версии OLE, ActiveX, OCX и т. д.).