Microsoft выпустил код MS-DOS 1.25 и 2.0 под лицензией MIT +28


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. Извиняюсь, что поздновато заметил новость, лучше поздно, чем никогда.

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (49):

  1. emmibox
    /#19233787 / +1

    Это идеальный набор примеров как раз именно для тех кто НЕ умеет в masm но хочет в него научится. Один из лучших «боевых» кодов для обучения программированию на ассемблере… стилю… методам…

    • StroboNights
      /#19233921

      Код очень аккуратный и продуманный, да. Другое дело, MS DOS этот использует только реальный режим работы; в нем нет страничной адресации, только сегментная. Соответственно, для обучения асму его можно рекомендовать разве что работникам музеев старого железа, ну или создателям эмуляторов.

      • emmibox
        /#19233951

        Адресация и .586 все только упрощают. Этот код можно будет сделать еще лучше и еще компактнее не меняя не стиля ни методов. И для обучения он в миллион раз лучше, чем широко распространенные туториалы построенные на анализе ассемблерных листингов типового С-шного helloworld-a.

      • vyatsek
        /#19243897

        Код очень аккуратный и продуманный, да
        Вряд ли Билли модицифировал этот код. MS DOS изначально назывался en.wikipedia.org/wiki/86-DOS и куплен был простым парнем Билли у Seattle Computer Products за жалкие 85k$ в 1981 году.
        А в Seattle Computer Products скорее всего работали грамотные парни

    • Sabubu
      /#19234389

      Не очень понятно, в чем смысл изучать давно устаревший и довольно убогий по нынешним меркам ассемблер 16-битного режима. Посмотрите на 32-битный или 64-битный код, с расширениями MMX, с расширенной адресацией, там одной командой можно сделать то, что в 16-битном режиме потребует отдельной подпрограммы.

      • u-235
        /#19234421

        Если мне не изменяет память, 8086 имел 24 способа адресации и основное отличие от защищенного режима, используемого в Windows, состоит в том, что в Windows сегментные регистры содержат ноль. И для старта MMX сложновато. Изучение подобного кода интересно с точки зрения оптимизаций, которые придумывал программист.

      • DrPass
        /#19234443

        там одной командой можно сделать то, что в 16-битном режиме потребует отдельной подпрограммы.

        Угу, вот только в подавляющем большинстве случаев вам ни одна из этих команд вообще никак не пригодится, и ваша 64-х битная программа все равно на 99% будет состоять из тех же самых команд пересылки, переходов и простой арифметики, что и 16-битные сорок лет назад.
        Если вы учите ассемблер х86, то исходники MS DOS посмотреть как минимум будет интересно. Если знаете и используете в работе, то естественно, никаких откровений там не найдете

      • rogoz
        /#19234699 / +2

        Сейчас в деле SSE/AVX расширения, MMX даже более бесполезен, чем «сопроцессор» (FPU), который тоже почти не используется, но там есть 80-битная плавающая точка.

      • emmibox
        /#19234833 / +1

        И где можно посмотреть на боевой 32-64 битный код на ассемблере из серьезного коммерческого проекта подобного уровня?

        • DrPass
          /#19234923

          серьезного коммерческого проекта подобного уровня?

          Хм. Хочу напомнить, что в этой статье идет речь о софтинке размером несколько десятков килобайт, которая была написана молодыми разработчиками с опытом работы год-два.

          • emmibox
            /#19234989 / +1

            Вы думаете, что в условиях «640кб хватит всем» у разработчиков этого кода были какие то проблемы с возрастом или опытом? А я думаю они задачи решали быстрее, чем набивали в терминалах того времени тот исходный текст…

            • DrPass
              /#19235227 / +1

              у разработчиков этого кода были какие то проблемы с возрастом или опытом

              Что вы? Не было, конечно. Ещё у них не было проблем с архитектурой, паттернами, тестами, да вообще ни с чем не было. Прелесть разработки софта в самом начале 1980-х была в том, что ты мог выучить полсотни операторов выбранного тобой языка программирования, сесть, и начать писать. И у тебя будет получаться не особо хуже, чем у опытных разработчиков. И то, что получилось, вполне можно будет даже продать. Если ты был в США, а не в СССР, конечно.

              • emmibox
                /#19235367 / +2

                Я не думаю что проблематика такой сущности как FAT (активно просуществовавшей от того момента и до наши дней) была в изучении пол сотен операторов языка, и что эта ее реализация могла быть выполнена кем то без опыта.

                • DrPass
                  /#19238263

                  Нет, конечно, не только в изучении операторов языка. Ещё надо было головой подумать, впрочем, как и всегда :) Но что у вас вызывает скепсис? FAT тех времён ничуть не сложнее, чем курсовые работы на ИТшных специальностях. Их же как-то пишут без опыта?
                  Да и кто разрабатывал FAT, это не секрет. Первую редакцию сделал Марк МакДональд, ему было тогда 21 год, потом усовершенствовал Тим Патерсон (тот, кто превращал QDOS в MS DOS), если не ошибаюсь, ему было 22, когда он этим занялся.

                  • emmibox
                    /#19240349

                    Вы помните жесткие диски тех времен? Сколько например в % битых секторов могло присутствовать в норме на абсолютно новом диске?! Сколько могло появится в процессе эксплуатации?! FAT тех времен — на абсолютных дровах работала! Многие поздние ФС таких дров даже в жизни не видели — и проектировались по совсем другим принципам в совсем другом мире…

                    • DrPass
                      /#19241125

                      Отлично помню. Как правило, на новых дисках могло быть несколько битых секторов, но их количество измерялось в штуках, от 0 до максимум десятка, а не в процентах. А ещё прекрасно помню, как в FAT реализован механизм защиты от подобных сбоев. DOS вызывает функцию форматирования сектора из BIOS, та форматирует сектор, и если контроллер накопителя при выполнении операции выдаёт отказ, DOS записывает в соответствующий кластер в FAT байт с кодом, указывающим, что кластер с этим сектором сбойный. И впоследствии при записи файлов этот кластер будет пропускаться.
                      Сложнейшая логика, да? Байт аж на десять. А то и целых пятнадцать. И проектировалась, наверняка, несколько месяцев.

                      • emmibox
                        /#19242407

                        Вы смотрите отсюда назад во времени. Вам кажется, что какие то вещи чрезвычайно просты, когда о них вы читаете в книжке. Но вот на момент создания, это было на самом деле сложнейшей логикой. А за 10ю байтами могли стоять месяцы проектирования и исследований. И было совсем не очевидно, как себя в реальности ведут эти диски и что делать, когда каталоги рассыпаются а что, когда электричество вырубают без парковки.

                        • DrPass
                          /#19242831

                          Вы смотрите отсюда назад во времени.

                          Я не вчера родился. Я моложе Билла Гейтса, но старше MS DOS :) И мне довелось под неё попрограммировать ещё тогда, когда это не было некромантией.
                          Но вот на момент создания, это было на самом деле сложнейшей логикой

                          Вы так плохо думаете о программистах 1970-х годов? Напомню, на момент создания MS DOS уже без малого десять лет существовали на порядки более сложные Юниксы, а также IBMовские OS/360 и т.д., многозадачные, с виртуальной памятью, разделением ресурсов.
                          А за 10ю байтами могли стоять месяцы проектирования и исследований.

                          Вы знаете, это сейчас, с нынешним диким спросом на ИТ-услуги, мы ухитряемся тривиальный код делать так, что работа на день растягивается на месяцы проектирования и исследований. А в те годы за такое бы у виска покрутили и сослали бы из программистов в лаборанты. Не было ничего подобного. Софт писался «как есть». Самым простым и очевидным способом.
                          И было совсем не очевидно, как себя в реальности ведут эти диски

                          Как написали в спецификации, так и ведут. Это была вообще не забота программистов файловой системы.
                          что делать, когда каталоги рассыпаются а что, когда электричество вырубают без парковки

                          Знаете, что делает файловая система FAT в таких случаях? Правильно, ничего. Она ничего не знает о проблемах с диском и валится вместе с ним. Вы точно считаете, что они потратили месяцы проектирования и исследований, чтобы прийти к этому решению? :)

                          • emmibox
                            /#19243793

                            Я старше самого x86 и под досом тоже программировал. И точно считаю, что они потратили месяцы и решения там появились не просто так. И наверняка у них были варианты нормально не работающие. Потому, что подобные вещи никогда не проектируются на бумаге с первого раза.

                            • DrPass
                              /#19244241

                              Ну, вам наверное виднее. Лично я не способен узреть рокет сайенс в плоской табличке с кодами кластеров, при том, что четверть века назад мы, подростки, под влиянием «Думов» вполне успешно писали простенькие 3D-движки за несколько дней, владея только Турбо-Паскалем и школьными знаниями тригонометрии. И большинство из нас даже программистами не стали. Поэтому извините, но гипотеза, что чувак, работающий программистом в Майкрософт, на изобретение структуры FAT потратил более пары вечеров, сдаётся менее достоверной, чем гипотеза, что нас вывели рептилоиды с планеты Нибиру :) Особенно если учесть, что до появления FAT уже существовали и более сложные файловые системы, и более простые. И было с чем сравнивать.

                              • emmibox
                                /#19244653

                                Формат файлов MSWORD наверно вам тоже не кажется rocket science… Вряд ли вы помните, что ДО него документация обычно представляла собой свалку из файлов <64к (сегмент)… А текстовые редакторы опять же имели ограничение памяти для работы в сегмент и менее и искали с воистину черепашьей скоростью.

                                • DrPass
                                  /#19245165

                                  Странная у вас логика, ей-богу. «Вы не едите жирное мясо? Наверное, вам не нравятся и помидоры?»

                                  Вряд ли вы помните, что ДО него документация обычно представляла собой свалку из файлов <64к (сегмент)

                                  Вы же вроде как говорили, что вы взрослый дядька, старше IBM PC. Тогда вы должны помнить (или хотя бы знать), что IBM PC — единственный популярный компьютер с сегментной адресацией памяти, и всё, что было ДО него, имело линейное адресное пространство, и всякие WordPerfect'ы (появившиеся раньше MS Word'а) сегментных ограничений на своих платформах не имели. Кроме того, формат файлов RTF появился аж в 1987-м году, а более знакомый нам бинарный формат — вообще в 1990-е. То есть это вообще другая эпоха.

                                  • emmibox
                                    /#19245245

                                    CP/M-80 например имела линейное адресное пространство — только там 64к было всей всей доступной памятью вообще и свалка состояла из еще более мелких файлов, и MS-DOS это все тупо наследовал.

                                    • DrPass
                                      /#19245809

                                      CP/M-80 например имела линейное адресное пространство — только там 64к было всей всей доступной памятью вообще

                                      Надо ж понимать, что это не свойство CP/M, а свойство тех компьютеров, на которых она работала. Хотя для домашних компьютеров 1970-х это и так был огромный объем памяти. Но компьютеры 1970-х не заканчивались машинками на MOS 6502 и i8080, были ведь и профессиональные архитектуры.
                                      MS-DOS это все тупо наследовал.

                                      Наследовал. Кстати, как и структуры файловой системы CP/M. Там она, правда, была основана на экстентах, но структуры корневого каталога и FCB оттуда перекочевали в FAT. По сути, изначально заменили только таблицу экстентов на таблицу кластеров.

              • boblenin
                /#19236341

                И надо заметить, что вояджер до сих пор летит без синего экрана смерти.

              • Ghost_nsk
                /#19236643

                У вас очень плохие знания в истории отрасли. 95% того что вы считаете современными архитектурами/паттернами и подходами к разработке было придумано в 60-70 годы. Тогда люди меньше времени тратили на болтавню в бложиках (за их отсутсвием) и больше на научную раборту. Вы наверное не былвали в технических библиотеках, после которых возникает улыбка от того что сейчас выдают за супер технологии. Ладно с узкой литературой, до которой доходят не многие, но например Кнут, которого знают даже школьники, писал в середине 60х. Не надо думать что раз тогда архитектура ПК была 16 битной, и только все начиналось (для ПК) то и писали код люди без опыта, у них была куча опыта и знаний, которые они получали на более серьезных архитектурах. А ограничения в вычислительных возможностях заставляли отпимизировать все и вся, так что там вполне есть чему поучиться.

                • DrPass
                  /#19238291

                  У вас очень плохие знания в истории отрасли. 95% того что вы считаете современными архитектурами/паттернами и подходами к разработке было придумано в 60-70 годы.

                  Я вас немного верну с небес троллинга на землю. То, что я (и другие специалисты) считают современными паттернами разработки, имеют вполне определённые даты появления. Первая публикация была в самом конце 1980-х. TDD — тоже детище 1990-х.
                  А Дональд Кнут в своих трудах описывал в первую очередь алгоритмы и структуры данных. Т.е. то, что многие современные программисты, в отличие от программистов тех лет, как раз нифига не знают, не умеют, и уверены, что им это и не понадобится. Причем, вполне вероятно, что так и есть.

                  • Eagle_NN
                    /#19240973

                    описывал в первую очередь алгоритмы и структуры данных. Т.е. то, что многие современные программисты, в отличие от программистов тех лет, как раз нифига не знают, не умеют, и уверены, что им это и не понадобится. Причем, вполне вероятно, что так и есть.

                    Именно по этой причине базы данных занимаю террабайты, а программа рассчитывающая коэффициенты экспоненты по набору точек работает минуты на современном ПК, хотя на 8086 данные убирались в мегабайты, а расчет длился секунды.
                    Но им это не понадобится.

        • cyberzx23
          /#19235591 / +1

          Последний проект, где я видел обширное применение ассемблера, это openssl.
          Причём ассемблер вполне там оправдан. Я сравнивал с ассемблерные реализации SHA256 и AES с сишным кодом в полной оптимизации на clang и gcc. Ассемблер оказался на 15% быстрее.
          Но поверьте мне, этот код довольно далеко уехал от кода тридцателетней давности.
          Если вы хотите писать быстрый код на ассемблере для x86_64, то надо не учить древний MS-DOS, а изучать архитектуру современных процессоров.

          • boblenin
            /#19236383

            Понятно, что x86 в чистом виде практически не актуален. Но ведь с нуля начинать писать под core i7 задачка та еще. Если изучать ARM-ы, то там весьма приличный зоопарк. Тут же возможность быстро усвоить принцип и даже что-то легко попробовать (в том же dosemu). Да просто создание .com файла это гораздо более быстрый путь к чему-нибудь работающему на asm, хотя бы из-за того что не надо сразу же разбираться с заголовками.

            • cyberzx23
              /#19239341

              Не понимаю какие именно принципы можно изучать. Я сам в детстве на уроке информатики программировал в фаре, ввода бинарные опкоды команд альтом, пока другие изучали ворд. Да, это весело и интересно, но не стоит питать иллюзий, что это даст какие-то навыки, которые можно применить в современном программировании.
              А если хочется разминки для ума, то есть много более интересных платформ, например почему бы не программировать z80?
              Да и под x86 реальный режим есть много очень крутого и интересного кода для вдохновения: исходники дума и других игр, известные демки особенно 256 компо и т.д.

              • boblenin
                /#19239353

                > Не понимаю какие именно принципы можно изучать.

                Адресация памяти, устройство стека, загрузка выполняемых модулей, выполнение условных переходов на уровне железа, доступ к оборудованию, обработка прерываний, работа с регистрами, в конце концов чтение дизасемблированного кода. Я думаю например все это можно изучать.

                > почему бы не программировать z80?
                z80 тоже хороший вариант, но исходников OS под z80 недавно не открывали. Я думаю это надо не противопоставлять, а считать что одно дополняет другое.

          • emmibox
            /#19237303

            Применение ассемблера в любой реализации AES оправдана только тем, что под него существует свой набор инструкций… Очень глупо его не использовать — это же отдельные затраты на куске кремния…

            Сравните например несколько реализаций древнего DES — от битности в них только косметическиe изменения.

            Опять же я например не вижу, зачем можно было бы писать быстрый код на x86_64. Какие то там буквально единичные приложения типа hashcat — и все…

            • cyberzx23
              /#19238959

              Для AES-NI ассемблер не очень-то и нужен, там есть интристики.
              Но не у всех алгоритмов есть хардварные реализации. И их можно реализовать на нативном ассемблере быстрее, чем это делают современные оптимизирующие компиляторы. Это сложно, муторно, требует знаний работы железа, но в результате это может дать вполне ощутимый профит.
              И конечно же, для такой работы никак не пригодится вдохновление ассемблерным кодом древнего доса.

            • boblenin
              /#19239309

              Во времена пентиумов-4 или атлонов тот же mplayer с ассемблерными вставками позволял играть DivX без дрыганья.

              • emmibox
                /#19240379

                А 99% других программ не позволяли — и это массово не прижилось…

                Новый ренесанс возможен будет после нескольких долгих лет упора в кремний… Когда маркетологам надо будет хоть что то предложить для понижения потребления-повышения производительности…

                • DrPass
                  /#19241183

                  Новый ренесанс возможен будет после нескольких долгих лет упора в кремний…

                  Могу только добавить, что даже у кремния есть ещё запас на много лет по оптимизации. Не за счет уплотнения техпроцесса, а за счет усовершенствования «схемогенераторов» а-ля Verilog, или ручной оптимизации.

                  • emmibox
                    /#19242421

                    Это просто отсрочка — а еще в аккумуляторах может свершится какой нибудь прорыв… но все равно в конце концов мы придем к тому, что надо будет избавится от любого лишнего исполнения кода в бекграунде мобильных устройств — а ассемблер останется единственным методом это сделать.

                    • boblenin
                      /#19242713

                      Как альтернатива — ML в оптимизациях кода.

                      • emmibox
                        /#19243797

                        Надеюсь к тому времени ручное написание кода будет забыто как страшный сон. И соответственно ML там нафиг не нужен будет.

      • VEG
        /#19236141

        Изучал в универе асм как раз на 16-битном x86. Когда захотелось пописать что-то под Widnows, я не помню чтобы тратил время на изучение особенностей 32-битного кода — и так с ходу было всё понятно.

        Если цель изучения — понять как пишутся программы на любом из ассемблеров, то можно изучать хоть ассемблер процессора 6502 (тут может даже чем проще архитектура, тем лучше). А потом, когда все принципы усвоены — справочник по нужному процессору в руки (сами вы всё равно все тонкости всех инструкций вряд ли запомните), и в бой.

    • CoolCmd
      /#19234757

      Это идеальный набор примеров как раз именно для тех кто НЕ умеет в masm но хочет в него научится.

      Если говорить о программе MASM (ml.exe), то научиться не получится, потому что современные версии сильно изменили синтаксис. В лучшую сторону.

      Исходники интересны в первую очередь как музейный экспонат. Примерно как утекшие исходники AWARD BIOS.

      • emmibox
        /#19234885 / -1

        Синтаксис ассемблерного кода x86 задан в instruction manual на x86 — и его нельзя изменить в какую то сторону не изменив этот документ, а этот документ может изменить только разработчик — который не был бы тем кем он является если бы по желанию левой пятки менял его в какие либо стороны.

        Что там куда поменяли в современных версиях masm никому не интересно (у меня например 8-я стоит сколько себя помню).

        • mpa4b
          /#19236321

          Попробуйте посмотреть, какой синтаксис генерят gnu-тулзы для х86 :)

          • emmibox
            /#19237369

            AT&T? ну пусть — а какую задачу решает изобретение другого синтаксиса на тот же самый камень?!
            Не как у всех? как кому то там удобно? чтоб не платить кому то за что-то?
            — все это было не нужно, даже когда этого не было!

            Напомню, что средства разработки на ассемблере с синтаксисом производителя в старые времена всегда за очень редкими исключениями были доступны бесплатно и неограниченно. Это только сейчас стало модно скидывать с себя любые задачи по написанию компиляторов на сторонние конторы.

  2. ianzag
    /#19233957 / -1

    Ааа Brown Interrupt List! Закапайте обратно :)

    • tormozedison
      /#19234717 / +1

      Нечего капать, у окулиста атропин кончился.

  3. alecv
    /#19235183 / +1

    Вот тут пытаются из «этого всего вот» собрать рабочую систему
    virtuallyfun.com/wordpress/2018/09/29/ms-dos-v1-25-and-v2-0-source-code-now-on-github/#comments

  4. Eagle_NN
    /#19236703

    Код явно не полный. По крайней мере в 1.25 не хватает очень большого количества файлов.