Page 1 of 2

На пути к релизу 1.0

Posted: Thu Nov 16, 2006 12:46 am
by Sniper
Собственно вопрос таков, у вас есть план того, что должно быть в релизе 1.0?

наверное,
- библиотека GUI контролов
- библиотека 3D графики
- поддержка USB
- поддержка большего колличества AC'97 кодеков
и.т.д

Какой план развития ОС?

Posted: Thu Nov 16, 2006 7:31 pm
by Aqwas
Мне кажется, что должен быть, хоть самый примитивный desktop менеджер... чтоб иконки таскать и всё такое... ну и web браузер само собой. Вот этого, честно очень не хватает...

Posted: Thu Nov 16, 2006 9:54 pm
by camper
И чтоб работало на всех компах выше первого пня с 24-32мб озу и выше

Posted: Fri Nov 17, 2006 12:07 pm
by Mario79
Sniper
Над USB я начал работать, но теперь забросил, так как я официально больше не участвую в проекте (имеется ввиду ядро) и на SVN непосредственно не заглядываю (один раз меня туда уже не пустили, больше не хожу).
Все что можно от меня ожидать это приложения, сейчас работаю над одним проектом. Хотя наверное этот мой пост может считаться offtop'ом.

camper
Бесплатный сыр оплачивается кровью мышки. ;-)

Posted: Fri Nov 17, 2006 5:53 pm
by O01eg
чего мне не хватает в колибри, это компилятора С/С++ работающего из системы и обычного файлменеджера типа SYSXTREE только поддержку своих расширений добавить.

Posted: Fri Nov 17, 2006 9:05 pm
by andrew_programmer
У меня оффтоп,но по делу.
У нас на форуме так получается,что разговор частенько не по теме,но по делу.

Чтобы портировать компилятор metcc в Колибри,надо портировать следующие сишные функции:

memcpy dd ? ; DATA XREF: j_memcpyr
strlen dd ? ; DATA XREF: j_strlenr
malloc dd ? ; DATA XREF: j_mallocr
memset dd ? ; DATA XREF: j_memsetr
strcpy dd ? ; DATA XREF: j_strcpyr
strcmp dd ? ; DATA XREF: j_strcmpr
_vsnprintf dd ? ; DATA XREF: j__vsnprintfr
_iob dd ? ; DATA XREF: sub_403915+18Ar
; .text:00422204r ...
fprintf dd ? ; DATA XREF: j_fprintfr
longjmp dd ? ; DATA XREF: j_longjmpr
exit dd ? ; DATA XREF: j_exitr
memcmp dd ? ; DATA XREF: j_memcmpr
sprintf dd ? ; DATA XREF: j_sprintfr
_open dd ? ; DATA XREF: j__openr
_close dd ? ; DATA XREF: j__closer
_read dd ? ; DATA XREF: j__readr
memmove dd ? ; DATA XREF: j_memmover
strrchr dd ? ; DATA XREF: j_strrchrr
ldexp dd ? ; DATA XREF: j_ldexpr
_errno dd ? ; DATA XREF: j__errnor
strtod dd ? ; DATA XREF: j_strtodr
_snprintf dd ? ; DATA XREF: j__snprintfr
time dd ? ; DATA XREF: j_timer
localtime dd ? ; DATA XREF: j_localtimer
_getcwd dd ? ; DATA XREF: j__getcwdr
_setjmp dd ? ; DATA XREF: j__setjmpr
strtoul dd ? ; DATA XREF: j_strtoulr
strtol dd ? ; DATA XREF: j_strtolr
strchr dd ? ; DATA XREF: j_strchrr
fputc dd ? ; DATA XREF: j_fputcr
fwrite dd ? ; DATA XREF: j_fwriter
_fdopen dd ? ; DATA XREF: j__fdopenr
fclose dd ? ; DATA XREF: j_fcloser
_lseek dd ? ; DATA XREF: j__lseekr
strncmp dd ? ; DATA XREF: j_strncmpr
ftell dd ? ; DATA XREF: j_ftellr
fopen dd ? ; DATA XREF: j_fopenr
printf dd ? ; DATA XREF: j_printfr
fseek dd ? ; DATA XREF: j_fseekr
qsort dd ? ; DATA XREF: j_qsortr
fgets dd ? ; DATA XREF: j_fgetsr
_ftime dd ? ; DATA XREF: j__ftimer
atoi dd ? ; DATA XREF: j_atoir
_strlwr dd ? ; DATA XREF: j__strlwrr
realloc dd ? ; DATA XREF: j_reallocr
free dd ? ; DATA XREF: j_freer
_controlfp dd ? ; DATA XREF: j__controlfpr
__set_app_type dd ? ; DATA XREF: j___set_app_typer
__getmainargs dd ? ; DATA XREF: j___getmainargsr
dd 0

