libGUI

Discussing libraries simplifying applications development
  • s1n

    Не беспокойся. Сегодня ночью я переустановил windows, а при помощи LiveCD Ubuntu я восстановил из консоли grub в linux.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Обновление библиотеки.

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

    P.S.
    С новой библиотекой старые примеры будут работать немного некорректно(отображение текста).Дело не в библиотеке, а в самих примерах. Это связано с недоработкой функций libC, используемых в примерах. Раньше недостатки были не видны, но внедрение менеджера памяти их выявило.
    Attachments
    libGUI.obj (21.76 KiB)
    Downloaded 312 times
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Добавил SDK для FASM-а и несколько примеров на assembler-е(смотреть на SVN).
    Скомпилированные примеры на C и Assembler находятся в архиве ниже.
    Attachments
    examples.7z (28.04 KiB)
    Downloaded 324 times
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • andrew_programmer
    1) Поддержка ASM это хорошо, и сразу видно что Cи все равно отъедает 20-30% по размеру занимаемой памяти (с учетом того что сама библиотека на Си написана). В бинарниках еще больше отъедает. И это с учетом того что писал человек разбирающийся в программировании. :mrgreen:

    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. Перерисовка одного окна вызывает перерисовку другого, другое в свою очередь предыдущего. В результате самоподдержка перерисовки перекрывающихся окон. И связана эта самоподдержка со способом обработки сообщений о перерисовке от системы. Я ещё не разбирался где там проблема "зарыта".
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • 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 находится за несколько байтов до конца файла. В общем придётся "шаманить" по другому.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • strip, оказавшийся у меня в PATH (от какой-то не слишком новой версии MinGW), выдал нормальный результат по команде strip -K EXPORTS -K .text -K .data -K .rdata -K .bss <filename>. Другой вопрос, что unresolved externals при этом превратились в обращение к [0], но они и в нестрипнутой версии в это превращаются при загрузке библиотеки.
    Ушёл к умным, знающим и культурным людям.
  • diamond

    Большое спасибо за совет. Я что-то вообще забыл, что названия секций ".text", ".data" и т.д. тоже удаляются вместе с остальными символами. Теперь библиотека работает. Неупакованная версия стала на 9kb меньше.
    Attachments
    libGUI.obj (20.21 KiB)
    пересобранная библиотека без лишних символов в бинарном файле
    Downloaded 318 times
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • andrew_programmer wrote:Этот баг я тоже заметил. Он связан частично с особенностью реализации оконного менеджера в Kolibri. Перерисовка одного окна вызывает перерисовку другого, другое в свою очередь предыдущего. В результате самоподдержка перерисовки перекрывающихся окон. И связана эта самоподдержка со способом обработки сообщений о перерисовке от системы. Я ещё не разбирался где там проблема "зарыта".
    У меня проблема была в 67 функции, описал проблему в теме Bugzilla и один из методов решения.
    Посмотри может и твоя проблема подобна.
  • У меня тоже была проблема с 67 функцией. Я переделал код. Теперь бага нет.
    Когда в коде будет достаточное количество изменений - залью на SVN.
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Не нашёл файла 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
    KolibriOS-перспективная ос!
    Kolibri is best operation system in the world!
  • Теперь ещё два вопроса:
    1. Ведётся ли разработка лэйаутов в libGUI? (просто если нет, я ей наверное займусь)
    2. Слово finition означает finishing?
    И кроме того, ширина - это всё-таки width, а не wigth.

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

    Users browsing this forum: No registered users and 4 guests