Board.KolibriOS.org

[offtop]разве из под венды нельзя grub поставить?? 0__о[/offtop]

s1n

Не беспокойся. Сегодня ночью я переустановил windows, а при помощи LiveCD Ubuntu я восстановил из консоли grub в linux.

Обновление библиотеки.

1)Добавлен менеджер памяти. Используется аллокатор памяти от Дага Ли(Doug Lea), который уже используется в некоторых проектах для KolibriOS. Я только адаптировал его для библиотеки libGUI. Минимальный размер памяти, которую выделяет аллокатор для библиотеки - 16 байт. Если размер запрашиваемой памяти больше 32-х килобайт, то память выделяется напрямую из системы.
2)Добавлен SDK для MSVC++(смотреть на SVN). Тестировалось на MSVC++ 2008. Сразу скажу, что если при написании программы вы выдилите мало памяти под стек, то программа будет глючить или вообще вылетать. Минимальный размер стека для работы программы(компиляция MSVC) 4Kb, а для нормальной работы лучше не менее 8-16Kb(зависит от типа и числа используемых контролов).
3)Это скорее важно для меня, чем для кого-то другого. Я сделал возможность вывода лога в консоль при работе библиотеки в режиме отладки.

P.S.
С новой библиотекой старые примеры будут работать немного некорректно(отображение текста).Дело не в библиотеке, а в самих примерах. Это связано с недоработкой функций libC, используемых в примерах. Раньше недостатки были не видны, но внедрение менеджера памяти их выявило.

Добавил SDK для FASM-а и несколько примеров на assembler-е(смотреть на SVN).
Скомпилированные примеры на C и Assembler находятся в архиве ниже.

andrew_programmer
1) Поддержка ASM это хорошо, и сразу видно что Cи все равно отъедает 20-30% по размеру занимаемой памяти (с учетом того что сама библиотека на Си написана). В бинарниках еще больше отъедает. И это с учетом того что писал человек разбирающийся в программировании.

2) Обнаружил зверский баг - если запустить 2 примера и поместить их друг над другом (чтобы окна хоть немного пересекались) они начинают бесконечно перерисовывать свои окна. Впрочем баг похоже не редкий - я в zSea тоже обнаружил недели 2 назад, пока не разбирался в чем причина.

Mario

1) Поддержка ASM это хорошо, и сразу видно что Cи все равно отъедает 20-30% по размеру занимаемой памяти (с учетом того что сама библиотека на Си написана). В бинарниках еще больше отъедает. И это с учетом того что писал человек разбирающийся в программировании.

Я так и думал, что все заметят разницу в размере. Причин столь значительной разницы в размере бинарников две.
1)Для вывода текста в консоль используется функция форматированного вывода printf() из стандартной библиотеки libC(небольшая часть этой библиотеки написана мной и используется в примерах). Функция printf() увеличивает размер бинарника на 7kb. Эта фукция рассчитана на форматированный вывод: отдельных символов,текста, целых чисел, вещественных чисел, строк, указателей. Также к размеру бинарника надо прибавить код для загрузки и линковки библиотеки console.
2)При компиляции программ компиляторами C(я использовал gcc) к заголовку программы добавляется код для разбора аргументов, передаваемых программе. Хотя сам код написан на ассемблере, но с учётом резервируемых для этого буферов, он расходует примерно 500-700 байт(зависит от того в каком формате объектный файл заголовка).

В ассемблерных примерах я не писал функции форматированного вывода. Лишь только для ProgressBar-а я использовал преобразование целого числа в строку(поэтому этот пример больше всех по размеру). Также в ассемблерных примерах нет вывода в консоль и нет кода разбирающего аргументы передаваемые программе.

Сейчас библиотека компилируется как объектный файл формата COFF. Только компилятор GCC добавляет в код служебную информацию(таблицу имён функций и т.д.). Для того, чтобы убрать эти лишние символы, нужно использовать утилиту strip. После её применения размер объектного файла libGUI.obj уменьшается на данный момент на 17kb. Только вот и ключевое слово EXPORTS тоже исчезает(потому что таблица экспорта представляется как обычный массив с именем EXPORTS). Поэтому библиотека перестаёт грузиться. Пока я не придумал, как обойти это. Нужно вникать в устройство формата объектного файла и писать свою версию утилиты strip, или пытаться править её код. Подумываю ещё сделать часть обёрток системных функций для MSVC++. Тогда библиотеку можно будет скомпилировать MSVC в ассемблер MASM, а потом скомпилировать код в dll формата COFF. В этом случае таблицы имён и прочего мусора не будет. Только MSVC вроде генерирует ассемблерный код без выравнивания, а вот gcc выравнивает. В общем я над этим поэкспериментирую.
Также я планирую переписать некоторую часть libGUI на ассемблер(работа с памятью, рассчёт градиентов и всё, что критично по скорости).