Выдрал из кода дизассемблером :)
Это не так уж и много,поэтому надо потихоньку их реализовывать.Я всё собираюсь это сделать(мне самому требуется,чтобы metcc работал в Колибри), да вот со временем не получается.Надеюсь как нибудь начну.
И ещё,портированные сишные функции должны в виде объектного файла,подключаемого при компиляции в metcc.После того как все необходимыt функции будут портированы необходимо скомпилировать metcc при помощи metcc.

Posted: Fri Nov 17, 2006 11:45 pm
by vectoroc
Большинство уже есть. Вот с файлами имхо попотеть надо ядерщикам...

Posted: Sun Nov 19, 2006 4:35 pm
by smb-
строковые - относительно ерунда
*{scanf,printf} - чуть хуже, но вроде в консольной либе был printf

Приличная муть, имхо - реализовывать семантику unix-open|close|read|write для работы с любым по типу дескриптором...
Правда, не уверен, что именно это нужно...

Да, ну и еще невеселая вещь - malloc + файловые...При отсутствии структуры типа FILE (как в обычных libc), кое-что становится нетривиальным =)

Posted: Sun Nov 19, 2006 5:13 pm
by andrew_programmer
>Да, ну и еще невеселая вещь - malloc + файловые...При отсутствии структуры типа FILE (как в обычных libc), кое-что становится нетривиальным =)

Ядро абладает достаточными возможностями,для реализации всех сишных функций для работы с файлами.Главное написать функции работы с файлами в stdio.h в соответствии с ANSI C.
Память ядро само выделяет,высвобождает.Такчто и это не проблема.Главное было бы кому писать всё это.

Posted: Sun Nov 19, 2006 5:24 pm
by smb-
А, ну да...Виноват, не с той стороны посмотрел :)

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

Posted: Sun Nov 19, 2006 5:26 pm
by vectoroc
Ну так Андрей Халявин уже написал чтото ANSI C подобное, только реализация оставляет желать лучшего имхо. Без поддержки со стороны ядра становится нереализуема функция fopen(name, flags);
andrew_programmer Как ты предлагаешь её сделать. Раз ты считаешь что "Ядро абладает достаточными возможностями", то наверно знаешь решение этой проблемы.

Posted: Sun Nov 19, 2006 5:35 pm
by smb-
Victor
Как я понимаю, FILE* суть node файла + текущее смещение + права + может еще что-нибудь :) Поэтому единственное что можно предложить - забить для этой фукнции на node и хранить filename, раз ядро в своей фукнции 58/0 получает ASCIIZ-строку...

Ну и очевидно - структура процесса не хранит все открытые файлы..

Posted: Sun Nov 19, 2006 5:58 pm
by andrew_programmer
> Без поддержки со стороны ядра становится нереализуема функция fopen(name, flags);
andrew_programmer Как ты предлагаешь её сделать. Раз ты считаешь что "Ядро абладает достаточными возможностями", то наверно знаешь решение этой проблемы.

Victor,я непонимаю в чём проблема.
Структура FILE должна хранит всю необходимую о файле ихформацию.При инициализации файла fopen(filename.flags) выделяют под структуру память.Потом читает информацию о файле,заполняет структуру и возвращает указатель на заполненную структуру.В чём проблема ? В написании кода :) ?

Posted: Sun Nov 19, 2006 6:04 pm
by vectoroc
В таком виде оно уже есть. Есть какая то структура FILE, при открытии создаётся буфер в АП процеса, через него происходит вся работа. При закрытии вызывается flush... В общем полный ANSI :). Но здезь же никак не учитывается синхронизация процессов. Если один отроет файл монопольно на запись другой не должен смочь его открыть. Хотя здесь я может ошибась. Мне показалось что ядро позволит хоть всем процессам открыть один файл и одновременно в него писать.

Posted: Sun Nov 19, 2006 6:09 pm
by smb-
Последнее абсолютно верно

Работа с FS сводится к низкоуровневому поиску по таблицам FAT + моментальная запись на диск, без всяких локов, буферизаций и кэшов

Впрочем, без KMA(kernel memory allocator) об этом можно особо не думать, имхо =/