про запуск в минимальной конфигурации монопольных программ: решается через своп. т.е. перед запуском система свой образ скидывает во внешнюю память, потом тупо запускает прог. в качестве свопа может быть заюзан даже флопоглот, с этим согласен даже великий и могучий, страшный волшебник, который изрек "640Кб хватит всем".
ну и тем более, если есть больше памяти и рам-диск.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ай, молодца.! Sayman не разобравшись,выхватил строчку из контекста сообщения и перевёл в недостаток.Сообщение от Sayman
Так вот обьясняю - о чем там шла речь, Alone говорил, что если программе по запросу предоставляется физические номера страниц, то не возможно организовать виртуальную память, то есть давать программе левые номера страниц (вместо настоящих), и потом, когда программа вызывает функцию включить страницу, то система смотрит - ага , нет сободных страниц, выбирает "жертву", у которой можно страницу забрать, сохраняет странцу в своп-файл, и отдаёт эту страницу проге,сделавшей запрос, а дальше мы имеем ТОРМОЗ,а именно, та другая прога , у которой была забрана страница, грит,типа, а ну подайте мене мою страницу , ща печатать картинки буду (или следующий кусок архива распаковывать), и начинается, система сохраняет страницу 2-й проги в своп-файл,загружает оттуда страницу для первой проги,первая прога начинает обрабатывать данные, а потом переключаются процессы и переключалка должна включить страницу второй проги,и опять всё по новой - сохранили загрузили - переключили
Вот про энто безобразие я и говорил, что его НЕТ, и НЕ БУДЕТ!!!
Специально повторяю, читайте внимательно!
Прога будет создавать свой файл, если система по запросу на выделение страниц скажет, мол, нет свободных страниц.
Ну а сама система будет использовать своп для того чтобы сохранять туда спящие процессы (кусками или полностью ) и тем самым она будет освобождать память для вновь запущенных прог
---------- Post added at 11:25 ---------- Previous post was at 10:55 ----------
Ну я бы назвал это так:
Вы говорите про меню - прямоугольник или квадрат со строчками текста, заголовком и возможно с маленькой картинкой(пиктограммой), а я говорю про окно (тот же прямоугольник) - в которое постоянно выводиться информация - даже если это просто листалка, посточно листаем текст и он в окне должен снизу вверх перемещаться - и как это в Вашем варианте осуществить? для вывода окна с тестком смещенным на одну строку вверх формировать новый описатель окна? - я пробовал в делать нечто подобное в минивиндовс98 - впечатление, что текст на бэйсике выводиться (в смысле очень медленно)
Ну, этот код спокойно располагается в страницах, а непрерывная память на него не раходуется
Ужасная идея! она не годится!!!
НИ В КОЕМ СЛУЧАЕ нельзя связывать кодера по рукам и ногам и указывать ему, что и где хранить - при такой схеме даже вьюевер 3-колорных картинок нельзя сделать!!!
Перелопачивать свои окна будут не все программы а только одна - которой придет сообщение - воздействие на её окно - в результате имеем немерянный выигрыш по скорости
а единый кодовый блок графсистемы займет немеряно памяти (он будет занимать не менен 8 кб (со 2 шрифтами) и 5.5 Кб с одним шрифтом) и теперь в Вашем варианте сюда надо добавить ещё кучу описателей каждого окна - Вы об этом подумали?
даже если описатель займет 200 байт - 10 окон это уже 2 Кб - и где их хранить? в странице с граф.подсистемой ещё место для процедур ядра нужно, или предлагаете сделать полноценный менеджмент памяти, который будет использоваться граф.подсистемой для манипулирования областями памяти с кучей описателей? или сильно усложнит код, увеличит занимаемую им память - и в результате стоит ли овчинка выделки?
Ничего сложного нет, кроме больших затрат памяти и процессорного времени
---------- Post added at 11:45 ---------- Previous post was at 11:25 ----------
Ну я же сказал - будет такая возможность - специальный вызов, для переключения страниц напрямую: типа прога делает call adr2 и страница сразу переключается без всяких "входов в режим ядра, поиск нужной функции , перевода номера логической в физический", только пока не определился с параметрами - вот склоняюсь к тому, что предлагает Alone - при заказе страниц система даёт проге два байта , прога не вникает в их смысл - а это байты,засылаемые в порты,тогда страница переключается максимально быстро
пример для Профи,проге надо две страницы и ей даётся 4 байта(#01,#10,#01,#11), она берет первые 2 байта и вызывает:
ld hl,#0110
call adr2
итого включается страница 8, а прога по барабану, она знаёт что теперь включена ПЕРВАЯ страница этой проги
а потом она берет вторые 2 байта и делает так
ld hl,#0111
call adr2
включается страница 9
и теперь прога знает что включена ВТОРАЯ страница этой проги
но это только для прога, которым нужна скоростное переключение страниц
а для остальных прог эти же 2 байта прога кладёт в ячейку памяти и после переключения процессов при приходе прерывания будет включена нужная страница.
Вот когда кто-нибудь перепишет драйвер винта для Nemo IDE на 32 бит, добывит в UZIX драйвер FAT16/32 (причем можно взять готовый), а потом обеспечит возможность запускать UZIX на Спеке - ну хотя бы таким образом - вот Вам набор файлов на винте - загрузите первый их них на адрес #6000 (например) и сделайте JP туда же и система UZIX дальше сама загрузиться и вот она готова к использованию - показывает приглашение на вход,
вот тогда мы (Спектрумисты) начнём изучать эту СИСТЕМУ,
а пока для больших винтов с FAT32 и cd/dvd приходиться использовать ту систему, которая есть, и УЖЕ запускаеться практически на любом Спектруме-128 b , и более
А я смотрю на это с другой стороны и вижу массу достоинств - вместо того чтобы сделать вызов функции call sys и управление от моей проги уходит ядро на неизвестно долгий период времени, в течение которого моя прога может сделать МАССУ полезных дел, я наоборот,даю системе сообщение, мол загрузи файл, а сам ПРОДОЛЖАЮ делать то, что мне нужно, ну вот хотя бы пример - показывалка слайдов из компресированных экранов,
пока система грузит следующую картинку, прога РАСПАКОВЫВАЕТ уже загруженную на 2-й экран,а пользователь видит на 1-м экране предыдущую картинку,раскпаковалась картинка на 2-й экран, прога включает его (ну естественно перед этим сделав getscr1,2)
пользователь видит картинку на 2-м экране, прога проверяет сообщение от системы и видит что уже следующая картинка загружена, дает собщение загружай очередную картинку, а сама начинает её только что заруженную распаковывать на 1-й экран
вот КОНКРЕТНЫЙ ПРИМЕР использования вызовов функции системы БЕЗ ОЖИДАНИЯ выполнения этого вызова
а какие там отличия от Систем 7, например,выложите плз,желательно на русском
конечно будет в виде условной компиляции - разные сборки ядра - например,ядро использует возможность подключать ОЗУ (кэш или страницу памяти) на адрес 0, или там для АТМ2- своя версия ядра и т.д.
---------- Post added at 12:19 ---------- Previous post was at 12:08 ----------
Согласен, на начальном этапе этогобудет достаточно
Ну,на том и порешили
Да будет ТАК!
и ещё обычно панель задач убирают с экрана
Как переключаться между окнами программ если на экране только видно только одно окно
Alone предлагает нажимать Caps Shift и Symbol Shift
Или дать возможность настраивать 2 варианта-
1) панель задач всё время торчит на экране в самой верхней строке
2) как в журналах (Deja Vu, Adventure) панель задач появляется вверху только тогда, когда подводишь стрелку в самый верх экрана
---------- Post added at 12:25 ---------- Previous post was at 12:19 ----------
планируется вызов wait - про него сказано на первой странице
чтобы не ждать прихода прерывания, прога размещает сообщение в почтовом ящике
и делает
call addr1 и тем самым ДОСРОЧНО прерывается её процесс и проиходит переключение на системный процесс, причем это процесс сначала доделает то, то он делал, и потом он выполняет вызов этой проги - таким образом НЕТ времени ожидания (до прихода прерывания), которое тратиться в пустую.
По сути ты будешь делать то же самое - система узнает какой проге принадлежит окно и отдаст ей управление, программа будет уже по своим описателям искать что это за координата, что там - кнопка или чекбокс и будет уже обслуживать его...
А теперь умнож объем кода обработчика каждой программы на количество окон... что мы имеем? для 10 окон у нас будет 10 блоков обработки, у каждого окна все равно будет табличка с координатами элементов - тот же самый описатель... и тут уже 2кб, как ты говорил - не отделаешься. Так зачем же изобретать очередное колесо?
Если будет скоростной режим переключения страниц, как ты думаешь - кто будет использовать "тормозной"? Стоит ли на него заморачиваться при его несостоятельности?
там же где будут хранить программы свои обработчики вызовов от графподсистемы. Да, я думал, я подумал, еще лет 10 назад, когда графическую либу с подобными возможностями делал.
Описатели будут храниться в коде программы или в сегменте данных - как угодно, зачем его хранить с графподсистемой вместе?
только ты не забывай, то при динамическом построении окна ты тратишься еще и на код прорисовки, а при взаимодействии с окном - еще и на код опроса. т.е. уже дважды не экономно используешь память.
И поддержка элементов управления со стороны программы усложнит и увеличит по времени написание программ, когда проще было бы создать описатель со свойствами нужных элементов и адресами обработчиков. И еще - мы теряем унификацию интерфейса - все будут делать как им проще и удобнее, не факт, что быстрее и оптимальнее. И представь - в памяти 3 программы и каждая будет содержать в себе по полноценной библиотеке интерфейса - зачем такие накладные расходы?
А полноценная графическая либа с выводом окон, текста в них, спрайтов, поддержкой мыши, с парой шрифтов и пр. у тебя все равно займет порядка 5-7 кб, не меньше... обработчик описателей - по сравнению с этой либой не много займет, т.к. во всю использует имеющуюся либу, и состоит всего лишь из цикла выборки кода объекта и передачи данных соответствующей процедуре прорисовки из графлибы.
---------- Post added at 13:49 ---------- Previous post was at 13:36 ----------
Я тебе за здравие - ты за упокой...
Т.е. если надо прочитать файл - то это надолго и можно положить в долгий ящик, что касается реализации интерфейса - то при почтовых ящиках и циклах ожидания мы получим дикий тормоз при рисовании окон и текста, выполнении каких-либо действий через системные библиотеки... тем более что почтовый ящик всего на одно сообщение...
Как я понимаю, менеджер задач будет раздавать задачам время кратное 1 период инта (на стандартной машине иного не придумать наверное), соответственно, если прога положила в почтовый ящик запрос на действие (любое) и ушла в цикл ожидания, то система обработает сообщение по приходу прерывания? или будет какой-то вызов для передачи управления?
я еще предлагаю сделать системный вызов для вызова подпрограммы, находящейся в другой странице.
т.е. допустим в 1й странице работает код и там:
ld hl,param1
ld de,param2
ld bc,param3
ld a,param4
call sys_long_call:db page3,address
sys_long_call включит 3ю страницу и вызовет прогу address, затем включит обратно старую страницу (1ю) и выйдет.
Зет, вот чес слово, ты сделай сначала. я не буду щас что-то говорить, ни хвалить, ни критиковать. ты сделай. попарь моск себе и людям)))) а то рассказываеш про возможности системы так. словно она пишется не для ZX-Spectrum, а как минимум для i486)))А я смотрю на это с другой стороны и вижу массу достоинств - вместо того чтобы сделать вызов функции call sys и управление от моей проги уходит ядро на неизвестно долгий период времени, в течение которого моя прога может сделать МАССУ полезных дел, я наоборот,даю системе сообщение, мол загрузи файл, а сам ПРОДОЛЖАЮ делать то, что мне нужно, ну вот хотя бы пример - показывалка слайдов из компресированных экранов,
пока система грузит следующую картинку, прога РАСПАКОВЫВАЕТ уже загруженную на 2-й экран,а пользователь видит на 1-м экране предыдущую картинку,раскпаковалась картинка на 2-й экран, прога включает его (ну естественно перед этим сделав getscr1,2)
так я же так и сказал на несколько постов раньше
Ну уж нет,ТАКИЕ ТОРМОЗА нам ни чему, для этого есть оффтопик,
а своп в память/рам-диск - только в случае отсутствия винчестера, ибо мало чего там
монопольгая прога натворит (вдруг зависнет и запортит верхнюю память)
да только же про это сказал:
Значится для второго типа вызовов, т.е. для вызовов функций граф.подсистемы прога будет
класть сообщение в ящик и передавать управление на адрес adr1 и произойдет переключение процесса на процесс граф.подсистемы, но он в этот момент может быть занят, поэтому он сначала доделает то, что делал (дорисует окно или допечатает текст), и после этого будет обрабатывать вызов.
Вот так годится?
Или придется делать реентерабельные графические процедуры и прога вызывает одну из них и процедура выполняется в то время, предназначенное для этой проги(типа печатает текст), а потом другая прога вызывает эту же функцию с этого же адреса (но процедура реентерабельная, так что она позволяет повторной вход в неё) и в то время, когда должна выполняться вторая прога, работает эта процедура и допустим она печатает спрайт.
Так можно , но это гораздо сложнее в реализации,
---------- Post added at 12:00 ---------- Previous post was at 11:45 ----------
Это легко добавить при условии, что основной код программы находится в нижней памяти,
только ещё надо придумать,как этот адрес sys_long_call передавать от системы проге (а то это уже третий адрес получается, 1-й - досрочное переключение с проги на граф.систему,2-й - скоростное переключение страниц)
Не боись! Сделаю! Но не сразу, за неделю такие вещи не делаются, надеюсь, ты это впиливаешь?
ВНИМАНИЕ,все свидетели, Sayman даёт честное пионерское слово, что не будет критиковать систему MATRIX.
Ну что ж, хочется в это верить
---------- Post added at 12:08 ---------- Previous post was at 12:00 ----------
ну вроде получается EXEC, а разве EXEC бывает отдельно от fork? или то execv вызывается после fork?ладно,буду курить матчасть
пока ничего не наследуется и не передаётся, лично я так и не понял, в чём прелесть этого
попробую, только на стандартном 128-м это не получиться, надо как минимум кэш цеплять,
ну а на остальных - да, (там только переделать надо, чтобы в таблице процессов удалённый отмечался не нулём(в поле старший байт адреса он отмечается), а например байтом #FF,но тогдп нельзя будет добавить процесс находящийся в странице по адресу #FF - вызовет ли это в будущем проблемы? пока не понятно)
---------- Post added at 12:25 ---------- Previous post was at 12:08 ----------
Зачем ты так гуворишь?
Проект MATRIX разрабатывается исключительно Just for fun
Вообще-то я думаю , что в окнах почти не будет таких стандарных элементов управления, или вообщен не будет, так как кодеры - существа ленивые (по своему опыту грю), и скорее всего никто из них не будет изучать, все эти радиогруппы, полосы прокрутки, ползунки, и переключатели,вот в Черной Вороне и в CHaOS - там я вникал - это всё так скучно, кодер скажет типа , да за то время, что я потрачу на изучение того, как всём этим набором пользоваться, я мог бы нарисовать 3 спрайтика (например кнопки для плэйера плэй.пауза.стоп) и десяток строк кода, который по полученным координатам от системы сравнит - в какую кнопку ткнул юзер и всё - вызовет процедуру
Я думаю, что если бы все кодеры хотели насытить окна массой стандарных элементов управления, то в большинстве прог так-бы и делали, но на самом деле этого за столько лет нет - не рисуют и не используют и не потому, что нет, как ты говоришь ,графлибы с подобными возможностями - а просто не радует,каждый хочет проявить индивидуальность.
Последний раз редактировалось Zet9; 05.09.2009 в 14:49.
Вместе хранить для скорости, так как поведение стрелки обрабатывается на прерываниях и если нажаты кнопки, то тут же начинается проверка заголовков окно, которые лежат в таблице рядом, а так как ты говоришь, надо будет пройтись по процессам, попереключать страницы для части их них и на всё это будет тратися время, забираемое после начала прерывания,
или другой вариант - тогда класть просто воздействие вовнутрь себя, а когда очередь дойдет до процесса граф.подсистемы, тогда она в течение фрейма будет проходить по памяти процессов (по их таблицам описателей-векторов окна) и сравнивать - но в этом случае будет запаздывание на несколько интов после момента воздействия - насколько это критично? - обнаружиться опытным путём?
Хотя как я уже сказал выше, по моему мнению - эти элементы не нужны, делать их "на всякий случай" - в первом посте сказал про это
ну даже вот полоса прокрутки - вертикальная - не нужна, она занимает знакоместо справа и не видно всю строчку текста, который отформатирован на 42 или 64 символа, значит строка переносится - не красиво,
горизонтальная - ну может только для схем и клавишами гораздо удобнее прокручивать, чем тянуться стрелкой, тем более в том же ворде, если сразу тыкаеш в самый низ полосы прокрутки, то ты не оказываешься в конце текста, текст листается постранично
всякие чекбоксы в которых надо галки ставить?
так просто у тебя строчка текста с пробелом вначале - по того как ты ткнул в неё вместо пробела напечатал галочку - типа включил опцию, еще раз ткнул, вместо галки напечатал пробел, типа выключил,
и там можно пройтись по всем элементам - НЕ НУЖНЫ ОНИ
тем более что их не будет ибо спектрумисты за все эти годы привыкли к системам меню и горячим клавишам
Вот предлагаю на первом этапе не заморачиваться с этим всем(набором описателей-векторов) ,а потом может быть на следующих этапах ,если будут кодеры жаловаться на их отсутствие, попробовать добавить их в отдельной граф.подсистеме (типа как в линухе GNOME,KDE и т.д.)
Меня уже тошнит от этих абсолютно одинаковых окон виндовс, то ли дело на Спеке,
загрузил журнал - одно оформление,загрузил, асм, коммандер, - другое , третье и т.д - всё такое пестрое, разноцветное- глаз радуется!
и потом я уже говорил про проявление индивидуальности
про быстрее и оптимальнее - кодер скажет - у вас там всё тормозит, я сделаю быстрее!
не буду пользоваться вашими процедурами!
Последний раз редактировалось Zet9; 05.09.2009 в 14:57. Причина: добавлено сообщение
А исходники данной ОС открыты? Если да, то дайте плиз глянуть на них.
Шутка.
Моё предложение по данному вопросу: Перенести тему в "Концепции" или во флейм, пока не появится хоть один бинарник.
Прочитал все четыре страницы и не увидел ни одной строчки кода(кроме неких расплывчатых примеров).
ну, я думаю эта фича должна быть именно в ядре (из-за работы со страницами, хотя хз, сделать можно всегда по-разному. я считаю, что открытая страница - часть контекста задачи, а по сему не важно, где находится основная прога, лишь бы стек у такой задачи был не в странице). пусть это будет 3й адрес, не думаю, что это страшно, сделать таблицу с адресами функций ядра и усё
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием