Freeman, судя по вопросу: какую библиотеку использовать в fasm для графики через BIOS... есть некоторые сомнения. Очевидно, что подобных библиотек не существует в более-менее рабочем состоянии, да и древность это уже никому не нужная.
В то время был грубо один стандарт VESA. Менуэт писался именно для изучения крутых и современных тогда вещей типа VBE для отрисовки графики. Сейчас нет смысла это изучать, 25 лет уж прошло, много чего нового появилось.
Совместимость то осталась, но для чего нужен VBE в 2024 году? Практически любой ПК сейчас крутится на UEFI, где почти всегда реализован GOP протокол для таких случаев. А уж сколько простеньких ноутбуков существует, где вообще Legacy режим отключен программно. На крайняк можно через UGA порисовать, но я не видел в природе устройств, которые хотя бы примитивно не реализуют GOP. Только если китайские платы какие-то нонеймовые, ну и Маки, у которых всегда своя атмосфера в этом плане была.
Ну и для рисования гуев через GOP максимум есть адекватные либы у вендоров типа AMI, но я сомневаюсь, что они их публикуют, да ещё и под fasm.
Там вроде LVGL портировать начали под UEFI в начале года, не знаю чем закончилось в итоге.
При огромном желании и конских знаниях, можно запилить бекенд эмбеддера для flutter, но это совсем упороться надо.
Так что, только учить, только ковыряться в спецификациях и мануалах даже чтобы переиспользовать чью-то либу.
Нужно изучать реврес-инжиниринг. Если нужно встроить динамическую библиотеку, изучай хуки функций, методы инжекта, отладчик, дизассемблеры, язык, на котором будешь писать эту библиотеку, структуру памяти в программе.
niten_d0raku, именно это и значит. std::wstring не имеет никакого отношения к UTF-8.
C++ не поддерживает как таковой UTF-8. Если текст статический, то можно через std::u8string объявить. А если строки динамические, то надо подключать библиотеку для работы с Юникодом. Раз уж ты уже используешь boost, то возьми Boost.Locale
Поддержу коммент про вейленд. Абсолютно все реализации его композитора в настоящее время работают чуть менее, чем полностью отвратительно. У меня артефакты на трёх девайсах с тремя разными GPU-вендорами были как что-то само собой разумеющееся. Мертворождённый протокол, к сожалению.
какой хоть язык?
Языки разные бывают, где-то чтобы автодополнить, нужно скомпилировать заново весь файл/модуль, а где-то из бора достаточно ветку вытащить.
pfg21, эта скорость же не с потолка берётся, как раз таки от изменения реализации внутренних механизмов.
Если ничего не меняется, почему тогда появляются уязвимости типа Meltdown, Spectre, Foreshadow, ZombieLoad, и т.п., когда изменяется внутренняя кухня модели исполнения в процессоре, её исследуют и находят косяки? Если бы ничего не менялось, уязвимости бы не появлялись.
Явно это всё не видно для пользователя, но это не значит что ничего не происходит.
Если раньше в процессоре без спекулятивного исполнения, без бранчпредиктора и без переупорядочивания команд, происходила операция, которая требует результата предыдущей команды или результата чтения из памяти, процессор банально останавливался и стоял ждал, пока придёт ответ, не выполняя никакой полезной работы. Современный процессор же начнёт спокойно выполнять код дальше, который не завязан на результат предыдущей операции.
Да, это не "видно глазом" из-за низких задержек для человеческого восприятия, но ждущий чего-то процессор, и не останавливающийся и делающий другую полезную работу -- это разве не кардинальное изменение процесса исполнения кода?
Если вы пишете hello, world, то разницы не увидите совершенно, за вас уже сделали колоссальную работу разработчики компилятора, ОС, драйверов. А если это какой-то неблокирующий IPC, который утилизирует знания о модели памяти, синхронизации кешей, работы блока переупорядочивания команд, NUMA не дай бог, то будет очень больно не учитывать все современные особенности модели исполнения.
Посмотрите какой-нибудь низкоуровневый проект, типа DPDK. Где для предотвращения cache false sharing в примитивах синхронизации выравнивали данные по границе одной кеш-линии (64 байта), а потом появился Sandy Bridge со своим парным префетчером (две линии по 64 байта за раз), и код сломался пока не пофиксили 128-байтным выравниванием. Архитектура та же, всё то же самое, никаких новых расширений не задействовали, а код сломался в новом процессоре. Почему же?
С кривыми руками можно и хер сломать.
Если 5 лет не было проблем, то и дальше не будет.
Никогда не понимал этих ломателей арча. Что там можно ломать то, если ты сам всё своими руками ставил и конфигурировал...
Если нет привычки читать форумы убунты и копипастить рандомные команды от анонов в шелл, то всё будет норм.
ПС Использую Арч больше 12 лет на нескольких десятках различных устройств, включая x86-64, ARM, серверы, miniPC, ноутбуки. Никогда ничего не ломалось за это время. Может что-то не так делаю. Не думаю, что с манджаро будет как-то иначе.
либо собирай руками через вызов
clang -std=c++23