Некоторые мысли по поводу осей. Дан-
ная статья была написана довольно давно
под впечатлением бесед с самим ( С СА-
МИМ!:)) XOR'ом. Он даже говорил, что
есть люди, у которых есть подобные идеи
и он их опубликует в ближайшем номере
"Абзаца", но пока я что-то этих статей
не видел. Поэтому я решил не выбрасывать
этот текстик в небытие, а использовать
его для увеличения об'ема родной "Мур-
зилки".
----------------------------------------
Чем плоха is dos? Отвечаю по пунктам,
начиная с наиболее серьёзных недостат-
ков:
О) Несовместимость с Tr dos. Тот, кто
думает, что tr dos устарела/не отражает/
не позволяет/и т.д. не хочет принимать
об'ективную реальность: всё, что сделано
на спеке ( не считая таре loading ) сде-
лано под tr dos. И вот так вот просто
взять это всё и выбросить ( адаптировать
никто ничего не будет ) никто не согла-
сится. И даже, если будут писаться проги
под is dos или другую не tr dos систему
я, например, подумаю приобретать такую
программу или нет ( если прога под
isdos, то однозначно я её даже у друга
бесплатно копировать не стану );
1) Всё, что сделано в isdos тормозит со
страшной силой. Из этого пункта вытекают
несколько подпунктов:
а) Копирование файлов tr dos/ms dosis
dos представляет собой мазохизм, я уже
не говорю о попытках переностить файлы
из ms dos в tr dos и наоборот посред-
ством этой системы. При том, что такие
операции приходится проделывать очень
часто и с большими объёмами информации -
только под is dos никто не работает, по-
тому что люди на Спеке не бухгалтерию
ведь ведут и не используют его только
как печатную машинку/калькулятор. Им
нужны графические/музыкальные/и т.д.
редакторы/ассемблеры/упаковщики/и всё
прочее. Нужно сшивать много файлов в
один релиз - а это и в tr dos часто
делается в ручную, под is dos это всё
невозможно. Серьёзные люди скажут: да
ведь это же несерьёзно - сшивать проги в
один файл ( игру, например ). Если вы
хотите делать игру, создавайте для неё
каталог, подкаталоги, указывайте эти
подкаталоги в setup ( .ini ? ), в общем
устанавливайте ( слово-то какое страшное
) - для это os вам и запрограммирована.
А я спектрумист и, к тому же, люблю
иногда покодить и если программа < 255
секторов и занимает в каталоге больше 1
файла, то я считаю это леймом ( это, ко-
нечно, относится к готовым программам ).
Все это, повторяю, в isdos невозможно.
б) Я кодер и мне нужен ассемблер. Ска-
жу сразу - под isdos ассемблер писать
бесполезно. Там загрузка простого тек-
стового файла для его просмотра с мно-
жественными заездами головки по диску
вызывает массу неприятных эмоций. Что же
говорить про ассемблер с его
include/incbin'ами - даже представить
страшно ( уфф - и правда ужас какой-то!
). К тому же при написании вышеупомяну-
тый ассемблер сбрасывается сами знаете
сколько раз в единицу времени. Теперь
представьте, если бы вы каждый раз
загружали isdos...
2) Глюки, приводящие ( довольно-таки
часто ) к выводу из строя самой системы.
А так как авторы оси в своё время хотели
зарабатывать на ней денежку ( в чём их,
конечно же, никто не упрекает - похваль-
ное и понятное желание ) и копирование
системы занятие довольно-таки утомитель-
ное даже пиратскими копировщиками, не
говоря уже о легальном способе, который
могли придумать только извращенцы, то
все глюки ( сами по себе довольно безо-
бидные и характерные для любой и не
isdos проги ) опять-таки сильно дей-
ствуют на нервы.
Конечно, в isdos много плюсов. Однако
идеи, заложенные в ней, как мне кажется,
не совсем подходят Спектруму.
В общем я хочу предложить ряд мыслей
по поводу того, какими путями можно соз-
давать новую ось.
Во-первых, что я хочу от новой оси:
1) Совместимость с trdos - хотя бы на
том уровне, чтобы trdos проги без проб-
лем работали под новой системой; и про-
ги, сделанные уже под новую ось при же-
лании можно было запускать из trdos;
2) Многокаталоговость;
З) Максимальную скорость работы с дис-
ком: это значить никакой фрагментации с
кластерами, fat и т.д.;
4) Минимум ограничений на написание прог
под новую ось;
5) Возможность выхода из программ прямо
в систему ( без сброса компа ), наличие
какого-нибудь подобия буфера обмена;
6) Возможность отрытия файлов соответ-
ствующими программами.
Это минимальные требования.
Как всё это реализовывать. Во-первых,
основаная проблема - это стандарт: фор-
мат диска и связь системы с программами
( вход/выход из проги, адреса рези-
дентных программ load file/save file ).
Диск должен быть максимально похож на
нормальный trdos: корневым каталогом бу-
дет считаться обычный каталог trdos,
расположенный, как известно, на нулевой
дорожке. Подкаталоги можно разместить в
конце диска, пусть они растут сверху
вниз до пересечения с последним записан-
ным файлом. Совместимость с trdos дос-
тигнута. Осталось разработать стандарт
для работы с программами из системы. Для
этого необходимо найти место в памяти
для резидентов, обеспечивающих нормаль-
ных выход из программы, вход с загрузкой
нужного файла и работу программы с дис-
ком, если это нужно. А вообще работу с
диском каждый программист сможет напи-
сать сам, как это делается сейчас под
trdos и тогда область резидентов можно
будет грохнуть и т.о. останется только
подпрограмма выхода в систему. Т.е. не
будет практически никаких ограничений.
После разработки стандарта саму систему
сможет написать любой программист. Нап-
ример, можно будет сделать её точной ко-
пией jemini comander, но с подкаталогами
и прочими наворотами - вобщем кому как
захочется. Главное, что возможностей у
всех этих прог будет намного больше, чем
у всех существующих сейчас boot'ов.
Other articles:
