Kolibri Foundation Classes (KFC)

Mon Jan 07, 2008 1:22 pm

Melian
вовсе не бред, а если указатели равны NULL? или оба указателя равны? твой вариант всё равно выполнит N итераций...
а то что вводится две переменные так это тоже ещё неизвесно как подействует на производительность и во что выльется конструкция
if ((const char*) (*s1)!=(const char*) (*s2))...
нужно ещё посмотреть...

Mon Jan 07, 2008 6:05 pm

Я убрал хрень s1==s2, потому что много писать не хотелось, а так хотите -добавьте.

2 andrew_programmer
А зачем давать что-то писать тем людям, которые пишут ересь? И где гарантия, что у вас лучше?

P.S. Я в биндингах на асме ничего не понимаю, так что показать, какой вы хороший программист не удастся

Mon Jan 07, 2008 7:26 pm

А зачем давать что-то писать тем людям, которые пишут ересь?

Что-то я непонял. Вы это про кого ? Про себя ?

И где гарантия, что у вас лучше?

Метод один - сравнивать с кодом menuetlibc.

Я поступаю так. Смотрю как функция реализована в menuetlibc. Если алгоритмическая реализация меня устраивает, то с небольшими изменениями(или вообще без них) код перекачёвывает в libCk. А если реализация мне не нравиться и я считаю, что могу сделать лучше, то я реализую свою версию алгоритма. В частности реализация работы с файлами в menuetlibc мне не понравилась. Можно сделать значительно проще, быстрее и компактнее(70-ая системная функция это позволяет).

Thu Jan 10, 2008 9:13 pm

andrew_programmer wrote:Что-то я непонял. Вы это про кого ? Про себя ?

Ух ты. Я, оказывается, пишу для Вас, сэр, код.
Извините, сэр, но мне кажется, вы заблуждаетесь, сэр. Я имел ввиду ваше стадо программеров, сэр. Мои знания в с/с++ поверхностны и несистематичны, как у мистера Холмса, сэр, так что я для вас негожусь.

P.S. Мне интересно, сэр, насколько ваши знания лучше моих.

Thu Jan 10, 2008 9:17 pm

А сколько в вашей библиотеке "с" асмовых биндингов, сэр?

Thu Jan 10, 2008 11:10 pm

path_of_milea
Напиши в личку ДеДок, и поинтерисуйся каким образом повела себя система в тестах. На своем предприятии он провел ряд тестов, об этом написано тут viewtopic.php?f=7&t=897
Все высказывания по поводу ненадёжности или лагах Колибри ОС основаны на личном мнении тех товарищей которые это пишут, я не видел ни одного реального примера того, что у них КООС зависла, как и не видел примера того что бы у меня зависла КООС. Их высказывания отражают только их субъективное мнение, причем оно не аргументированно.
Это как высказывание того что Таз(ВАЗ) это плохая машина. Любое мнение субъективно если оно не основанно на фактах.

Thu Jan 10, 2008 11:39 pm

path_of_milea, основные проблемы возникают с существующим программным обеспечением, а не с ядром. Для ваших задач, как я понимаю, все равно весь софт придется переписывать, так что вы сами внесете в конечную систему достаточное количество ошибок (это гипотетически конечно :-). Само ядро имеет небольшой объем по коду и соответственно ошибок в нем (те что еще не обнаружены) также не много.

..bw

Fri Jan 11, 2008 2:08 am

path_of_milea
Чрезвычайно интересно!... миллион вопросов по теме, и не менее предложений... хотелось бы понять концепцию вашего холодильника...

если вы хотите реализовать " Умный конторль", и ограничиться лишь технологической стороной дела, возможно, рациональнее использовать в качестве обработчиков однокристальные микроконтроллеры, либо готовые микроконтроллерные модули.если вы хотите сделать что - то в виде microSCADA, то очень удобно было бы использовать готовые панельные компьютеры, судя по их конфигурации КоОС прекрасно на них будет работать! Характеристики КоОС идеально подходят для создания подобных систем! а при написании программ легко и Винду убить, и Линукс, если под рутом сидеть...

