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

Everything you can't fit into other forums
  • Мне кажется, что должен быть, хоть самый примитивный desktop менеджер... чтоб иконки таскать и всё такое... ну и web браузер само собой. Вот этого, честно очень не хватает...
  • И чтоб работало на всех компах выше первого пня с 24-32мб озу и выше
  • Sniper
    Над 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.
  • Большинство уже есть. Вот с файлами имхо попотеть надо ядерщикам...
  • строковые - относительно ерунда
    *{scanf,printf} - чуть хуже, но вроде в консольной либе был printf

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

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

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

    Как я помню, в ядре есть функция для считывания байт (со смещения, в количестве, в буфер) - поэтому да, всё есть...
  • Ну так Андрей Халявин уже написал чтото ANSI C подобное, только реализация оставляет желать лучшего имхо. Без поддержки со стороны ядра становится нереализуема функция fopen(name, flags);
    andrew_programmer Как ты предлагаешь её сделать. Раз ты считаешь что "Ядро абладает достаточными возможностями", то наверно знаешь решение этой проблемы.
  • Victor
    Как я понимаю, FILE* суть node файла + текущее смещение + права + может еще что-нибудь :) Поэтому единственное что можно предложить - забить для этой фукнции на node и хранить filename, раз ядро в своей фукнции 58/0 получает ASCIIZ-строку...

    Ну и очевидно - структура процесса не хранит все открытые файлы..
  • > Без поддержки со стороны ядра становится нереализуема функция fopen(name, flags);
    andrew_programmer Как ты предлагаешь её сделать. Раз ты считаешь что "Ядро абладает достаточными возможностями", то наверно знаешь решение этой проблемы.

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

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

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

    Users browsing this forum: No registered users and 6 guests