libGUI
-
[offtop]разве из под венды нельзя grub поставить?? 0__о[/offtop]
s1n
Не беспокойся. Сегодня ночью я переустановил windows, а при помощи LiveCD Ubuntu я восстановил из консоли grub в linux.
Не беспокойся. Сегодня ночью я переустановил windows, а при помощи LiveCD Ubuntu я восстановил из консоли grub в linux.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
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, используемых в примерах. Раньше недостатки были не видны, но внедрение менеджера памяти их выявило.
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 316 times
-
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Добавил SDK для FASM-а и несколько примеров на assembler-е(смотреть на SVN).
Скомпилированные примеры на C и Assembler находятся в архиве ниже.
Скомпилированные примеры на C и Assembler находятся в архиве ниже.
- Attachments
-
-
examples.7z (28.04 KiB)Downloaded 328 times
-
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
andrew_programmer
1) Поддержка ASM это хорошо, и сразу видно что Cи все равно отъедает 20-30% по размеру занимаемой памяти (с учетом того что сама библиотека на Си написана). В бинарниках еще больше отъедает. И это с учетом того что писал человек разбирающийся в программировании.
2) Обнаружил зверский баг - если запустить 2 примера и поместить их друг над другом (чтобы окна хоть немного пересекались) они начинают бесконечно перерисовывать свои окна. Впрочем баг похоже не редкий - я в zSea тоже обнаружил недели 2 назад, пока не разбирался в чем причина.
1) Поддержка ASM это хорошо, и сразу видно что Cи все равно отъедает 20-30% по размеру занимаемой памяти (с учетом того что сама библиотека на Си написана). В бинарниках еще больше отъедает. И это с учетом того что писал человек разбирающийся в программировании.
2) Обнаружил зверский баг - если запустить 2 примера и поместить их друг над другом (чтобы окна хоть немного пересекались) они начинают бесконечно перерисовывать свои окна. Впрочем баг похоже не редкий - я в zSea тоже обнаружил недели 2 назад, пока не разбирался в чем причина.
Mario
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 на ассемблер(работа с памятью, рассчёт градиентов и всё, что критично по скорости).
Я так и думал, что все заметят разницу в размере. Причин столь значительной разницы в размере бинарников две.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 на ассемблер(работа с памятью, рассчёт градиентов и всё, что критично по скорости).
Этот баг я тоже заметил. Он связан частично с особенностью реализации оконного менеджера в Kolibri. Перерисовка одного окна вызывает перерисовку другого, другое в свою очередь предыдущего. В результате самоподдержка перерисовки перекрывающихся окон. И связана эта самоподдержка со способом обработки сообщений о перерисовке от системы. Я ещё не разбирался где там проблема "зарыта".2) Обнаружил зверский баг - если запустить 2 примера и поместить их друг над другом (чтобы окна хоть немного пересекались) они начинают бесконечно перерисовывать свои окна. Впрочем баг похоже не редкий - я в zSea тоже обнаружил недели 2 назад, пока не разбирался в чем причина.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
con_printf() из console.obj?andrew_programmer wrote:1)Для вывода текста в консоль используется функция форматированного вывода printf() из стандартной библиотеки libC(небольшая часть этой библиотеки написана мной и используется в примерах). Функция printf() увеличивает размер бинарника на 7kb.
strip --keep-symbol=EXPORTS или ..._EXPORTS?andrew_programmer wrote:Для того, чтобы убрать эти лишние символы, нужно использовать утилиту strip. После её применения размер объектного файла libGUI.obj уменьшается на данный момент на 17kb. Только вот и ключевое слово EXPORTS тоже исчезает(потому что таблица экспорта представляется как обычный массив с именем EXPORTS). Поэтому библиотека перестаёт грузиться. Пока я не придумал, как обойти это. Нужно вникать в устройство формата объектного файла и писать свою версию утилиты strip, или пытаться править её код.
Ушёл к умным, знающим и культурным людям.
Нет. Если бы мне была нужна только функция printf(), то я реализовал бы только конвертирование вещественных чисел в строку, а весь остальной форматированный вывод возложил на con_printf(). Но мне нужен форматированный вывод и в строки, и в файл, поэтому я реализовал функцию format_printf(), которая производит форматированный вывод в строку, и используется в других функциях форматированного вывода. А уж из строку я могу выводить куда мне нужно.con_printf() из console.obj?
Вся проблема в том, что для strip метка EXPORTS является всего лишь символом.Хотя команда strip --strip-all --keep-symbol=_EXPORTS libGUI.obj оставляет EXPORTS в файле, но саму таблицу экспорта переносит в другое место. Метка EXPORTS находится за несколько байтов до конца файла. В общем придётся "шаманить" по другому.strip --keep-symbol=EXPORTS или ..._EXPORTS?
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
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 меньше.
Большое спасибо за совет. Я что-то вообще забыл, что названия секций ".text", ".data" и т.д. тоже удаляются вместе с остальными символами. Теперь библиотека работает. Неупакованная версия стала на 9kb меньше.
- Attachments
-
-
libGUI.obj (20.21 KiB)
- пересобранная библиотека без лишних символов в бинарном файле
Downloaded 323 times
-
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
У меня проблема была в 67 функции, описал проблему в теме Bugzilla и один из методов решения.andrew_programmer wrote:Этот баг я тоже заметил. Он связан частично с особенностью реализации оконного менеджера в Kolibri. Перерисовка одного окна вызывает перерисовку другого, другое в свою очередь предыдущего. В результате самоподдержка перерисовки перекрывающихся окон. И связана эта самоподдержка со способом обработки сообщений о перерисовке от системы. Я ещё не разбирался где там проблема "зарыта".
Посмотри может и твоя проблема подобна.
У меня тоже была проблема с 67 функцией. Я переделал код. Теперь бага нет.
Когда в коде будет достаточное количество изменений - залью на SVN.
Когда в коде будет достаточное количество изменений - залью на SVN.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Не нашёл файла libGUI.inc на svn. А без него разработка на асме не очень возможна.
PS: исправил на svn meneger на manager.
PS: исправил на svn meneger на manager.
Текущий путь: /programs/develop/sdk/trunk/libGUI/FASM/LIBGUI.INC
http://kolibrios.org/?p=SVN&kind=file&l ... LIBGUI.INC
http://kolibrios.org/?p=SVN&kind=file&l ... LIBGUI.INC
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Теперь ещё два вопроса:
1. Ведётся ли разработка лэйаутов в libGUI? (просто если нет, я ей наверное займусь)
2. Слово finition означает finishing?
И кроме того, ширина - это всё-таки width, а не wigth.
PS: в примере main есть глюк - при перемещении области со скроллами остаются следы на предыдущем месте, которые исчезают при полной перерисовке)
1. Ведётся ли разработка лэйаутов в libGUI? (просто если нет, я ей наверное займусь)
2. Слово finition означает finishing?
И кроме того, ширина - это всё-таки width, а не wigth.
PS: в примере main есть глюк - при перемещении области со скроллами остаются следы на предыдущем месте, которые исчезают при полной перерисовке)
Who is online
Users browsing this forum: No registered users and 36 guests