Загадки и особенности установщика DOS 4.0 SELECT: история одного мастера дисков

Альткойны

В мире ретро-компьютеров и классических операционных систем существует немало интересных и порой неожиданных историй, которые позволяют глубже понять развитие технологий прошлого века. Одним из таких примеров является достаточно необычный опыт работы с IBM DOS 4.0 и его оригинальным установщиком SELECT, который, несмотря на свою кажущуюся простоту, оказался куда более «умным» и хитрым, чем кажется на первый взгляд. IBM DOS 4.00 дебютировала в 1988 году, и с тех пор вызвала массу споров и противоречий.

С одной стороны, это была одна из первых версий DOS, поддерживавшая большие жесткие диски свыше привычных 32 мегабайт – нововведение, без которого последующее развитие ПК было бы гораздо сложнее. С другой стороны, выпуск сопровождался многочисленными жалобами на нестабильность и неоптимальные решения, а DOS 4.0 во многих кругах пользовалась репутацией одного из менее удачных релизов в истории DOS. Инсталлирование DOS 4.0 в наше время — отдельное приключение, полное технических тонкостей и подводных камней, особенно если речь идет об оригинальных дискета-образах с 5.

25″ носителей, которые сейчас практически стали антиквариатом. Недавно один из исследователей, увлеченных сохранением компьютерной истории, наткнулся на редкий, и весьма поврежденный образ установочного диска IBM DOS 4.0 в формате SNATCH-IT — архиваторе и формате, сложном для декодирования и восстановления из-за специфики упаковки данных и многотомности. Особенность SNATCH-IT заключалась в том, что он использовал блоки данных размером в несколько килобайт, и если один блок оказывался поврежден, остальные часто оставались нетронутыми, что позволяло восстанавливать диск с минимальной потерей данных. Восстановление из частично поврежденного образа требовало тщательного анализа структуры и размещения секторов — процесс, напоминающий работу архивариуса с древними свитками.

После долгих усилий исследователю удалось запустить установщик, однако столкнулся с крайне необычной ошибкой: после первой перезагрузки инсталляция тотально зависала. Аналогичная ситуация наблюдалась с образом версии 4.01, несмотря на то, что файлы были идентичны. В поисках решения было обнаружено, что сам установщик SELECT оценивает физический тип дисковода, и исходя из этого решает, какую серию дисков воспринимать за установочную. Такая логика имела смысл в эпоху физических носителей, ведь 5.

25″ и 3.5″ дисководы отличались конструкцией и не могли читать диски друг друга. Однако в эру виртуализации, когда образы дисков назначаются виртуальному дисководу программно, ситуация усложняется. Виртуальный дисковод с типом 3.5″, пытающийся смонтировать образ на 5.

25″ диск, вводил установщик в заблуждение. Он ожидал, что будет работать с набором 3.5″ дисков, которого на самом деле не было, потому что образ представлял собой 5.25″ версию. В результате наблюдался полный отказ инсталляции.

Приведение виртуального привода к типу 5.25″ устраняло проблему, позволяя SELECT успешно продолжить работу. Помимо технических аспектов, интересно отметить, что SELECT проявлял «умное» поведение и в управлении установочными дисками. В отличие от типичного ожидания, когда при установке операционной системы пользователю предлагается создать записываемую копию установочного диска — так называемый SELECT COPY — этот установщик пытался сразу изменить оригинальный диск. Таким образом, если оригинальный диск был доступен для записи, программа просто модифицировала его, добавляя необходимые файлы и изменяя конфигурацию.

Только когда диск оказывался защищен от записи, она запрашивала у пользователя другую, пустую дискету для создания копии. Такой подход значительно снижал количество необходимых замен дисков и ускорял процесс установки, но мог ошеломить пользователей, ожидающих более стандартного сценария. Не менее любопытным моментом стала запись в так называемом „sluack space“ — незаполненной части последнего кластера системного файла DISKCOPY.COM, которая оказалась не случайным мусором. В этом пространстве были обнаружены текстовые строки, напоминающие сетевые пути, связывающие дисковый привод с некоторой сетевой машиной с названием SPIDERMAN.

Даты и время, присутствующие в этой фрагментарной информации, совпадали с временными метками на самом диске, что указывало на возможность того, что эти данные могли быть записаны еще при создании образа или мастеринге дисков в 1988 году. Подобные детали создают впечатление, будто кто-то задолго до появления полноценного интернета уже интегрировал сетевые элементы в процесс распространения и создания дистрибутивов DOS, что выглядит удивительно с исторической точки зрения. Тем не менее, подобные следы представляют собой уникальное окно в то, как создавалась и распространялась классическая ПО, показывая практические особенности работы разработчиков и инженеров того времени. Еще одним интересным аспектом DOS 4.0 стало то, что этот релиз содержал ряд особенностей, призванных обеспечить поддержание совместимости с версиями Windows 1.

x и 2.x. Появление DOS 4 сопровождалось значительными изменениям во внутренних структурах операционной системы, которые несовместимы с некоторыми предположениями ранних версий Windows. Вместо того, чтобы полностью отказаться от старых приложений или требовать от них обновлений, DOS 4.0 включала «хитрые манёвры», позволяющие скрыть изменения и представить устаревшим программам привычный интерфейс и поведение.

Таким образом, обеспечивалось более плавное переходное время и сохранение пользовательского опыта. Впоследствии в DOS 5.0 эта задача была решена более элегантно — посредством динамического «патчинга» исполняемых файлов в памяти, благодаря чему исправления вносились без необходимости изменения самих программ. Этот метод получил название exe-патчинг и стал важным элементом в обеспечении обратной совместимости с предшествующими версиями Windows и другими программами. Несмотря на все нововведения, DOS 4.