Pull to refresh

Comments 24

Поскольку CP/M работала только на процессорах Z80
Z80 не требовался. Я переписывал CP/M в 90-х под Z80, но оригинальному варианту было достаточно Intel 8080.
Гейтсу сложновато было бы выкатить QDOS (по случаю удачно приобрести у невнятного стартапа) в сжатые сроки без исходников CP/M. Откуда он мог взять исходники? Исходниками с ним вполне мог поделиться сам Digital Research, ибо Гейтс пилил прикладной софт для CP/M и ему доверяли поскольку наши люди друг-друга не обманывают. Возможно это были даже исходники еще не выпущенной к тому моменту CP/M-86.

По этой же схеме он потом кинул и IBM с полуосью.
Исходники CP/M портировать на 8086 было бы практически невозможно, они там больше на ассемблере или чем-то подобном были написаны. Да и программный интерфейс CP/M (открытый) был не так уж и сложен, чтобы его реализовать на 8086 с нуля.
Портировать 8080 -> 8086 несложно: «Процессор Intel 8086 представляет собой модернизированный процессор Intel 8080, и хотя разработчики не ставили перед собой цель достичь полной совместимости на программном уровне, большинство программ, написанных для Intel 8080, способны выполняться и на Intel 8086 после перекомпиляции».

А вот сделать ОС по документации на API несколько сложнее. Wine/ReactOS тому примером. Вдобавок документированных API заведомо мало, чтобы обеспечить легкий перенос софта с CP/M, который последовал.
Вы вообще видели интерфейс CP/M? Там практически все вызовы — низкоуровневое управление аппаратурой. Смысла в трансляции ассемблера 8080 в 8086 для портирования CP/M — никакого, ничего работать просто не будет. Проще с нуля написать, что работники или подрядчики Гейтса и сделали, скорее всего. Благо простой интерфейс был.

Мода закрывать API появилась гораздо позже CP/M и MS-DOS. Собственно, успех CP/M в большой степени был достигнут как раз за счет того, что ее системные вызовы были хорошо документированы.
А также успех CP/M был достигнут и за счет того, что она была одной из немногих ОС на языке высокого уровня (PL/M) и за счет этого была легко переносима на разные архитектуры и их релизации. Без трансляции ассемблера, просто перекомпиляцией основной части. Легко переносима при наличии исходников.
Портировать PL/M и потом править все низкоуровневые процедуры (из которых и состояла большая часть CP/M) было бы гораздо сложнее чем портировать API CP/M. Собственно, реализация вызовов CP/M в *DOS довольно хорошо демонстрирует, что ее скорее писали заново, чем портировали — вызовы делаются через прерывания, а не простым CALL, отсутствуют некоторые важные составляющие (типа партиций дисковых, или как они там назывались), файловая система другая, ну и наконец — используется большая разрядность адресов.
CP/M был достигнут и за счет того, что она была одной из немногих ОС на языке высокого уровня (PL/M)

Не уверен.
В средине 80х делал «свою» ОСь для 8080, на основе реверс-инжиниринга (дизассемблирование в ручную!) СР/М. Не могу представить как можно с PL/M скомпилировать/декомпилировать передачу данных через стек вызова, прерывая вызов ожидаемым прерыванием. И подобных ассемблерных финтов попадалась масса.
Очевидно я шел по пятам за Биллом:
реализация вызовов CP/M в *DOS довольно хорошо демонстрирует, что ее скорее писали заново, чем портировали — вызовы делаются через прерывания

Только Я не писал, а переписывал. :)
Да собственно CP/M это, набор драйверов к железу + чуть чуть ФС.
Продолжая вспоминать молодость: еще попалась книжечка — брошюрка (не помню автора название) на основе которой запустил 8! разрядный СИ на том же 8080.
Начинал с перфолент > магнитофон кассетник > 7' флоппи.
Джеймс Хендрикс, «A Small C Compiler» — у нас была переведена и издана.
существует в электронном виде?
именно переведенной — как-то не видно.

public domain Small C, в т.ч. и от Хендрикса — есть.
Под CP/M был вполне приличный компилятор C, который генерил на выходе текстовый файл с программой на языке ассемблера (8080). Все основные конструкции (typedef, union и прочее в объёме Kernighan&Ritchie) работали без проблем. А вот оптимизации не было практически никакой, например конструкция i++ занимала на одну ассемблерную инструкцию больше, чем ++i, независимо от того, использовалось ли значение i в дальнейших вычислениях или нет.
Исходние коды обеих систем доступны, много людей на них смотрели и общий вывод что DOS не портирована с PL/M на ассемблер (DOS весь на ассемблере), а написан с нуля и от CP/M унаследовал набр вызовов, некоторые структуруры данных (в первую очередь FCB) и разбиение на три модуля.
PL/M — это не язык высокого уровня, а макроязык поверх ассемблера. Вы хотя бы посмотрите его синтаксис на его досуге. И ваш оппонент прав по поводу BIOS, т.е. API для CP/M. Его переносить просто смысла не было. Все операции проводились через Int. Даже оставить номера прерываний, то толку от такого «переноса» не будет. Другие программы с BIOS'ом не заработают.
После заключения сделки Microsoft и IBM, Digital Research подал в суд на обоих. Они и эксперты долго изучали исходники и сделали выводы, что QDOS — это clean room port. Точка.
С OS/2 вы тоже погорячились. Какие-то идеи Microsoft позаимствовала в NT из OS/2. Например, имплементация NTFS имеет схожие моменты c HPFS, но NT — это детище Дэйва Катлера, который OS/2 страшно ненавидел, и даже не хотел слышать про ее дизайн. В команду изначально даже не брал людей оттуда, а набирал со стороны. В NT больше от VMS, чем от OS/2. И, кстати WNT — это побуквенный ++ от VMS. :D Почитайте на досуге книгу «Show Stopper!». Очень интересная история про самого Катлера и культуру Microsoft того времени.
сделать ОС по документации на API несколько сложнее. Wine/ReactOS тому примером

