Проект ОС

[DimkaM]

Я прошу совета(вопрос очень тесно связанный с данной темой).
Ещё раз прошу совета:

А как грамотней организовать доступ к библиотеке процедур?
я вижу три варианта :
1.В начале либы пачка JP
2.Передавать номер функции через регистр
3.Номер функции в следующем байте после CALL

Вопрос очень простой, вариантов ответа только три,либо свой вариант.

[Vadim]

4)Суём параметры в стек
5)в регистре указываем адрес дескриптора на параметры.
и ещё и ещё и ещё можно придумать. Только я не понимаю зачем? Для чего? Тут была масса слов ни о чем. Обсуждение того, что сделано ещё в середине 70-х годов. И модули которые релоцируемые (запускаемый модуль который изначально неизвестно куда грузится, его релоцирует сама ОСь при запуске), и модули обработки придуманы (БДОС иБИОС в ЦПМ) и подгружаемые библиотеки RSX (вообще по смыслу получается что это были предки DLL). Всё это есть и придумано. В т.ч. как передавать параметры в эти модули. И как вести обработку в скрытых на момент вызова страницах, тоже все это уже реализовано и в ЦПМ 3 и в MSXDOS.

[DimkaM]

Опять двадцать-пять.
Как я буду передавать аргументы я уже определился - стек и регистры(в зависимости от потребностей либы).

Я немогу определится как буду вызывать функции.

1.В начале либы пачка JP
2.Передавать номер функции через регистр
3.Номер функции в следующем байте после CALL

Это варианты, а не последовательность действий.

[Sayman]

номер 3) пожалуй лучше отсеить - некрасиво, не удобно и вапще.
передавать параметры можно или через регистры, либо указателем на структуру с параметрами, либо через стэк.
в самой либе или пачку джампов либо писать подобие диспечера либо иметь структуру с адресами тех или иных функций...лучше всего посиди да поэксперементируй.
пошарь по гуглу и поспрашивай его на предмет либы rsx, она хоть и писана была под Ц64 (128?), но всё таки уже есть куда посмотреть. ещё вариант - посмотри на исходники библиотеки виндовс12 для цпм профика. но там чёрт ногу сломает...

[Vadim]

пошарь по гуглу и поспрашивай его на предмет либы rsx

RSX модули появились в CP/M 3 (CP/M Plus) и работало это везде где была установлена эта ОСь, а не только на C128. Это динамическое расширение API CP/M. Т.е. загрузили его - получили доп. функции в системе, можем его и выгрузить.

---------- Post added at 13:54 ---------- Previous post was at 13:53 ----------

Опять двадцать-пять.

Да) Я ж написал - суём параметры в стек. И номер функции вызываемой является параметром. И следующий пункт аналогично. Т.е. имеем только одну точку входа и через неё реализуем весь функциионал. Остальные способы (керналь из JP, байт после Call) ты описал.

[NovaStorm]

Я немогу определится как буду вызывать функции.

В идеале нужно поддержать какой-то стандартный (E)ABI. Я бы посмотрел сначала, что поддерживается компиляторами. А потом уже думать и, возможно, дорабатывать. Вроде неплохой док по похожей проблеме гуглится по "Motorola 8 and 16 bit Embedded ABI".

[Максагор]

Есть ли разделение на функциональные уровни (в CP/M & MS-DOS это: уровень интерепретатора команд (command.com или Norton), потом уровеь BDOS, ниже уровень BIOS. Между ДОС и биос есть подуровень загружаемых драйверов устройств (в msdos) - спец система, позволяющая нам интегрировать драйверы). Что есть в тазис? Ответ - НИ ЧЕ ГО! Пустота. Бред сивой кобылы на пустом месте. Имитация системы, имитация нортона, что бы можно было бы грузить блоки с дискеты (ну сейчас винт прикрутили, за почти 20 лет делания то можно уже было).

Я уж не помню, когда и где была та дискуссия, ноу да хрен с ней, важно только, что, как я понял, автору сего глупого комментария дали почитать доки, где описаны все уровни системы, а он уперся в книгу, да увидел лишь фигу. По собственной недалекость, видимо, А как еще интерпретировать то, что в описании уровней системы, которые имеются как и в любой ОСи, он их не заметил КАК КЛАССА? Впрочем, не будем плохо думать о человеке. Возможно ему дали ссылку не на то описалово. Поэтому дам ссылку я:
http://vtrdos.ru/book/ISD_REST.ZIP
Конкретно в архиве надо смотреть файл "Рестарты". Там описаны все уровни и их функции, начиная с самого нижнего и базового ( располагающегося выше всего в ОЗУ) и по очередности далее вниз в ОЗУ по принципу "матрешки". Причем очень походе на принцип BIOS-BDOS-CCP ЦПМки.

Повторяю вопрос, обращаю его апологету АТМ и тазис: Где есть структура системы. Где уровни? Где api? можно ли наращивать систему (как по горизонтали, так и по вертикали?), есть ли там понятие процесса? и т.д. и т.п.

Отвечаю ядро системы разбито на иерархическую систему уровней. Стандартно используется 5 (от 0 до 4), а максимально из может быть 8 (т.е. можно подключить еще тру уровня пользователя). Таковые временные "юзерские" уровни временно подключают, насколько я знаю, текстовый редактор и базы данных. Повторюсь, любой, нет, ЛЮБОЙ (в т.ч. и эти пять системных уровней) может быть удален и заменен на уровень собственного написания средствами системы. То есть наращивать систему таки можно "как по горизонтали, так и по вертикали".

И поэтому, кстати, неправда ваша, а наоборот большая ложь в том, что:

ну сейчас винт прикрутили, за почти 20 лет делания то можно уже было

Винт к iS-DOS "прикрутили" тогда же, в первые годы существования системы (TASiS как дальнейшего развития ОСи еще не было, но в плане поддержки внешних устройств TASiS ничего от исдоса не отличается). Вот только не "прикрутили", так как это не какая-то намертво прошитая в ПЗУ тырдосина, а просто написали подгружаемый драйвер (как и любой другой драйвер) под разработанный IDE-контроллер. Под контроллер АТМ действительно до последнего времени драйвер написан не был. НУ а причем здесь система?

Итак, возвращаемся к уровням. Каждый уровень обладает своим уникальным (и соответствующим функционалу уровня) набором функций. Их еще называют "рестартами". Тут уже придирались к этому слову, но называются они так, потому что вызываются через единую точку входа по RST 16 по уникальному номеру функции. Что из себя представляет API системы? Всего функций может быть до 256 - от #00 до #FF. Номер передается в регистре C. Различные дополнительные параметры, адреса таблиц и прочее и прочее - в других регистрах. Также в ответ функции в регистрах возвращают полезную информацию, флаги и прочее.

Структура адресного пространства при работе IS DOS.
0-й уровень ядра 65535
1-й уровень ядра
...
7-й уровень ядра
область драйверов и резидентных задач
область каналов $Stop
виртуальный диск (КЭШ)
программа пользователя $Utop
переменные TR DOS 23900
переменные BASIC 23746
область экрана 23552
ПЗУ BASIC SPECTRUM 48K 16384 (или неизменяемая часть уровней в iS-DOS chic)

За каждым уровнем системы резервируется по возрастающей по 32 рестарта. Каждый уровень имеет стандартный заголовок и таблицу рестартов, что очень удобно при из "прикручивании" и "откручивании". Каковы же основные уровни системы? -