Сама же КоОС очень надёжна, проста и неприхотлива, эксперименты это доказывают, кроме того, она быстро и без проблем загружается, что не маловажно для продуктов с программным техническим контролем и управлением...

Fri Jan 11, 2008 6:22 pm

ДедОк wrote: Сама же КоОС очень надёжна, проста и неприхотлива, эксперименты это доказывают, кроме того, она быстро и без проблем загружается, что не маловажно для продуктов с программным техническим контролем и управлением...

Золотые слова. Сделать бы на сайте/вики раздел "отзывы" и кинуть туда.

Fri Jan 11, 2008 11:19 pm

Ладно короче чать вторая. Потуги работать на KolibriOS есть, но пока увы хреновато, быват вся ось здрово виснет.
Компилируется с по прежнему с MinGW и пропускается через pk2kos дабы получить нужный формат файла.

хотя я не понял OMF или COFF юзает MinGW по дефолту и к чему преобразует pk2kos его в итоге (ну не асмовец я) . LibC не требуется заменил на самопал (в нем все и проблемы).

Fri Jan 11, 2008 11:26 pm

<Lrz> wrote:path_of_milea
Напиши в личку ДеДок, и поинтерисуйся каким образом повела себя система в тестах. На своем предприятии он провел ряд тестов, об этом написано тут viewtopic.php?f=7&t=897
Все высказывания по поводу ненадёжности или лагах Колибри ОС основаны на личном мнении тех товарищей которые это пишут, я не видел ни одного реального примера того, что у них КООС зависла, как и не видел примера того что бы у меня зависла КООС. Их высказывания отражают только их субъективное мнение, причем оно не аргументированно.
Это как высказывание того что Таз(ВАЗ) это плохая машина. Любое мнение субъективно если оно не основанно на фактах.

Ну повесить ее в десять раз проще чем винду и тем более линух. Суть в том что ядро KOS плохо защищено от вредоносных деяний пользовательского процесса. В итоге отладка ПО превращается в кромешный ад.

Sat Jan 12, 2008 12:35 am

Ну повесить ее в десять раз проще чем винду и тем более линух.

Пожалуйста код, вешающий систему. Ну или по крайней мере бинарник.

Суть в том что ядро KOS плохо защищено от вредоносных деяний пользовательского процесса.

SHREDER, а ты случайно не про эмулятор говориш? Ты проверял код на реальной KolibriOS, а не под эмуляторами, виртуальными машинами и т.д. ?

В итоге отладка ПО превращается в кромешный ад.

В mtdebug нормально отлаживать, надо только ассемблер знать.

Sat Jan 12, 2008 12:45 am

andrew_programmer

Грузишь любой файл в память начиная с адреса 0х8000 0000. Это навскидку. Многие функции записывающие данные в буфер не проверяют адреса и запросто затирают ядро.

Mon Jan 14, 2008 7:40 pm

andrew_programmer wrote:Из-за того, что menuetlibc алгоритмически сильно неоптимальна, я решил, что легче
написать новую libC чем переписывать menuetlibc. halyvin писал libC с нуля, а
потом это дело заглохло из за нехватки времени. Я взял исходные коды этой библиотеки
за основу. Вычистил из неё ошибки(их там было очень много). Добавил новые функции.
В частности функции форматированного вывода. Не все функции полность соответствуют
стандарту, так как дописать их до конца у меня просто нет времени. Я пишу только те
функции, которые мне нужны для моей научной программы.

Melian, как насчёт присоединения к разработкам libCk ?
Недостающие обертки на ассемблере для системных вызовов я могу написать. В текущей
libCk часть обёрток уже есть. А высокоуровневая часть libC написана на C.
Можно, например, добавить функцию для форматированного ввода. И на её основе сделать
остальные функции форматированного ввода. Ну так как насчёт присоединения ?

А где можно посмотреть libCk? Я обственно говоря в printf не нуждаюсь, а вот все что в libc лежит в подпапке minuet нужно.

Mon Jan 14, 2008 9:52 pm

[offtop]
Serge, SHREDER
верю что ядро убить можно, но можно ли конкретный пример???
[/offtop]

Kolibri Foundation Classes (KFC)

Who is online