Не надо сравнивать. BIOS — 2 килобайта, BDOS килобайт 6 или 8, не помню, драйвера: дисковод, экран, клава.
Всё это дизассемблировать не составит труда даже на машинах того времени.
Особенно учитывая уровень нердов, люди правили программы прямо в программе Monitor, в 16-ричных кодах :)

спасибо, интересная статья. буду ждать продолжения
Хорошая статья. Видно, что автор хорошо вложился в просмотр и чтение избранного от Кринджли. :) Радует, что его нетленки были приняты критически. Я много читал опусов, где либо Кринджли либо авторов «Fire in Silicon Valley» переводят или интепретируют буквально без всякой попытки анализа или проверки фактов.
Можно быть занудой и придираться к каждому слову, но тут я хотел бы отметить несколько моментов и неточностей.
Понятно, что автор следовал теории заговора и то, что Сэмс был нечестен, когда рассказывал историю договора с Digital Research. И там действительно есть много противоречивых историй. Во-первых, сам Гарри был сильно задет всей историей с IBM, и то, что Microsoft стала лидером, перепрыгнув через проект его жизни. Во-вторых, Гарри был любимцем индустрии. У него был замечательный характер, он разбирался во всех тонкостях технологий, учавствовал во всевозможных сборщиах и конференциях, был ментором у многих новых компаний/стартапов. Плюс, он писал статьи, был ведущим и продюсером популярной в течение долгого времени ТВ передачи «The Computer Chronicles». Ее выпуски легко найти на архивном сайте и на youtube. Кстати, фамилия у него все-таки «КилдАлл», а не «КилдОл». Ну это неважно.
По поводу истории встречи, есть несколько более поздних интервью с женой и дочерью Гарри. Плюс, большое интервью с его другом и участником тех событий (упомянутый в статье тоже) Юбэнксом. Последний также был в «Триумфе нердов». Но он давал и более поздние интервью с воспоминаниями о приезде IBM в офис DR. Его воспоминания в целом совпадают с тем, что рассказывал Сэмс. Так что, никаких оснований говорить, что он врет нет. Жена Килдалла не хотела подписывать NDA и не хотела разговаривать до подписания. Сам Гарри где-то мотался весь день. История про то, что он решил полетать на самолете, — это, наверное, легенда. И тут правильно подмечена линия про то, что IBM не хотели иметь дело с Гарри. Им проще было купить лицензию у Гейтса. Microsoft наобещал столько всего, что выполнить потом сам не смог. За счет IBM и его сотрудников пришлось потом дорабатывать QDOS. Но это уже другая история.
То, что лаба IBM во Флориде не имела бюджета для разработки компьютера с нуля и один год на разработку, — это факт. И то, что они из-за этого решили понабрать комплектующих отовсюду и впопыхах собрали компьютер — это не спекуляции Кринджли, а воспоминания самих участников проекта. Там же в «документалки» они про это и говорят.
Кстати, по поводу выбора Intel 8086. Просто стечение обстоятельств. У Intel'а был тестовый стенд с 8086, который они раздавали всем для отладки и тестирования решений на процессоре. Сам процессор был переходным, и никто не ожидал его продавать в больших количествах. Да и не было у Intel'а больших клиентов до IBM. Эти два фактора странным образом и сыграли свою роль в выборе процессора. Инженеры во Флориде уже имели опыт работы со стендом Intel'а. Intel не имел рынков сбыта для 86-го (точнее 88-го, но не суть). Когда IBM запросили ценнник у Intel'а, то те выкатили цену практически равнозначную тому, Commodore/MOS Technologies. Для i86 также были готовы микросхемы обвязки и сам стенд, т.е. уже готовая материнка и комплект чипов. Все входило в пакет сделки. Для компьютера на базе MOS надо было еще собирать свою плату. Подозреваю, что когда разговаривали с Atari, то получили неразумный ценник на разработку или лицензирование платы от Atari. Плюс, у самой Atari тогда дела пошли не очень.
Уже писали выше, что CP/M был написан для i8080, а не Z80. Последний просто был совместим с первым.
Softcard нужен был не пользователям Visicalc'а, который был изначально релизнут для Apple II, а не CP/M, а для софта самого Microsoft'а, куда входили интерпретаторы и компиляторы, которых для Apple II не было. Плюс, CP/M давала стандартный формат для дисков. Т.е. пользователи того же Visicalc'а теперь могли передавать файлы с Apple II, чтобы те могли читаться на других компьютерах.
Кривой перевод. «For hacking» пеерводится не как «для взлома», а как «для энтузиастов», или «для хакеров». Людей, которым нравится возиться с железом и делать всякие прикольные штуки just for fun.
Прочитал обе части оригинальной статьи, захватывающее чтиво. Очень понравилось. Теперь гораздо лучше представляю себе историю тех дней. Ещё бы почитать продолжение, но уже про становление windows и передряги с apple.
Да, это немного вымораживает. Поправить бы в статье.
Sign up to leave a comment.

Articles