Board.KolibriOS.org

Mario79
"Сложность" в том что программисты ленивый народ. И если делать дескрипторы файлов то всё равно придётся занимать память ядра потому что пути относительно рабочего каталога общепринятая вещь. И расход памяти небольшой, в памяти редко висит больше 10 программ.

Serge
Программисты под Колибри не только ленивы, они еще бережливо ленивы.

Вообще относительные пути экономят время программистов (правда не разработчиков ядра ). Если программа расположена на /hdo/3/kolibri/programs/my_prog и должна читать несколько файлов из своего каталога и вложенных, то для каждого файла придется создать полный путь и ещё зарезервировать под него память обычно с запасом потому что malloc не все используют.

Serge
Зачем для каждого? Можно использовать то же пространство и копировать в конец пути имя файла. А все расчеты вообще можно произвести 1 раз.

Mario79
Если разные файлы читаются вперемешку то придётся каждый раз строить путь. Интересно как поступает FASM?

>Как минус утратится совместимость с МеОС

такие вопросы надо решать голосованием (потeря Quake/Doom, которые нельзя так просто перекомпилировать). Есть ли возможность проверять систему/версию (Меос, кос, эмуль) и если колибри, то использовать org std_application_base_address, а если меос или эмуль, то не использовать?

Решать конечно надо голосованием. А с Doom уже возникли проблемы после внедрения NTFS. Я пробовал найти портированные исходники но не удалось. Если кто-нибудь знает, дайте ссылку, может удасться прикрутить звук.

>Есть ли возможность проверять систему/версию (Меос, кос, эмуль) и если колибри, то использовать org >std_application_base_address, а если меос или эмуль, то не использовать?

Не совсем понял о чём идет речь. В принципе у новых программ будет нереально большое для MeOS значение app_start и app_mem. Наконец можно заменить "MENUET01" на "KOLIBRI ", тогда не будет никаких проблем с неподходящими программами. Это было бы логично после переименования menuet.img

Mike.dld спрашивал куда движется ядро.
Есть несколько идей.
Первую я уже предложил. Кроме уменьшения ядра есть ещё один плюс: будет проще портировать систему на 64 бита. Думаю такую возможность надо держать в уме.

Вторая идея - динамическое выделение pl0-стека. Это сэкономит около 1Мб ОЗУ. Верхние 512 байт займёт область сохранения FPU.
Новый стек будет в два раза больше - 8Кб. Это позволит при необходимости размещать в стеке больше локальных переменных.
Пробная версия работала но возникли проблемы с Qemu.

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

Serge
Надо чтобы менеджер памяти выделял непрерывные блоки большого размера под нужды ядра, тогда можно будет под фоновую картинку выделять, сколько нужно или совсем не выделять. Ну, в крайнем случае, опять же 4 Кб минимально (физическое ограничение). Например, если фон заливается одним цветом, то вообще по идее буфер не нужен, а память на старых машинах очень нужна под приложения и другие нужды ядра.
Слова:

Наконец можно заменить "MENUET01" на "KOLIBRI ", тогда не будет никаких проблем с неподходящими программами.

плохо стыкуются с:

Кроме уменьшения ядра

Как мне кажется, в этом случае ядро не уменьшится. Если оперировать уменьшением ядра, то с совместимостью придется полностью порвать.

Вообще потеря DOOM и еще пары или даже десятка игрушек для меня не критично. Я больше склоняюсь к развитию ОС в целом, и как следствие вполне обосновано будет "потеря" совместимости с Meos. Пока ОС молодая и для нее написано не так много софта, вполне можно принимать координальные решения, для улучшения системы. Я поддерживаю идеи которые высказал Serge.
________
Не откладывай на потом, то что нужно сделать сейчас.

Есть ещё одно предложение.
Перейти к програмной многозадачности. Большая часть регистров перед переключением задач сохраняется в стеке так-что
сохранение/восстановление регистров происходит фактически два раза. Для программного переключения надо только записать в esp указатель стека входящей задачи, после чего восстановить из стека регистры. Ещё надо загрузить новый значение cr3 и установить флаг переключения задачи для FPU, и записать в сегмент задачи новое значение esp0.
Правда при этом начнется геморой с битовой картой разрешения ввода-вывода. IMHO в Колибри от битовой карты никакого толка, но это отдельная тема. Эти битовые карты вместе с сегментами TSS занимают 2080 Кб, поэтому если оставить один сегмент TSS и одну общую битовую карту то сэкономится 2072 Кб. Плюс 1Мб экономии на стеке и ядро спокойно уместится в 8 Мб.
Ещё можно сэкономить на массиве display_data. Для него зарезервировано 1.6 Мб, реально нужно в режиме 640*480 - 300Кб, 800*600- 469Кб 1024*768 - 768Кб, 1280*1024 - 1280 Кб. Память экономится во всех режимах особенно в "ходовом" для Колиби 800*600.

Место для фоновой картинки можно выделять динамически уже сейчас с этим нет проблем.

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

Serge

Место для фоновой картинки можно выделять динамически уже сейчас с этим нет проблем.

Не знал, менеджер, который внедрил Андрей Халявин, позволял выделять только по 4 Кб непрерывного пространств за раз.
В принципе можно бы переписать код работы с фоном, но я, к сожалению, больше ядром не занимаюсь.
А для современных компов иногда возникает желание поставить фоновую картинку побольше, например 1280*1024.

Ядро спокойно уместится в 8 Мб

386 компам это не поможет - нужно еще уменьшать. Правда насколько я знаю есть и несовместимость связанная с применением 486 и Pentium команд.

На 486 ядро тоже не идёт. Но уменьшение ядра будет полезно для всех компов.

Ещё одно поясение по поводу нового базового адреса.

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

Потеря совместимости с МеОС никогда не была самоцелью, но ядро МеОС спроектировано не самым лучшим образом, причина в этом.

Mario79

В принципе можно бы переписать код работы с фоном, но я, к сожалению, больше ядром не занимаюсь.

Есть повод вернуться. Итак слишком мало разработчиков ядра осталость, а сделать можно ещё очень много.

Serge

Потеря совместимости с МеОС никогда не была самоцелью, но ядро МеОС спроектировано не самым лучшим образом, причина в этом.

Я с этим не спорил. С подобными утверждениями спорил прародитель ОС, но это уже оффтоп.

Еще OFFTOP:

Есть повод вернуться.

Я не пользуюсь услугами, которых меня в любой момент могут лишить, птичьи права для меня не рулят.
С того раза я не разу не пользовался ядром напрямую c SVN, беру только с сайта - на общих основаниях.

Mario79

Я с этим не спорил. С подобными утверждениями спорил прародитель ОС, но это уже оффтоп.

Я в этом не сомневался. Думаю некоторые так считают.