0-ой уровень, он же "DOS.SYS"
Нижний уровень системы в iS-DOS (рестарты с #00 по #1F) работает с кэшем, блочными и символьными устройствами каналами и прерываниями. Этот уровень не знает ни о файлах, ни о командных строках, ни об оконной технологии. Всем этим занимаются более высокие уровни.
Именно здесь находится Супервизор ядра - программа, расположенная в нулевом уровне и обрабатывающая инструкции RST 16. Она анализирует содержимое регистра C и либо выполняет соответствующую подпрограмму ядра, либо - в случае ошибки - возвращает управление программе, вызвавшей RST 16, помещая код ошибки в регистр A и устанавливая флаг C в регистре состояния процессора. В TASiS в этом уровне лишь немного была изменена обработка прерываний. Все остальное осталось без изменений.
Этот уровень непосредственно работает с драйверами внешних физических устройств и является примерным аналогом уровня BIOS в системе CP/M.

1-й уровень: ФАЙЛОВАЯ СЛУЖБА (DUD.SYS) -
рестарты с #20 по #3F.
Этот уровень охватывает весь возможный основной спектр работы с файлами на логическом устройстве и является приблизительным аналогом уровня BDOS в системе CP/M. В TASiS этот уровень не менялся.

2-й уровень: ИНТЕРПРЕТАТОР КОМАНДНОЙ СТРОКИ COM.SYS -
рестарты с #40 по #5F.
Рестарты 2-го уровня системы занимаются в основном обработкой текстовых командных строк, из которых состоят batch-файлы, которые подаются в строковом мониторе mon.res (mon.com) и которыми запускаются любые командные файлы из оболочки при отработке нажатых клавиши <Enter> (строки пишутся в файле Q:extent.txt), клавиш <3> и <H> (extview.txt и extprint.txt в каталоге Q:SHELL\ соответственно) и, наконец, всех остальных клавиш, строки для которых описаны в файле Q:SHELL\extkey.txt. Обрабатывается командная строка в специальном системном буфере уровня. Размер буфера 128 байт. Этот уровень является приблизительным аналогом CCP в системе CP/M. В TASiS этот уровень не менялся.

3-й Уровень WIND.SYS: "Оконная система IS-DOS"
рестарты с #60 по #7F.
Уровень WIND.SYS содержит рестарты, обеспечивающие работу с окнами, строками символов, курсором и т.п. При помощи этих рестартов можно организовать вывод информации на дисплей, оформление рабочего экрана, а также организовать диалог с пользователем при помощи строкового редактора. Другими словами этот уровень - работа с текстом, рамками, атрибутами и прочим.
Этот уровень частично (но только очень частично) является аналогом CCP, а частично - той части BIOS, что отвечает за физический доступ к "железу" видеопамяти. С экраном взаимодействует через подгружаемые драйвера/шрифты/таблицы перекодировки.
Именно этот уровень был существенно переработан при написании OS TASiS.

4-й Уровень ОБОЛОЧКА (SHELL.SYS):
рестарты с #80 по #9F.

Тот самый "Нортон".
Это самый верхний уровень стандартной конфигурации системы iS-DOS. Выше него могут устанавливаться дополнительно еще три. Обычно это два уровня баз данных или уровень отладчика ВиОС.sys, 7-ой уровень временно занимается текстовым редактором. Замечу при этом, что уровни iSDOS не должны обязательно находиться в памяти один рядом с другим. Редактор, например, содержит 7-ой уровень прямо в себе, т.е. в файле edit+.com, и всего лишь помещает адрес своей таблицы рестартов в таблицу уровней, находящуюся в 0-ом уровне (DOS).
4-ый уровень, или уровень SHELL, содержит рестарты, позволяющие передавать управление нортонообразной оболочке, вызывать некоторые из ее функций, а также включает такие полезные подпрограммы, как редактирование десятичного числа и меню. Программы, не использующие данные функции, могут временно снимать верхние 2 уровня (3-ий и 4-ый) для увеличения свободной памяти в iSDOS Classic. Так поступает, скажем FORTH. Так работал копировщик copy_all.com. Обе программы запускались из bat-файла, в самом начале которых вызывалась программа set.com, снимавшая все лишние резиденты и эти 2 уровня. На выходе эти уровни можно было поставить обратно. Но, поскольку 4-й уровень (shell.sys) после установки необходимо инициализировать программой shell.com, то проще обычно перезагрузиться. В системе iSDOS Chic необходимость снимать верхние уровни отпала, да и выигрыш там был бы при этом очень небольшим - всего 1063 байта shel.sys + 764 байта twira.sys. Их адреса Вы можете посмотреть сами в программе show.com. Да и панелью пользоваться удобно во многих программах. Работать с отмеченными файлами, например, или открыть какой-нибудь файл, не выходя из программы, с помощью панели куда удобнее слепого ввода его пути и имени.

Этот уровень также был доработан при написании TASiS. Прежде всего, для вывода панелей и системных сообщений не на экран с текствой сеткой 42х24 как в iS-DOS, а 80х25. Также добавлены за счет задействования неиспользуемых рестартов менеджер страниц ОЗУ, работа с палитрой и экранными режимами.

[Максагор]

Вот такова в первом приближении структура операционной системы iS-DOS/TASiS. А за кадром осталось описалово системы подгрузки драйверов, резидентов и фоновых (висящих на прерывании) модулей и их цепочек, описалово работы с каналами и дисковым КЭШем. Это все можно будет изучить, в ссылке на архив с которым я дал и в котором нет только описаний нескольких новых специфичных только для TASiS рестартов, которых всего несколько и описание которых есть на любом дистрибутивном диске TASiS.

[Vadim]

Ужос! Во первых, какой нахрен блок из файла? Файл состоит, как логическая структура, из записей. А блок или кластер - это дела системы, разбираться в этом. Для нас файл это набор записей (по крайней мере так в операционных системах а не в исдосе). А именно ДОС занимается всеми вычислениями, мы ей задаем лишь желаемую запись файла, а ДОС делает ВСЕ необходимые вычисления, и вызывает БИОС, задав параметры уже физического сектора. Это первое. Второе. Кеш для ДОСа совершенно прозрачен. Кеш работает незаметно как для доса так и для биоса. Ну разве что есть функция сброс кеша (flush). Его заполнением занимается драйвер кеша.

---------- Post added at 08:47 ---------- Previous post was at 08:46 ----------

Вообще, миллион раз уже говорилось и мной и не мной, что софт спектрума в рамках ОСи работать не может. Так зачем городить огород? Зачем? Авторы издоса не были знакомы с теорий операционных систем, их вдохновил дос+нортон. Написали как смогли. Ну ладно. Дело то в том, что я не понимаю, не вижу причин что бы делать систему не совместимую с тем, что имеет наибольшее распространение+ наибольшее количество софта под данную ОСь и платформу. Если мы берем Z-80 то здесь - CP/M. Если разобраться, почитать что же делает издос и каков её функционал, то окажется, что она ведь не даёт никаких преимуществ относительно ЦПМ. Никаких. Реально её можно "выпправить" избавившись от уродств, переписать софт. Это будет что? Расширенная ЦПМ, с подгружаемыми модулями. Так и нужно было делать. Нет смысла ставить на спектрум нечто, когда у нас болтается 16К ПЗУ бейсика+16К трдос, этот вариант был изначально провальным. Всего 48К ОЗУ и на это была ориентация. Это неверно. Уже через год после появления издоса массово распространились машины 128К, а издосу было пофигу, не видел он её ОЗУ и не использовал в полной мере. Это глобальный минус. Глобальный.

Ошибку издоса повторили авторы estex на спринтере. Реально почитав описание системы видим, что она подобна ЦПМ, но при этом с ней не совместима. Это опять же минус - выкидываем весь софт какой был (обсуждать его здесь не будем, примем то, что он есть и его немало), взамен что получаем? Подобную ЦПМ ось без совместимости с оной.

Правильный, реальный вариант делать системы совместимую с ЦПМ, расширяя её функционал, как вот msxdos 2. Там работает почти весь софт ЦПМ (за исключением того, который работает с диском через ЦПМ БИОС) + имеем хандл-ориентированный ввод-вывод (т.е. прямая, нормальная работа с подгаталогами). Есть и процессы, есть IOCTL. Нужна графическая подсистема? Да не вопрос. Всё пишется и АПИ системы расширяется. Захотели другую оболочку для командной строки? Да не вопрос даже в обычной CP/M есть заменители для CLI.

Ещё скажу о издосе следующее. "система" крайне не приветлива для программистов. Ничего в ней не сделано такого, что бы облегчить жизнь при написании программ. Оно и ясно, часть того что обязана делать ОСь отдано программисту. Невероятные сложности для простых действий. Как будто капканы везде расставлены, всё не по человечески сделано. Почему так я уже объяснял выше и раньше много много раз.

[psb]

В чем логика "системы"? Как оно функционирует? Есть ли разделение на функциональные уровни (в CP/M & MS-DOS это: уровень интерепретатора команд (command.com или Norton), потом уровеь BDOS, ниже уровень BIOS.

итого, ты назвал 3 уровня. они же есть и в исдосе: 0,1,2+3+4+5+... что не так?

Повторяю вопрос, обращаю его апологету АТМ и тазис: Где есть структура системы. Где уровни? Где api? можно ли наращивать систему

структуру с уровнями показали? показали, ты признал те самые 2-3 уровня. апи показали? показали.

как я уже говорил ранее, в издосе (как и в тазисе) все понятия свои собственные. некоторым даже не известно, что насамом деле канал, это поток, а рестарт - это системный вызов (функция, процедура). но о чём это я...

и правда, о чем это ты ОПЯТЬ? я тебе на это уже возражал, что у такой мощной фирмы как ибм, да будет тебе известно, на мэйнфреймах своя терминология. приходишь в мир мф и теряешься, хотя разобравшись в терминологии понимаешь, что все это знаешь и видел раньше. и что??? о чем ты?

Вот ты не понимаешь что это уродство? Нет? А я понимаю. Где система управления памятью? Где она? Какие нахрен переменные basic? Какие переменные tr-dos? Как можно было писать такой бред, придумывать его?

1. твоей красивой системы еще никто не видел
2. а может быть это ты не понимаешь, почему там написано именно так в той таблице?
3. не кажется ли тебе, что ты бог? ну или гений? ну или что такую штуку как ОС изобрел именно ты? и это твоё право решать, какая ос правильная, а какая - нет? никто не говорит, что исдос - идеал, но... какая задача оси вообще? предоставить программе юзера некую прослойку с сервисами между этой программой и железом, больше ничего. исдос делает именно это. все делают именно это. а ты докопался к реализации.[COLOR="Silver"]

---------- Post added at 09:53 ---------- Previous post was at 09:46 ----------

Оно и ясно, часть того что обязана делать ОСь отдано программисту. Невероятные сложности для простых действий. Как будто капканы везде расставлены, всё не по человечески сделано.

еще 2 вопроса:
1. что ты сделал для исдоса, чтобы это заявлять? или ты тупо не разобрался?
2. где конкретно капканы, давай по пунктам, пока единственный знаток исдоса здесь только без стереотипов, что в ос что-то обязательно должно быть вот именно так, а не так.