Каковы должны быть принципы новой ОС?

[dwt]

Вот что мне "нравится" в этом форуме что каждый отвечает так как он хочет... вот conan поставил ряд вполне грамотных вопросов, но никто не торопится на них попробовать ответить...

Об этом я и хтел сказать - давайте КОНЦЕПЦИИ!!! Ведь ответы на поставленные Conan`ом вопросы - это и будет обобщенная концепция!

Мы находимся в "гудке", причем полном на данном этапе у нас есть бейсик48, чуть расширенный 128й и эмулятор кассетных образов на диске ! - TR-DOS (именно с этой целью он и создавался)

Вот-вот, и я о том же. Тем более, плюс ко всему - обилие стандартов не только памяти и скорости, но и различных других временных характеристиках. То есть все эти неровности должна "сглаживать" ОС. А что у нас?...

хотим придти? хотим возможность доступа к HDD и CD-ROM, как на уровне выбора начальной загрузки, так и произвольный доступ к файлам (не знаю конечно, если вдруг кому и понадобится можно и поддержать в basic , типа как rand usr 15619:rem bla-bla-bla); так же хотим иметь возможность запуска одной и более программ в памяти одновременно, хотим переключения между ними.

Я думаю, что проблема во многом еще и втом, что мало кто представляетчто именно нужно, что именно необходимо. Говорят, необходимо поступить так-то так-то, как на платформе той-то. Но не будем забывать, что каждая платформа уникальная и то, что, к примеру, пригодно для С64 по каким-то уникальным аспектом не пройдет на Спектруме. Да, необходимо учитывать опыт, но работать надо в сторону своих, спектрумовских интересов. У Спектрума, на мой взгляд, основная "железная" проблема - это обилие различных вариаций схем, откуда, как я уже говорил, чрезмерное обилие стандартов. Поэтому и ОС необходимо ориентировать на сглаживание этих неровностей... Разве это не часть "постановки проблемы"?
Если мы справимся с этим аспектом (предусмотрение в ОС менеджера памяти, ориентированного на работу с драйвером памяти, в принципе подробная концепция изложена на соответствующей теме раздела), то уже тогда можно с помощью модульности и открытости подулючать hdd, реализовывать tcp/ip-стек, и т.д.

решения два: либо мы переписываем TR-DOS, BASIC и еже с ними (геморно, нудно, долго - но зато будет совместимо со страрым веком ),
либо мы посылаем всё к черту и пишем так как думаем с возможной эмуляцией среды для особо привязванных (программ и игр). Хотя я думаю что если программа ценна то её можно и отучить от того же ПЗУ. Но как мне кажется для новой ос - будут и новые программы...

Проблематично, на мой взгляд. Я думаю, вполне можно пойти путем, предлагаемым SfS, читай раздел "Менеджер памяти", там выложена интересная концепция.

[Advertiser]

[Ronin]

а, мысль номер три - пора бы обоснованно отваливать местами от асма к тому же си например. Культура программирования, например, структурность и тп, на асме нулевая (хотя тоже возможна). Т.е. пора бы серъезно задуматься о модульности, структурности и ЯВУ.

[Vladimir Kladov]

а что, уже появился приличный C для Z80?
а если в асм добавить IFcond ... ELSE ... ENDIF (кстати в некоторых вариантах асма это даже макросами можно сделать), то код получается вполне даже блочный. Если еще и PROC / EPROC есть, который позволяет ограничивать область видимости локальных меток, то вот вам и модульность. Не ожидаю особой радости от применения ЯВУ на спеке.

[Ronin]

Мы находимся в "гудке", причем полном на данном этапе у нас есть бейсик48, чуть расширенный 128й и эмулятор кассетных образов на диске ! - TR-DOS (именно с этой целью он и создавался)


хотим придти? хотим возможность доступа к HDD и CD-ROM, как на уровне выбора начальной загрузки, так и произвольный доступ к файлам (не знаю конечно, если вдруг кому и понадобится можно и поддержать в basic , типа как rand usr 15619:rem bla-bla-bla); так же хотим иметь возможность запуска одной и более программ в памяти одновременно, хотим переключения между ними.

решения два: либо мы переписываем TR-DOS, BASIC и еже с ними (геморно, нудно, долго - но зато будет совместимо со страрым веком ),
либо мы посылаем всё к черту и пишем так как думаем с возможной эмуляцией среды для особо привязванных (программ и игр). Хотя я думаю что если программа ценна то её можно и отучить от того же ПЗУ. Но как мне кажется для новой ос - будут и новые программы...

судя по тому "где мы" и "куда хотим прийти", все опять забыли про IS-DOS
чего жутко не хватало(ет) исдосу - нормального менеджера памяти. ну да ладно.

А вообще все тут говорят - разные схемы бла-бла-бла. но при этом вообще без оси под дырдосом пишут работающие проги, имея в качестве траблов только memory>128k. короче мысль в том что все эти отличия схем - несущественны, для ОС, на память - менеджер памяти, на диски - драйвера, и все будет работать. Никакой Спек не "особенный", все то же что и для других, тут работать будет. и более того - под исдосом ВСЕ это работает вполне корректно и удобно. вот только память там через одно место...

мысль номер два - отличия базовых архитектур минимальны, а вот перспективных и потенциальных (для которых ОС вроде как и планируется) - существенны, и вот именно БУДУЩИЕ архитектуры и должна корректно поддерживать ОС, даже пока они нам и неизвестны. Т.е. ВМЕСТЕ с ОС надо думать о новом железе (а вот вопрос его целесообразности, вернее экономической хотя бы неубыточности - под вопросом)

мысль номер три - блин забыл, пока думал первые две

[GriV]

1.Описание проблемы (где мы находимся)

Проблема в отсутствии единой среды разработки и единой среды пользования для компьютера ZX Spectrum любой модификации.

2.Цели разработки (куда мы хоти придти)

Хоти придти к созданию указанных средств.

3.Предлагаемое решение (путь)

Решение - создать многозадачную ОСь, создать ЯВУ (по крайней мере Си).

[GriV]

1. Физический уровень - драйвера
2. Системный уровень - виртульная машина
3. Пользовательский уровень - консоль/GUI и т.д.

Физический уровень написать несложно (память, FDD, HDD и т.д.)
Пользовательский уровень конечен и вообще говоря пока не важен.
Системный уровень - его собственно и предстоит разработать.

P.S. К уровням не придираться, упростил.

[captain cobalt]

А вот ещё немного ИМХО.

При проектировании ОС нужно решить много вопросов. Некоторые из них распадаются на подвопросы. Однако основные это:
-- Модель исполнения. Параллельность и синхронизация.
-- Управление памятью.
-- Ввод-вывод
-- Обработка прерываний (у Speccy их совсем немного)

По каждому из этих пунктов существует более одного архитектурного решения. И даже более двух. А это, фактически означает, что у каждого конкретного решения наверняка окажется больше противников, чем сторонников. И совсем не приходится надеятся, что удастся договорится по всем пунктам. Скорее всего, заинтересованные лица разделятся на десять и более групп (если наберётся достаточно человек) по разделению интересов. В такой ситуации неважно, кто прав, а кто виноват. В выигрыше окажутся те кто реализует на практике свои идеи, таким образом, навязав их всем остальным. Даже если эти идеи будут не самыми лучшими. Например, микрософт до сих пор доит б0льшую часть домашних пользователей ПЦ.

Я вижу только единственный способ движения вперёд. Кто-то должен предоставить РАБОТАЮЩИЙ, ДОКУМЕНТИРОВАННЫЙ, С ЧИТАБЕЛЬНЫМИ ИСХОДНИКАМИ, ПРИГОДНЫЙ К ДАЛЬНЕЙШЕМУ РАЗВИТИЮ прототип. Только вокруг конкретного, а не абстрактного центра кристаллизации могут собраться единомышленники. Именно так разработаны все открытые программные проекты. Другого пути нет.

[captain cobalt]

Теперь немного о культуре обсуждения.

Зачем обсуждать?
Такое ощущение, будто обсуждающие думают, что здесь присутствует большое количество "блестящих кодеров", которые только и ждут, когда им представят "гениальную архитектуру", останется лишь реализовать её и наступит счастье.

Зачем обсуждать?
Нужно ли обсуждать то, что давно исследовано, обосновано и изложено в УЧЕБНИКАХ по теории операционных систем? Не полезнее ли прочитать эти учебники? А на досуге изучить архитектуру нескольких конкретных реально существующих операционных систем, не укладывающуюся в прокрустово ложе этих учебников.

Тем не менее, я не против обсуждений. Но настоятельно рекомендую придерживаться правила
ОДНА ВЕТКА ФОРУМА = ОДНО АРХИТЕКТУРНОЕ РЕШЕНИЕ.
Что происходит при невыполнении этого правила вы видели - обсуждается, к примеру, конкретный метод управления памятью, потом вдруг приходит некто и "толкает" свою "идею". После этого некоторые участники продолжают обсуждать первую идею, в то время как другие переключаются на вторую. Через некоторое время возникает полная неразбериха. Создаётся ещё одна тема. В ней снова повторяется эта ситуация. Поэтому, если у кого-то есть конкретная идея архитектурного решения, он ДОЛЖЕН создать для неё новую тему. В этой теме будут обсуждаться достоинства и недостатки ТОЛЬКО одного этого конкретного решения. Такой более систематизированный способ обсуждений будет способствовать большей продуктивности этих обсуждений, и появлению новых, лучших, идей.

[captain cobalt]

Замечательно.
Только это скорее не "драйвер-ориентированная" а "модульная" система.

трдос есть у всех. в неё вносится менеджер драйверов/резидентов которыми может управлять любая трдос программа. т.о. есть у вас расширенный экран - загрузите драйвер вашего экрана и новые программы работающие с моделью драйверов будут его использовать.

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

[ukms[z]]

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

где ? не вижу проблемы разрабатывается стандарт общения с драйвером экрана, что-то типа zx-gl и всё. остальное - проблемы драйвера и чела его написавшего. разве мы могли в далёком 91 году подумать о том что сейчас видим в демках ?