MATRIX

[Дмитрий]

Программа может создавать и использовать несколько окон для отображения в них текста или спрайтов.

Зачем так сложно? для генерации полноценного интерфейса надо загнать кучу вызовов для заголовка, текста, спрайтов, стандартных элементов управления, а потом каким-то образом еще обрабатывать данные манипулятора? Имхо, это не оптимально. Может упростить? Организовать вектор-описатель окна, где будут присутствовать объекты текста, графики и стандартные элементы управления с точками вызова определенных процедур, типа onrightclick/onleftclick/ondblclick. А так что придется для каждой проги писать свой интерфейс? Это не ведет к минимизации использования памяти и процессорного времени, наоборот в каждой программе будет свой обработчик сообщений от окна и не всегда оптимальный, что будет затормаживать реакцию на действие пользователя.

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

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

[psb]

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

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

в таком случае ось имеет тупик в своем развитии.

внимательно читаем:

(т.е. другими словами попытка создать такую среду разработки,чтобы "отвязать" вновь разрабатываемое ПО от дискет TR-DOS и от использования ПЗУ TR-DOS).

[Sayman]

чтобы "отвязать" вновь разрабатываемое ПО от дискет TR-DOS и от использования ПЗУ

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

[Дмитрий]

psb, невозможность использовать все руссурсы ПК и работа с ТР-ДОС не связаны между собой... к примеру ты пишешь граф-редактор с мультиколором и тебе нужны рессурсы для отрисовки экрана - система тебе их не дает... уже такой софт мы не будем писать под матрикс... Примеров программ с приоритетным использованием рессурсов компа масса и необходимо учитывать это при создании ОС.

---------- Post added at 13:31 ---------- Previous post was at 13:25 ----------

а форматирование и многозадачность в принципе могут друг с другом ужиться, я еще в далеком 98м году для экспериментов писал менеджер прерываний (менеджер задач, как угодно), который позволяет работать параллельно 2м задачам (легко переделывалось и под большее количество, главное придумать где стеки хранить), каждой задаче отводилось по инту, ну или если задача не нуждалась в расчетах - могла пожертвовать свое время другой с помощью системного вызова. На тот момент задачи были не мудреные - форматирование диска и игра питончик. и все прекрасно уживалось

[psb]

че вы прицепились к тр-дос? это, я думаю, одна из функций.
главное тут: среда разработки многозадачных приложений. всё.
естественно, для мелких автономных прог (в т.ч. мультиколора) это мало подходит (хотя, никто тебе не запретит сделать DI или перенастроить прерывания, главное с памятью корректно обойтись).
но зато сделать хороший текстовый редактор гораздо веселее. сделать плеер музыки (ay, gs). сделать инет-приложения. и это всё можно запускать одновременно в каких угодно сочетаниях. старый софт в принципе не возможно сделать многозадачным, поэтому не говорите ерунды. но можно его переделать так, что он будет запускаться практически с любого устройства.

---------- Post added at 16:41 ---------- Previous post was at 16:39 ----------

каждой задаче отводилось по инту,

и как же у тебя форматирование работало? оно жрет примерно 10 интов подряд, прерывать нельзя.

[Дмитрий]

и как же у тебя форматирование работало? оно жрет примерно 10 интов подряд, прерывать нельзя.

а это уже другой сложный вопрос.

че вы прицепились к тр-дос?

мы к нему не цеплялись - это афтор, а позднее ты заострил внимание на вытеснении ТР-ДОС.

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

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

[Advertiser]

[Sayman]

так, минуточку, псб. использовать прерывания собственно ручно в какой-то осе, несколько неверно. это задача самой ос. обработчики прерываний, дииспечер памяти и прочего, это всё задачи системы, а никак не кодера который пишет по. иначе. если мы начинаем писать собственные обрабочики прерываний, собственные драва памяти, собственные ...и т.д. то скажи, чем тогда эта ос отличается от программирования под трдос? что тогда эта система вообще предлагает? это получается, что одна програ написанная на пентагоне, будет идти только на пентагоне. а вот если быц система предоставляла ряд возможностей и если работать именно через функции системы, то твоя прога будет работать не только на пентагоне, смекаеш? а так в итоге, что 10 лет назад, что сейчас, что с приходом матрицы - кто в лес кто подрова... и при таком раскладе, не может быть речи ни про какую многозадачность! да и потом. она кому то тут нужна шибко? понты это всё на данной платформе. хочу заметить, что попытки реализовать многозадачность на спектруме были и ранее: домен ос пинк флойд, профивижн, ревос, реалтайм какая то ос, мифос..ещё была какая то, название забыл. и везде суть была одна и таже - глюки, тормоза, конфликты между по! матрица будет стоять рядом с ними. не надо делать упор на создание многозадачной системы - спектруму не подсилу такое при текущем развитие железа!

[psb]

но для этого надо реализовывать возможность переводить систему в резидентный режим,

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

не просто по DI/EI, а корректным способом - системными вызовами.

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

а это уже другой сложный вопрос.

ну расскажи, а то интересно это уже не просто многозадачность, это шаманство.

---------- Post added at 17:32 ---------- Previous post was at 17:24 ----------

п****ь, Sayman, ну че ты гонишь... че ты зацепился за прерывания? вы вообще читать умеете, нет? сделать предлагают среду разработки многозадачных приложений. до сих пор непонятно, что ли??? чем это отличается от автономок под тр-дос - читайте в 1 посте. тут и предлагается все через драйвера, единые точки входа, а не писать все самому. вы первые начали ныть, "а что если надо все ресурсы". вам предложили вариант, и больше ничего.

если конкретно вы не видите преимуществ написания хотя бы одной единственной программы под многопоточное ядро - проходите мимо, эта штука не для вас, пишите постаринке.

