Собственно вопрос таков, у вас есть план того, что должно быть в релизе 1.0?
наверное,
- библиотека GUI контролов
- библиотека 3D графики
- поддержка USB
- поддержка большего колличества AC'97 кодеков
и.т.д
Какой план развития ОС?
На пути к релизу 1.0
Мне кажется, что должен быть, хоть самый примитивный desktop менеджер... чтоб иконки таскать и всё такое... ну и web браузер само собой. Вот этого, честно очень не хватает...
И чтоб работало на всех компах выше первого пня с 24-32мб озу и выше
Sniper
Над USB я начал работать, но теперь забросил, так как я официально больше не участвую в проекте (имеется ввиду ядро) и на SVN непосредственно не заглядываю (один раз меня туда уже не пустили, больше не хожу).
Все что можно от меня ожидать это приложения, сейчас работаю над одним проектом. Хотя наверное этот мой пост может считаться offtop'ом.
camper
Бесплатный сыр оплачивается кровью мышки.
Над USB я начал работать, но теперь забросил, так как я официально больше не участвую в проекте (имеется ввиду ядро) и на SVN непосредственно не заглядываю (один раз меня туда уже не пустили, больше не хожу).
Все что можно от меня ожидать это приложения, сейчас работаю над одним проектом. Хотя наверное этот мой пост может считаться offtop'ом.
camper
Бесплатный сыр оплачивается кровью мышки.
чего мне не хватает в колибри, это компилятора С/С++ работающего из системы и обычного файлменеджера типа SYSXTREE только поддержку своих расширений добавить.
У меня оффтоп,но по делу.
У нас на форуме так получается,что разговор частенько не по теме,но по делу.
Чтобы портировать компилятор 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.
У нас на форуме так получается,что разговор частенько не по теме,но по делу.
Чтобы портировать компилятор 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.
Большинство уже есть. Вот с файлами имхо попотеть надо ядерщикам...
строковые - относительно ерунда
*{scanf,printf} - чуть хуже, но вроде в консольной либе был printf
Приличная муть, имхо - реализовывать семантику unix-open|close|read|write для работы с любым по типу дескриптором...
Правда, не уверен, что именно это нужно...
Да, ну и еще невеселая вещь - malloc + файловые...При отсутствии структуры типа FILE (как в обычных libc), кое-что становится нетривиальным =)
*{scanf,printf} - чуть хуже, но вроде в консольной либе был printf
Приличная муть, имхо - реализовывать семантику unix-open|close|read|write для работы с любым по типу дескриптором...
Правда, не уверен, что именно это нужно...
Да, ну и еще невеселая вещь - malloc + файловые...При отсутствии структуры типа FILE (как в обычных libc), кое-что становится нетривиальным =)
>Да, ну и еще невеселая вещь - malloc + файловые...При отсутствии структуры типа FILE (как в обычных libc), кое-что становится нетривиальным =)
Ядро абладает достаточными возможностями,для реализации всех сишных функций для работы с файлами.Главное написать функции работы с файлами в stdio.h в соответствии с ANSI C.
Память ядро само выделяет,высвобождает.Такчто и это не проблема.Главное было бы кому писать всё это.
Ядро абладает достаточными возможностями,для реализации всех сишных функций для работы с файлами.Главное написать функции работы с файлами в stdio.h в соответствии с ANSI C.
Память ядро само выделяет,высвобождает.Такчто и это не проблема.Главное было бы кому писать всё это.
А, ну да...Виноват, не с той стороны посмотрел
Как я помню, в ядре есть функция для считывания байт (со смещения, в количестве, в буфер) - поэтому да, всё есть...
Как я помню, в ядре есть функция для считывания байт (со смещения, в количестве, в буфер) - поэтому да, всё есть...
Ну так Андрей Халявин уже написал чтото ANSI C подобное, только реализация оставляет желать лучшего имхо. Без поддержки со стороны ядра становится нереализуема функция fopen(name, flags);
andrew_programmer Как ты предлагаешь её сделать. Раз ты считаешь что "Ядро абладает достаточными возможностями", то наверно знаешь решение этой проблемы.
andrew_programmer Как ты предлагаешь её сделать. Раз ты считаешь что "Ядро абладает достаточными возможностями", то наверно знаешь решение этой проблемы.
Victor
Как я понимаю, FILE* суть node файла + текущее смещение + права + может еще что-нибудь Поэтому единственное что можно предложить - забить для этой фукнции на node и хранить filename, раз ядро в своей фукнции 58/0 получает ASCIIZ-строку...
Ну и очевидно - структура процесса не хранит все открытые файлы..
Как я понимаю, FILE* суть node файла + текущее смещение + права + может еще что-нибудь Поэтому единственное что можно предложить - забить для этой фукнции на node и хранить filename, раз ядро в своей фукнции 58/0 получает ASCIIZ-строку...
Ну и очевидно - структура процесса не хранит все открытые файлы..
> Без поддержки со стороны ядра становится нереализуема функция fopen(name, flags);
andrew_programmer Как ты предлагаешь её сделать. Раз ты считаешь что "Ядро абладает достаточными возможностями", то наверно знаешь решение этой проблемы.
Victor,я непонимаю в чём проблема.
Структура FILE должна хранит всю необходимую о файле ихформацию.При инициализации файла fopen(filename.flags) выделяют под структуру память.Потом читает информацию о файле,заполняет структуру и возвращает указатель на заполненную структуру.В чём проблема ? В написании кода ?
andrew_programmer Как ты предлагаешь её сделать. Раз ты считаешь что "Ядро абладает достаточными возможностями", то наверно знаешь решение этой проблемы.
Victor,я непонимаю в чём проблема.
Структура FILE должна хранит всю необходимую о файле ихформацию.При инициализации файла fopen(filename.flags) выделяют под структуру память.Потом читает информацию о файле,заполняет структуру и возвращает указатель на заполненную структуру.В чём проблема ? В написании кода ?
В таком виде оно уже есть. Есть какая то структура FILE, при открытии создаётся буфер в АП процеса, через него происходит вся работа. При закрытии вызывается flush... В общем полный ANSI . Но здезь же никак не учитывается синхронизация процессов. Если один отроет файл монопольно на запись другой не должен смочь его открыть. Хотя здесь я может ошибась. Мне показалось что ядро позволит хоть всем процессам открыть один файл и одновременно в него писать.
Последнее абсолютно верно
Работа с FS сводится к низкоуровневому поиску по таблицам FAT + моментальная запись на диск, без всяких локов, буферизаций и кэшов
Впрочем, без KMA(kernel memory allocator) об этом можно особо не думать, имхо =/
Работа с FS сводится к низкоуровневому поиску по таблицам FAT + моментальная запись на диск, без всяких локов, буферизаций и кэшов
Впрочем, без KMA(kernel memory allocator) об этом можно особо не думать, имхо =/
Who is online
Users browsing this forum: No registered users and 2 guests