Board.KolibriOS.org

А в чём магия? Что мой код всего лишь на строчку короче? Ну да, компиляторы неплохо оптимизируют код... нормальный код, без ООП.

Там вон viewtopic.php?f=9&t=2122&p=66983#p66982 перестало работать.
Предположительно из-за этого изменения http://websvn.kolibrios.org/filedetails ... 75#line-28

Я ошибся - код одинаковый, по 11 команд.
И у компилятора тоже есть неочевидная для меня

lea   eax, DWORD PTR [eax+eax*2]

Так что счет равный.

Влил ToolTip и пример использования в библиотеку.
В исходниках - полезная для будущих компонент фича для использования структур в асме.

Siemargl, молодец, конечно, что старался.
Но это всё-таки не совсем tooltip получился.
Tooltip это вот на скриншоте viewtopic.php?f=24&t=1220&start=315#p66855 А у тебя просто квадратик рисуется.
Ну ничего, в принципе, как пример это можно оставить.
Как только появится время, постараюсь добавить нормальный ToolTip.
Америку открыл, да?

Насчёт editbox-a.
Думаю, лучше было взять дополнительные байты из "внутренних" переменных, таких как, например, ed_shift_pos, ed_shift_pos_old, cl_curs_x, cl_curs_y. Потому как реально там не нужно по 4 байта. Сами эти переменные можно сдвинуть в памяти, они же внутренние, их никто кроме самого editbox-а не использует. Так что, это ещё и экономия памяти.

Дизайнер есть, насоветует - рисовку улучшим.
Судя по коду бокс_либ и твоим проблемам с байтами - таки открыл )

Siemargl, посчитай ещё раз.
Мой код (без "магии"):

        mov     ecx,ed_text_color
        mov     ebx,ecx
        shr     ecx,28
        shr     ebx,24
        and     ebx,7
        inc     ebx
        mov     eax,6
        jecxz   @f
        mov     al, 8
@@:
        mul     bl

Впрочем, мерятся с компилятором всё равно что играть с ботами...

Так нечестно - ты сейчас выкинул and c маской и у тебя jecx отработает при любых старших битах, например asciiz.

В целом я и не спорю, что ручная оптимизация лучше, да и компилятор иногда такое нарисует (особо относится к gcc),
а поинт был в том, что если уж писать асм руками, то делать это понятным для человека.

Раз пошла такая пьянка, вот ресурс, позволяющий оценить, что напишет бот-компилятор для примера, с выбором ботов. А потом уже можно и напильником.
AFAIK, компиляторы пока сами не умеют хорошо использовать SSE.

and dword ed_text_color,17FFFFFFh - это общая валидация для всего editbox, она нужна в обоих случаях.

А ещё, компиляторы не умеют использовать rep movs, lods, stos...

Хорошо, я сам это сделаю тогда viewtopic.php?f=24&t=1220&p=67000#p66992
Никто ведь не против сохранения обратной совместимости?
Pathoswithin, подумай насчёт высоты шрифта, там тоже не надо 4 байта. Может ещё для чего-нибудь сгодится, для флагов там каких-нибудь.

В данном случае нет. Компилятор тестирует конкретный бит.

Я против - ты поломаешь C-Layer, а у gcc какие то болячки с отключением выравнивания в структурах. Еще потом с байтами трахаться (со словами не придется).
Лучше исправить поломавшиеся программы на нормальный код с родными бокс_либовскими макросами

Siemargl ух кокой толстый тролинг
Кому не нравится обратная совместимость, могут смело форкать проект.

Проверил. Экономия 12 байт в структуре стоит дополнительных 32 байта в коде из-за префикса размера у не 32-битных команд в 32-битном режиме.

Pathoswithin, ты собираешься исправлять или как?
А ты сейчас серьёзно насчёт экономии памяти?
Тогда я тебе тоже сейчас серьёзно и отвечу.
Для трёх EditBox-ов экономия составит уже 12 * 3 = 36 байт, в то время как в коде BoxLib это будут по-прежнему те же самые 32 байта.
Отвечу тебе твоими же словами. Тебе нужно всего-тоТо есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasm

Тут проблема в том, что поломались уже работающие программы.
То есть, если после обновления сборки у пользователя перестаёт что-то работать, то ему, вероятно, придётся пойти на форум, потратить время, чтобы понять, в чём проблема, обновить поломавшуюся программу(причём сначала надо будет дождаться её исправления).

Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.

Вообще, хотелось бы по этому поводу комментариев администрации. Я считаю, что такое положение дел это ну никак нормальным назвать нельзя. А представьте, что проблемы с совместимостью возникли бы у гораздо большего количества разработчиков, например 20-30?

Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.

Еще и скорость обращения к полусловам наверное тоже ниже, хотя для интерфейсной части это вряд ли критично.

>То есть, следуя твоей логике, сами структуры из BoxLib можно менять хоть каждый день, хоть по нескольку раз в день. Главное макросы использовать. Причём непременно для fasm
Именно. Автосборка системы решает эту проблему, а fasm - стандартный для системы транслятор. Новая версия системных библиотек тянет за собой требование к тестированию и/или обновлению юзер-программ, это всегда и везде так.

>Я пока обнаружил проблемы в RunOD(сейчас исправлено), GenFiles, fNav, вероятно, что также WebView и Eolite.
В С-- структура уже исправлена (т.е.WebView и Eolite вычеркиваем), остальные можешь проверить и сказать, поломались или нет )

>Если говорить обо мне, то это для меня не проблема, чтобы просто взять и вкомпилировать код EitBox-а "как есть" в само приложение. Это уж точно избавило бы от возможных проблем с совместимостью.
Такая идеология в static linux http://sta.li