---------- Post added at 17:41 ---------- Previous post was at 17:32 ----------

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

лол
все под силу, если здраво рассуждать и не пытаться сделать невозможное.
я вот тоже как и многие, делал многозадачное ядро, довольно неплохое. оно работает без глюков! а если тот, кто делает корявый софт, сделает как всегда, то это НЕ проблемы этого ядра. так?

[Sayman]

psb во-первых, не стоит кипятица.
во-вторых, в первом посте что сказано? правильно

т.е. другими словами попытка создать такую среду разработки

речь идёт не про ось. а всего лиш про среду разработки.
далее по тексту четаем:

Ядро системы предоставляет минимум функций

если читать совсем внимательно, то увидиш, что

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

т.е иными словами ЧТО ТЫ БУДЕШ там писать? текстовую гляделку? уж извини, таких прог гора, солить и мариновать уже можно! граф редакторы? тоже самое.и в итоге что? в системе ничего толкового нельзхя написать. вэб броузер? ау, где вы, браузеры?!?!? нету..ниодной штуки. и в ближайшие год, два, три и до бесконечности не придвидецо. аська? туда же. сетевого интерфейса на данный момент у спека нет (есть но не в россии). диалапом сам пользуйся!
едем далее по постам автора:
речь про почтовые ящики. а автор в курсе что через регистры нескорлько быстрее передавать инфу, в том числе на нужные адреса, в которых указаны нужныве таблицы, логи, сообщения и прочее? коды отработки функций так вообще вне конкуренции - тратить столько времени на формирование сообщение, да потом ещё и опрашивать "а не было ли чего там при выполнении функии" - кащунство. это на пц может сканать. а тут извините, не так много железок.
и так далее снова по текстам аффтара:

Своп вообще НЕ НУЖЕН, иначе будет ТОРМОЗ

нормлаьная ос с многозадачностью не может пренебрегать наличием свопа! это очень сильный козырь, даже у венды, у ленукса, у юникса и у многих других. даже извините у доса есть надстройка, позволяющая делать свап.
так о чём это я?! я уже привёл спико "многозадачных" поделок. не поленись, взгляни на них. а то сидиш на том конце провода и стучиш пяткой в грудь, мол это крута, это надо, это реально. а я тебе по опыту эксплуатации говорю - ацтой! причём именно по спектрумау, т.к. пробовал и мифос и пинкфлойда и профивижн. как минимум три оси из вышеперечисленного списка. но в отличиие от матрицы, профивижн обладает ещё и почти полноценным ООП и такие понятия как класс и объекты там были введены ещё в 93м году! и при этом на спектруме, точнее на профи! а матрица пока что кроме возможностей просматривать текст с одновременным проигрыванием музыки. нифига толком преждложить не способна.
да чё тут спорить.

---------- Post added at 18:57 ---------- Previous post was at 18:54 ----------

добавлю ещё пару строк:
по поводу портирования староо софта. это без проблем. на цпм под профи помница несколько старых спековых игрух было портировано, в том числе эксолон.
игрухи с мсх и других клонов. а собственно при наличии сорцов,..да хоть Чёрного Ворона!

---------- Post added at 18:58 ---------- Previous post was at 18:57 ----------

делал многозадачное ядро, довольно неплохое. оно работает без глюков!

пример реализации в студию! иначе это всё трёп.

[Zet9]

Второе окно есть на АТМ, на одной из прошивок Pentagon 1024SL 2.x, на NGS.

Ещё на Профи есть, но включать туда вроде можно только одну фиксированную страницу (пусть владельцы Профи уточнят)
Ты предлагаешь делать проги так, чтобы прога могла пользоваться 2-м окном проецирования и включать туда страницы? - тогда они не будут работать на всех остальных Спектрумах,это не годится.
Или чтобы проги ничего про 2-е окно не знали, а сама система его использовала,когда прогам не хватает нижней памяти? Тогда можно в ядре это указывать и при отсутствии 2-го окна когда начинает не хватать нижней памяти, то куски нижней переносяться в верхнюю (это конечно долго, но процессы будут работать и не надо будет предыдущие усыплять)

Вложенными друг в друга геометрически.

Ну так там передаётся номер окна на которое воздействие (забыл об это указать , исправлю)
и соответственно, если у проги 3 окна - одно большое, а два других маленькие расположенные внутри большого,то по номеру определяется на какое окно произошло воздействие.
Ты это имел ввиду?

Программа со стеком в странице не может переключать страницы. Она не может даже вызывать функции ядра, которые лазят в другие страницы.

Не вижу проблемы!
В программе нет конструкций типа call куда-то в ядро , поэтому спокойно ядро включает страницу,когда прога кладет номер страницы в специальную ячейку памяти(за исключением функции wait (прога должна сделать call adr1),но её надо ещё продумать и ещё хотел все-таки прямое переключение страниц через call adr2добавить, чтобы не ждать прерывания(после которого произойдет переключение страницы), но тоже нужно придумать, как передавать adr1,2 от ядру проге(например при запуске в виде сообщения) )
так что поясни

---------- Post added at 16:44 ---------- Previous post was at 16:28 ----------

Представь, что задаче пришло сообщение и по нему надо что-то сделать с ресурсом. А ресурс занят. Что она будет делать? Если она будет ждать освобождения ресурса, то пропустит следующие сообщения.

Ну, значит. если для программы критичен пропуск сообщения, тогда она пусть сама создаёт очередь входящих сообщений
Приведи конкретный пример, вот я могу придумать,например прога проигрывания музыки на GS, прога ждёт готовности GS - а он не отвечает, а юзер тыкает кнопку отмена, а прога должна проверять сообщения между опросом GS