Microsoft выпустил код MS-DOS 1.25 и 2.0 под лицензией MIT, см. соответствующий репозиторий на GitHub, на фразу «for reference purposes» внимание не обращайте, она устарела. Это тот самый код, который ещё в марте 2014 года стал доступен как shared source («смотри, но не трогай») на сайте Музея компьютерной истории (новость на Хабре). Всё, что изменилось теперь — лицензия, и она совместима с GPL.
Обе версии MS-DOS — очень старые, в них не поддержано многое из того, что заработало в последующих. Так, например, лишь во второй из них появились папки и перенаправление при помощи знака "|". Так что, несмотря на совместимость лицензий, вряд ли хотя бы строчка этого кода попадёт в FreeDOS или DOSBOX. Но делу улучшения совместимости анализ их исходников не помешает.
P.S. Там приложены и некоторые исполняемые файлы. Понятно, что BASIC и BASICA в DOSBOX не заработают, им нужен Бейсик в ПЗУ. А MODE заработал, но он «знает» только параметры 40 и 80, а параметры co40, co80 и mono ему неведомы. Ещё заработал MASM, но он для тех, кто в него умеет.
P.P.S. Извиняюсь, что поздновато заметил новость, лучше поздно, чем никогда.
Обе версии MS-DOS — очень старые, в них не поддержано многое из того, что заработало в последующих. Так, например, лишь во второй из них появились папки и перенаправление при помощи знака "|". Так что, несмотря на совместимость лицензий, вряд ли хотя бы строчка этого кода попадёт в FreeDOS или DOSBOX. Но делу улучшения совместимости анализ их исходников не помешает.
P.S. Там приложены и некоторые исполняемые файлы. Понятно, что BASIC и BASICA в DOSBOX не заработают, им нужен Бейсик в ПЗУ. А MODE заработал, но он «знает» только параметры 40 и 80, а параметры co40, co80 и mono ему неведомы. Ещё заработал MASM, но он для тех, кто в него умеет.
P.P.S. Извиняюсь, что поздновато заметил новость, лучше поздно, чем никогда.
Комментарии (49)
alecv
14.10.2018 22:51+1Вот тут пытаются из «этого всего вот» собрать рабочую систему
virtuallyfun.com/wordpress/2018/09/29/ms-dos-v1-25-and-v2-0-source-code-now-on-github/#comments
Eagle_NN
15.10.2018 11:50Код явно не полный. По крайней мере в 1.25 не хватает очень большого количества файлов.
emmibox
Это идеальный набор примеров как раз именно для тех кто НЕ умеет в masm но хочет в него научится. Один из лучших «боевых» кодов для обучения программированию на ассемблере… стилю… методам…
StroboNights
Код очень аккуратный и продуманный, да. Другое дело, MS DOS этот использует только реальный режим работы; в нем нет страничной адресации, только сегментная. Соответственно, для обучения асму его можно рекомендовать разве что работникам музеев старого железа, ну или создателям эмуляторов.
emmibox
Адресация и .586 все только упрощают. Этот код можно будет сделать еще лучше и еще компактнее не меняя не стиля ни методов. И для обучения он в миллион раз лучше, чем широко распространенные туториалы построенные на анализе ассемблерных листингов типового С-шного helloworld-a.
vyatsek
А в Seattle Computer Products скорее всего работали грамотные парни
Sabubu
Не очень понятно, в чем смысл изучать давно устаревший и довольно убогий по нынешним меркам ассемблер 16-битного режима. Посмотрите на 32-битный или 64-битный код, с расширениями MMX, с расширенной адресацией, там одной командой можно сделать то, что в 16-битном режиме потребует отдельной подпрограммы.
u-235
Если мне не изменяет память, 8086 имел 24 способа адресации и основное отличие от защищенного режима, используемого в Windows, состоит в том, что в Windows сегментные регистры содержат ноль. И для старта MMX сложновато. Изучение подобного кода интересно с точки зрения оптимизаций, которые придумывал программист.
DrPass
Угу, вот только в подавляющем большинстве случаев вам ни одна из этих команд вообще никак не пригодится, и ваша 64-х битная программа все равно на 99% будет состоять из тех же самых команд пересылки, переходов и простой арифметики, что и 16-битные сорок лет назад.
Если вы учите ассемблер х86, то исходники MS DOS посмотреть как минимум будет интересно. Если знаете и используете в работе, то естественно, никаких откровений там не найдете
rogoz
Сейчас в деле SSE/AVX расширения, MMX даже более бесполезен, чем «сопроцессор» (FPU), который тоже почти не используется, но там есть 80-битная плавающая точка.
emmibox
И где можно посмотреть на боевой 32-64 битный код на ассемблере из серьезного коммерческого проекта подобного уровня?
DrPass
Хм. Хочу напомнить, что в этой статье идет речь о софтинке размером несколько десятков килобайт, которая была написана молодыми разработчиками с опытом работы год-два.
emmibox
Вы думаете, что в условиях «640кб хватит всем» у разработчиков этого кода были какие то проблемы с возрастом или опытом? А я думаю они задачи решали быстрее, чем набивали в терминалах того времени тот исходный текст…
DrPass
Что вы? Не было, конечно. Ещё у них не было проблем с архитектурой, паттернами, тестами, да вообще ни с чем не было. Прелесть разработки софта в самом начале 1980-х была в том, что ты мог выучить полсотни операторов выбранного тобой языка программирования, сесть, и начать писать. И у тебя будет получаться не особо хуже, чем у опытных разработчиков. И то, что получилось, вполне можно будет даже продать. Если ты был в США, а не в СССР, конечно.
emmibox
Я не думаю что проблематика такой сущности как FAT (активно просуществовавшей от того момента и до наши дней) была в изучении пол сотен операторов языка, и что эта ее реализация могла быть выполнена кем то без опыта.
DrPass
Нет, конечно, не только в изучении операторов языка. Ещё надо было головой подумать, впрочем, как и всегда :) Но что у вас вызывает скепсис? FAT тех времён ничуть не сложнее, чем курсовые работы на ИТшных специальностях. Их же как-то пишут без опыта?
Да и кто разрабатывал FAT, это не секрет. Первую редакцию сделал Марк МакДональд, ему было тогда 21 год, потом усовершенствовал Тим Патерсон (тот, кто превращал QDOS в MS DOS), если не ошибаюсь, ему было 22, когда он этим занялся.
emmibox
Вы помните жесткие диски тех времен? Сколько например в % битых секторов могло присутствовать в норме на абсолютно новом диске?! Сколько могло появится в процессе эксплуатации?! FAT тех времен — на абсолютных дровах работала! Многие поздние ФС таких дров даже в жизни не видели — и проектировались по совсем другим принципам в совсем другом мире…
DrPass
Отлично помню. Как правило, на новых дисках могло быть несколько битых секторов, но их количество измерялось в штуках, от 0 до максимум десятка, а не в процентах. А ещё прекрасно помню, как в FAT реализован механизм защиты от подобных сбоев. DOS вызывает функцию форматирования сектора из BIOS, та форматирует сектор, и если контроллер накопителя при выполнении операции выдаёт отказ, DOS записывает в соответствующий кластер в FAT байт с кодом, указывающим, что кластер с этим сектором сбойный. И впоследствии при записи файлов этот кластер будет пропускаться.
Сложнейшая логика, да? Байт аж на десять. А то и целых пятнадцать. И проектировалась, наверняка, несколько месяцев.
emmibox
Вы смотрите отсюда назад во времени. Вам кажется, что какие то вещи чрезвычайно просты, когда о них вы читаете в книжке. Но вот на момент создания, это было на самом деле сложнейшей логикой. А за 10ю байтами могли стоять месяцы проектирования и исследований. И было совсем не очевидно, как себя в реальности ведут эти диски и что делать, когда каталоги рассыпаются а что, когда электричество вырубают без парковки.
DrPass
Я не вчера родился. Я моложе Билла Гейтса, но старше MS DOS :) И мне довелось под неё попрограммировать ещё тогда, когда это не было некромантией.
Вы так плохо думаете о программистах 1970-х годов? Напомню, на момент создания MS DOS уже без малого десять лет существовали на порядки более сложные Юниксы, а также IBMовские OS/360 и т.д., многозадачные, с виртуальной памятью, разделением ресурсов.
Вы знаете, это сейчас, с нынешним диким спросом на ИТ-услуги, мы ухитряемся тривиальный код делать так, что работа на день растягивается на месяцы проектирования и исследований. А в те годы за такое бы у виска покрутили и сослали бы из программистов в лаборанты. Не было ничего подобного. Софт писался «как есть». Самым простым и очевидным способом.
Как написали в спецификации, так и ведут. Это была вообще не забота программистов файловой системы.
Знаете, что делает файловая система FAT в таких случаях? Правильно, ничего. Она ничего не знает о проблемах с диском и валится вместе с ним. Вы точно считаете, что они потратили месяцы проектирования и исследований, чтобы прийти к этому решению? :)
emmibox
Я старше самого x86 и под досом тоже программировал. И точно считаю, что они потратили месяцы и решения там появились не просто так. И наверняка у них были варианты нормально не работающие. Потому, что подобные вещи никогда не проектируются на бумаге с первого раза.
DrPass
Ну, вам наверное виднее. Лично я не способен узреть рокет сайенс в плоской табличке с кодами кластеров, при том, что четверть века назад мы, подростки, под влиянием «Думов» вполне успешно писали простенькие 3D-движки за несколько дней, владея только Турбо-Паскалем и школьными знаниями тригонометрии. И большинство из нас даже программистами не стали. Поэтому извините, но гипотеза, что чувак, работающий программистом в Майкрософт, на изобретение структуры FAT потратил более пары вечеров, сдаётся менее достоверной, чем гипотеза, что нас вывели рептилоиды с планеты Нибиру :) Особенно если учесть, что до появления FAT уже существовали и более сложные файловые системы, и более простые. И было с чем сравнивать.
emmibox
Формат файлов MSWORD наверно вам тоже не кажется rocket science… Вряд ли вы помните, что ДО него документация обычно представляла собой свалку из файлов <64к (сегмент)… А текстовые редакторы опять же имели ограничение памяти для работы в сегмент и менее и искали с воистину черепашьей скоростью.
DrPass
Странная у вас логика, ей-богу. «Вы не едите жирное мясо? Наверное, вам не нравятся и помидоры?»
Вы же вроде как говорили, что вы взрослый дядька, старше IBM PC. Тогда вы должны помнить (или хотя бы знать), что IBM PC — единственный популярный компьютер с сегментной адресацией памяти, и всё, что было ДО него, имело линейное адресное пространство, и всякие WordPerfect'ы (появившиеся раньше MS Word'а) сегментных ограничений на своих платформах не имели. Кроме того, формат файлов RTF появился аж в 1987-м году, а более знакомый нам бинарный формат — вообще в 1990-е. То есть это вообще другая эпоха.
emmibox
CP/M-80 например имела линейное адресное пространство — только там 64к было всей всей доступной памятью вообще и свалка состояла из еще более мелких файлов, и MS-DOS это все тупо наследовал.
DrPass
Надо ж понимать, что это не свойство CP/M, а свойство тех компьютеров, на которых она работала. Хотя для домашних компьютеров 1970-х это и так был огромный объем памяти. Но компьютеры 1970-х не заканчивались машинками на MOS 6502 и i8080, были ведь и профессиональные архитектуры.
Наследовал. Кстати, как и структуры файловой системы CP/M. Там она, правда, была основана на экстентах, но структуры корневого каталога и FCB оттуда перекочевали в FAT. По сути, изначально заменили только таблицу экстентов на таблицу кластеров.
boblenin
И надо заметить, что вояджер до сих пор летит без синего экрана смерти.
Ghost_nsk
У вас очень плохие знания в истории отрасли. 95% того что вы считаете современными архитектурами/паттернами и подходами к разработке было придумано в 60-70 годы. Тогда люди меньше времени тратили на болтавню в бложиках (за их отсутсвием) и больше на научную раборту. Вы наверное не былвали в технических библиотеках, после которых возникает улыбка от того что сейчас выдают за супер технологии. Ладно с узкой литературой, до которой доходят не многие, но например Кнут, которого знают даже школьники, писал в середине 60х. Не надо думать что раз тогда архитектура ПК была 16 битной, и только все начиналось (для ПК) то и писали код люди без опыта, у них была куча опыта и знаний, которые они получали на более серьезных архитектурах. А ограничения в вычислительных возможностях заставляли отпимизировать все и вся, так что там вполне есть чему поучиться.
DrPass
Я вас немного верну с небес троллинга на землю. То, что я (и другие специалисты) считают современными паттернами разработки, имеют вполне определённые даты появления. Первая публикация была в самом конце 1980-х. TDD — тоже детище 1990-х.
А Дональд Кнут в своих трудах описывал в первую очередь алгоритмы и структуры данных. Т.е. то, что многие современные программисты, в отличие от программистов тех лет, как раз нифига не знают, не умеют, и уверены, что им это и не понадобится. Причем, вполне вероятно, что так и есть.
Eagle_NN
Именно по этой причине базы данных занимаю террабайты, а программа рассчитывающая коэффициенты экспоненты по набору точек работает минуты на современном ПК, хотя на 8086 данные убирались в мегабайты, а расчет длился секунды.
Но им это не понадобится.
cyberzx23
Последний проект, где я видел обширное применение ассемблера, это openssl.
Причём ассемблер вполне там оправдан. Я сравнивал с ассемблерные реализации SHA256 и AES с сишным кодом в полной оптимизации на clang и gcc. Ассемблер оказался на 15% быстрее.
Но поверьте мне, этот код довольно далеко уехал от кода тридцателетней давности.
Если вы хотите писать быстрый код на ассемблере для x86_64, то надо не учить древний MS-DOS, а изучать архитектуру современных процессоров.
boblenin
Понятно, что x86 в чистом виде практически не актуален. Но ведь с нуля начинать писать под core i7 задачка та еще. Если изучать ARM-ы, то там весьма приличный зоопарк. Тут же возможность быстро усвоить принцип и даже что-то легко попробовать (в том же dosemu). Да просто создание .com файла это гораздо более быстрый путь к чему-нибудь работающему на asm, хотя бы из-за того что не надо сразу же разбираться с заголовками.
cyberzx23
Не понимаю какие именно принципы можно изучать. Я сам в детстве на уроке информатики программировал в фаре, ввода бинарные опкоды команд альтом, пока другие изучали ворд. Да, это весело и интересно, но не стоит питать иллюзий, что это даст какие-то навыки, которые можно применить в современном программировании.
А если хочется разминки для ума, то есть много более интересных платформ, например почему бы не программировать z80?
Да и под x86 реальный режим есть много очень крутого и интересного кода для вдохновения: исходники дума и других игр, известные демки особенно 256 компо и т.д.
boblenin
> Не понимаю какие именно принципы можно изучать.
Адресация памяти, устройство стека, загрузка выполняемых модулей, выполнение условных переходов на уровне железа, доступ к оборудованию, обработка прерываний, работа с регистрами, в конце концов чтение дизасемблированного кода. Я думаю например все это можно изучать.
> почему бы не программировать z80?
z80 тоже хороший вариант, но исходников OS под z80 недавно не открывали. Я думаю это надо не противопоставлять, а считать что одно дополняет другое.
emmibox
Применение ассемблера в любой реализации AES оправдана только тем, что под него существует свой набор инструкций… Очень глупо его не использовать — это же отдельные затраты на куске кремния…
Сравните например несколько реализаций древнего DES — от битности в них только косметическиe изменения.
Опять же я например не вижу, зачем можно было бы писать быстрый код на x86_64. Какие то там буквально единичные приложения типа hashcat — и все…
cyberzx23
Для AES-NI ассемблер не очень-то и нужен, там есть интристики.
Но не у всех алгоритмов есть хардварные реализации. И их можно реализовать на нативном ассемблере быстрее, чем это делают современные оптимизирующие компиляторы. Это сложно, муторно, требует знаний работы железа, но в результате это может дать вполне ощутимый профит.
И конечно же, для такой работы никак не пригодится вдохновление ассемблерным кодом древнего доса.
boblenin
Во времена пентиумов-4 или атлонов тот же mplayer с ассемблерными вставками позволял играть DivX без дрыганья.
emmibox
А 99% других программ не позволяли — и это массово не прижилось…
Новый ренесанс возможен будет после нескольких долгих лет упора в кремний… Когда маркетологам надо будет хоть что то предложить для понижения потребления-повышения производительности…
DrPass
Могу только добавить, что даже у кремния есть ещё запас на много лет по оптимизации. Не за счет уплотнения техпроцесса, а за счет усовершенствования «схемогенераторов» а-ля Verilog, или ручной оптимизации.
emmibox
Это просто отсрочка — а еще в аккумуляторах может свершится какой нибудь прорыв… но все равно в конце концов мы придем к тому, что надо будет избавится от любого лишнего исполнения кода в бекграунде мобильных устройств — а ассемблер останется единственным методом это сделать.
boblenin
Как альтернатива — ML в оптимизациях кода.
emmibox
Надеюсь к тому времени ручное написание кода будет забыто как страшный сон. И соответственно ML там нафиг не нужен будет.
VEG
Изучал в универе асм как раз на 16-битном x86. Когда захотелось пописать что-то под Widnows, я не помню чтобы тратил время на изучение особенностей 32-битного кода — и так с ходу было всё понятно.
Если цель изучения — понять как пишутся программы на любом из ассемблеров, то можно изучать хоть ассемблер процессора 6502 (тут может даже чем проще архитектура, тем лучше). А потом, когда все принципы усвоены — справочник по нужному процессору в руки (сами вы всё равно все тонкости всех инструкций вряд ли запомните), и в бой.
CoolCmd
Если говорить о программе MASM (ml.exe), то научиться не получится, потому что современные версии сильно изменили синтаксис. В лучшую сторону.
Исходники интересны в первую очередь как музейный экспонат. Примерно как утекшие исходники AWARD BIOS.
emmibox
Синтаксис ассемблерного кода x86 задан в instruction manual на x86 — и его нельзя изменить в какую то сторону не изменив этот документ, а этот документ может изменить только разработчик — который не был бы тем кем он является если бы по желанию левой пятки менял его в какие либо стороны.
Что там куда поменяли в современных версиях masm никому не интересно (у меня например 8-я стоит сколько себя помню).
mpa4b
Попробуйте посмотреть, какой синтаксис генерят gnu-тулзы для х86 :)
emmibox
AT&T? ну пусть — а какую задачу решает изобретение другого синтаксиса на тот же самый камень?!
Не как у всех? как кому то там удобно? чтоб не платить кому то за что-то?
— все это было не нужно, даже когда этого не было!
Напомню, что средства разработки на ассемблере с синтаксисом производителя в старые времена всегда за очень редкими исключениями были доступны бесплатно и неограниченно. Это только сейчас стало модно скидывать с себя любые задачи по написанию компиляторов на сторонние конторы.