2) Обнаружил зверский баг - если запустить 2 примера и поместить их друг над другом (чтобы окна хоть немного пересекались) они начинают бесконечно перерисовывать свои окна. Впрочем баг похоже не редкий - я в zSea тоже обнаружил недели 2 назад, пока не разбирался в чем причина.

Этот баг я тоже заметил. Он связан частично с особенностью реализации оконного менеджера в Kolibri. Перерисовка одного окна вызывает перерисовку другого, другое в свою очередь предыдущего. В результате самоподдержка перерисовки перекрывающихся окон. И связана эта самоподдержка со способом обработки сообщений о перерисовке от системы. Я ещё не разбирался где там проблема "зарыта".

andrew_programmer wrote:1)Для вывода текста в консоль используется функция форматированного вывода printf() из стандартной библиотеки libC(небольшая часть этой библиотеки написана мной и используется в примерах). Функция printf() увеличивает размер бинарника на 7kb.

con_printf() из console.obj?

andrew_programmer wrote:Для того, чтобы убрать эти лишние символы, нужно использовать утилиту strip. После её применения размер объектного файла libGUI.obj уменьшается на данный момент на 17kb. Только вот и ключевое слово EXPORTS тоже исчезает(потому что таблица экспорта представляется как обычный массив с именем EXPORTS). Поэтому библиотека перестаёт грузиться. Пока я не придумал, как обойти это. Нужно вникать в устройство формата объектного файла и писать свою версию утилиты strip, или пытаться править её код.

strip --keep-symbol=EXPORTS или ..._EXPORTS?

con_printf() из console.obj?

Нет. Если бы мне была нужна только функция printf(), то я реализовал бы только конвертирование вещественных чисел в строку, а весь остальной форматированный вывод возложил на con_printf(). Но мне нужен форматированный вывод и в строки, и в файл, поэтому я реализовал функцию format_printf(), которая производит форматированный вывод в строку, и используется в других функциях форматированного вывода. А уж из строку я могу выводить куда мне нужно.

strip --keep-symbol=EXPORTS или ..._EXPORTS?

Вся проблема в том, что для strip метка EXPORTS является всего лишь символом.Хотя команда strip --strip-all --keep-symbol=_EXPORTS libGUI.obj оставляет EXPORTS в файле, но саму таблицу экспорта переносит в другое место. Метка EXPORTS находится за несколько байтов до конца файла. В общем придётся "шаманить" по другому.

strip, оказавшийся у меня в PATH (от какой-то не слишком новой версии MinGW), выдал нормальный результат по команде strip -K EXPORTS -K .text -K .data -K .rdata -K .bss <filename>. Другой вопрос, что unresolved externals при этом превратились в обращение к [0], но они и в нестрипнутой версии в это превращаются при загрузке библиотеки.

diamond

Большое спасибо за совет. Я что-то вообще забыл, что названия секций ".text", ".data" и т.д. тоже удаляются вместе с остальными символами. Теперь библиотека работает. Неупакованная версия стала на 9kb меньше.

andrew_programmer wrote:Этот баг я тоже заметил. Он связан частично с особенностью реализации оконного менеджера в Kolibri. Перерисовка одного окна вызывает перерисовку другого, другое в свою очередь предыдущего. В результате самоподдержка перерисовки перекрывающихся окон. И связана эта самоподдержка со способом обработки сообщений о перерисовке от системы. Я ещё не разбирался где там проблема "зарыта".

У меня проблема была в 67 функции, описал проблему в теме Bugzilla и один из методов решения.
Посмотри может и твоя проблема подобна.

У меня тоже была проблема с 67 функцией. Я переделал код. Теперь бага нет.
Когда в коде будет достаточное количество изменений - залью на SVN.

Не нашёл файла libGUI.inc на svn. А без него разработка на асме не очень возможна.

PS: исправил на svn meneger на manager.

Текущий путь: /programs/develop/sdk/trunk/libGUI/FASM/LIBGUI.INC

http://kolibrios.org/?p=SVN&kind=file&l ... LIBGUI.INC

Теперь ещё два вопроса:
1. Ведётся ли разработка лэйаутов в libGUI? (просто если нет, я ей наверное займусь)
2. Слово finition означает finishing?
И кроме того, ширина - это всё-таки width, а не wigth.

PS: в примере main есть глюк - при перемещении области со скроллами остаются следы на предыдущем месте, которые исчезают при полной перерисовке)