Пишу фреймворк LDL, аналог SDL но на С++ и с поддержкой старых систем

Амбиции – это прекрасно.

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

Ну так сделайте топик про свою разработку, выложите исходники в свободный доступ. Чтобы можно было оценить «удобно» – это для вас лично или вообще.

Мой топик пока - продакшен.

Извиняюсь, но ни в одном из моих постов маниловщины нет.

На мой взгляд нет смысла собирать какой-либо код старыми компиляторами на старых системах. Намного удобнее и правильнее собирать современным компилятором на современной системе для старой системы. По сути это кросс компиляция. Но создание кросс-тулчейнов это отдельная большая задача. Хотя тоже интересная.

Гм, а я вот поддерживаю ТС.
Для него это радость, а это весьма неплохо.
Позитив помогает очень в разработке.

Да это системы с 20+ лет.

в системах 20-летней давности уже был С++03 и даже зайчатки с++11

в системах 20-летней давности уже был С++03 и даже зайчатки с++11

20 лет назад это 2003 год. Я взял С++ 98 как золотую середину. Много компиляторов тех лет поддерживали именно этот стандарт.

На мой взгляд нет смысла собирать какой-либо код старыми компиляторами на старых системах. Намного удобнее и правильнее собирать современным компилятором на современной системе для старой системы. По сути это кросс компиляция. Но создание кросс-тулчейнов это отдельная большая задача. Хотя тоже интересная.

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

Аналогично (гонки за стандартами нет).
«Кто выще бье, тот краще грае» не мой путь.

Исходники можно скомпилировать любым компилятором.

Более того (у меня форк SDL на C++ ) std, STL, template, class, string, ... не использую.
Своё API.
Собственно так многие разработчики поступают.
Такой путь много упрощает разработку кроссплатформенного кода.

Конечно поддерживаю вашу разработку и в многом вы правы.
Поэтому ваш путь разработки позволит создавать программы, которые смогут работать в разных ОС (и более ранних версий).

Мне ближе «Где просто, там ангелов со ста. Где мудрено, там ни одного.».

Для теста фреймворка собрал разрабатываемый мной двиг для Arcanum.

Работает на Lubuntu под WM

Скрин

Более того (у меня форк SDL на C++ ) std, STL, template, class, string, … не использую. Своё API. Собственно так многие разработчики поступают. Такой путь много упрощает разработку кроссплатформенного кода.

Я все же менее аскетичный код пишу:) STL и шаблоны юзаю. Просто не выхожу за стандарт С++ 98.

Конечно поддерживаю вашу разработку и в многом вы правы. Поэтому ваш путь разработки позволит создавать программы, которые смогут работать в разных ОС (и более ранних версий). Мне ближе «Где просто, там ангелов со ста. Где мудрено, там ни одного.».

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

Минимум хаков. Все скрыто за абстракциями.

У меня для это используется API, которое использует метаданные.
Если кратко, то метаданные содержат данные об объекте.
API на основании метаданных позволяет создать и работать с объектом, который находится в памяти или файле (это не а-ля сериализация).
Супер удобно!

Вам близка тематика разработка игр и вам известно как много форматов используется.
Так вот API позволяет создать объект любого формата и сложности.
Да ещё в «довесок» предоставляет унифицированные функции для работы с объектами.

Это не фантазии, а уже разработанное (не на 100%) API.

Поэтому ныне разработка GUI для меня не fun, а необходимость.

Это и ответ на ваше суждение «Я все же менее аскетичный код пишу:) STL и шаблоны юзаю. Просто не выхожу за стандарт С++ 98.»

Да и в 2003 году все актуальные на тот момент компиляторы так или иначе поддерживали С++03 хотя бы частично.

Кроме того, вы заявляете о поддержке win95, но sdl2 не поддерживает win95, поддержка винды у него начиная с ХP, это ядро NT5.0, в отличие от win95-98 у которых вообще другое ядро.

Кстати, Opengl1.2 на который вы рассчитываете, заведётся под win95 тоже не полностью.

Да и в 2003 году все актуальные на тот момент компиляторы так или иначе поддерживали С++03 хотя бы частично.

Наколько мне известно, С++03 не слишком отличается, в основном это стандарт исправляющий ошибки и неточности предыдущего стандарта.

Кроме того, вы заявляете о поддержке win95, но sdl2 не поддерживает win95, поддержка винды у него начиная с ХP, это ядро NT5.0, в отличие от win95-98 у которых вообще другое ядро.

Так я разрабатываю фреймворк LDL по мотивам SDL2. Поэтому он поддерживает Windows 95. Волен запиливать под любое старьё:)

Кстати, Opengl1.2 на который вы рассчитываете, заведётся под win95 тоже не полностью. Я пока так и не смог его завести под Windows 95(только soft render).

Так я разрабатываю фреймворк LDL по мотивам SDL2. Поэтому он поддерживает Windows 95. Волен запиливать под любое старьё:)

Попытки использования LDL для Windows 95 были?
Если у вас всё получится, то будем у вас перенимать опыт.

Попытки использования LDL для Windows 95 были?

Только запуск примеров под 86box c Windows 95 (только в софт рендере) Нативно работают под ПК с Windows 98 (OpenGL 1.1 рендер)

Если у вас всё получится, то будем у вас перенимать опыт. Я только за.

Весь код написан на С++ 98, для поддержки большего числа компиляторов и систем. Но разработчик, может использоать любой стандарт языка, хоть С++ 23. Ограничение есть лишь у меня как у разработчика фреймворка.

И как в C++98 работает move-семантика? Приходится руками писать методы перемещения и руками их вызывать?

Как живется без constexpr? Константы объявлены через #define ?

И как в C++98 работает move-семантика? Приходится руками писать методы перемещения и руками их вызывать?

Семантика перемещения не работает. Её же нет.

Как живется без constexpr? Константы объявлены через #define ?

Вполне нормально. Использую enum и const. #define использую только для С API и условий для сборки.

Я понимаю, что теряю большое число современных фич и удобств. Но таков путь. Важна совместимость и портируемость кода.

Проект собирается и на lubuntu 16.04 и буду дальше экспериментировать с понижением версии дистра.

Сейчас осталось, реализовать отсутствующий функционал для Linux и запилить поддержку звука.

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

Почитал статью на хабре, чтобы кинуться какашкой, а в итоге зашло, согласен с тобой :)

Почитал статью на хабре, чтобы кинуться какашкой, а в итоге зашло, согласен с тобой :)

Рад, что нашел соратника.

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

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

Не окажется, потому что однопоточная производительность всё же росла.

Игроделы многопоточку хоть как-то осиливать начали лет семь назад, до тех пор однопоток и изредка физика на другом ядре.

А что мешает писать на современном C++ с сохранением поддержки старых ОС? Или ты хочешь чтоб прям в Windows 95 компилировался код? Скомпилировать под GNU/Linux в MinGW и перетащить в старую винду проще, имхо.

А что мешает писать на современном C++ с сохранением поддержки старых ОС? Или ты хочешь чтоб прям в Windows 95 компилировался код? Скомпилировать под GNU/Linux в MinGW и перетащить в старую винду проще, имхо.

Да компиляция нативно в ОС. Под Windows 95 и выше я собираю на windows 10 двумя компиляторами MinGW бородатой версии и Visual C++ 6.0

Под Linux уже нативно компилятором идущий в поставке дистра. Сейчас тестирую сборку фреймворка на debian 4. Скачал образ dvd включающий необходимый софт.

Не использую современный С++ для будущей поддержки очень старого железа, какие нибудь sun, sparc и т.д Главное, что бы имелся компилятор С++ с поддержкой namespace и шаблонов.

Здесь не всё так просто.
Например тот же CString (многое в MFC) в не будет правильно функционировать в более старых версиях ОС.
Да и для каждой версии Visual Studio имеется своя redistribution, ...

О многом и не сказал.

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

Да, нужно использовать старые компиляторы и дело вовсе не в возможностях компилятора.

И поэтому-то в т.ч. у меня своё API, которое будет правильно функционировать в любой ОС.

Да, нужно использовать старые компиляторы и дело вовсе не в возможностях компилятора.

Здесь не всё так просто.

Большой плюс в том, что так же я не использую зависимых компиляторных фич. И постоянно компилирую новыми компиляторами, что быть уверенным, что на любом компиляторе все собирается и рабюотает.

К примеру разрабатываю фреймворк под Windows 10 (64-бит) на MSVC 2022, под Lubuntu 22.04.2 LTS на VSCode.

Здесь не всё так просто. Например тот же CString (многое в MFC) в не будет правильно функционировать в более старых версиях ОС. Да и для каждой версии Visual Studio имеется своя redistribution, О многом и не сказал. Вообщем не мало подводных камней.

mfc я не юзаю в проекте, только winapi и в зависимсоти от разрядности винды, обмазываю #ifdef’ами

Sorry за повтор суждения о том, что у своего API много плюсов.

Так многие разработчики поступают.

«Нельзя объять, необъятное».
Надеюсь вы в постах поделитесь опытом.

--------------------------------------------
Не зря Microsoft так любит COM (и ActiveX использует очень часто).
Кстати многие связывают ActiveX с диалоговыми формами.
Это абсолютно не верно.
Можно просто API ActiveX использовать как хороший биндинг для использования любого API на C++.
Но COM конечно не годится для обработки больших объёмов данных.

«Нельзя объять, необъятное». Надеюсь вы в постах поделитесь опытом. Вы лучше спросите, а я отвечу.

Я позже хочу на Хабре написать обзорную техническую статью к релизу о фреймворке. Но я бы не стал утверждать, что я сделал, что то сложное. Код довольно чистый.

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

Сложного и специфического в проекте нет. Все довольно просто написано.

Думаю, что основную магию делают компиляторы и стабильное Win32 API. Различные варианты обертываю #ifdef’ами, так же поступлю для старых версий Linux, если они есть.

Поддержка старой ос, это просто дополнительный код.

Ещё о COM.

COM и ActiveX API даже разработанное в 1998 году, корректно работает в любой версии Windows.
Хорошая технология, но лишь при правильном её использовании (вспомним микроскоп).

Sorry за повтор суждения о том, что у своего API много плюсов.

Так и есть. Своим API можно покрыть любой функцинал нижележайшей ОС. Даже если ОС не поддерживает функционал, можно предоставить заглушку или альтернативное решение.

Надеюсь вы в постах поделитесь опытом.

Если интересно. При сборке под debian 4, компилятор ругается на clock_gettime, обмажу #ifdef’ом добавлю другой вызов API.

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

Надеюсь, что через какое-то время у вас материала наберётся на цельную статью.

Я не сильно понимаю смысла в поддержке Win9x, так как живых пользователей подобного я ещё не встречал. Но поддерживать ту же XP достаточно похвально.

Более того, использовать компиляторы и стандарты тех времён это на самом деле правильная мысль, поскольку сторонние в сторонних тулчейнах далеко не идеальная поддержка этих же старых систем.

Я не сильно понимаю смысла в поддержке Win9x, так как живых пользователей подобного я ещё не встречал. Но поддерживать ту же XP достаточно похвально.

Мне нравится возиться со старым железом, в основном на него ставят Windows95 и Windows 98. Поддержка особых усилий не требует.

Более того, использовать компиляторы и стандарты тех времён это на самом деле правильная мысль, поскольку сторонние в сторонних тулчейнах далеко не идеальная поддержка этих же старых систем.

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

Я не сильно понимаю смысла в поддержке Win9x, так как живых пользователей подобного я ещё не встречал.

Мы здесь и нас много:)

... могут только принудительно выставить в 50

Просьба скор в 50 установить.

Это не вранье, не небылица:
Видели другие, видел я,
Как в ручную простого форумчанина
Превратить пытались в журавля…

Чтоб ему не видеть синей дали
И не отрываться от земли,
Грубо форумчанина окольцевали
И в ЛОР отметку занесли!

Спрятали в шкафу, связали крылья
Белой птице счастья моего,
Чтоб она дышала теплой пылью
И не замышляла ничего…

Но недаром птица в небе крепла!
Скор остался в дураках…
Сломанная клетка — горстка пепла,
А скор снова 50

Настолько сильно не хочется звезду получить?

Привычка по жизни «никогда, ни в чём не выпечятиваться».

«Самоуничижение паче гордыни».

Серафим Саровский прав!
РЕСПЕКТ ему!

Исправил часть сорцов туториала от NeHe по OpenGL, впилив часть сорцов библиотеки GLU. Думаю, добавить всю библиотеку исходниками.

Ещё добавил исходникми библиотеки FreeType последней версии. Все зависимости ношу с собой:)

Библиотека так же собирается новыми и старыми версиями gcc и msvc.

Минимальная версия gcc, которую я смог найти и проверить gcc 3.4.5 Минимальная версия msvc, Visual C++ 6.0

Пробывал собрать Visual C++ 5.0, но 100500 ошибок. Версия слишком куцая, обеспечивать совместимость не буду, не вижу смысла. Совместимости с Visual C++ 6.0, хватает для сборки и тестирования под Windows 95 и Windows 98.

Минимальная версия дистра на которой собирается фреймворк, Debian 4 (пока не внес изменения совместимости в общую репу, но из коробки поддерживатьс будет)

Как то так.

Текущие задачи.

1. Добавить потоковое воспроизведение аудио. (На всех поддерживаемых ОС)
2. Доделать подержку OpenGL3.
3. Сделать API работы с текстом, через библиотеку FreeType.
4. Доделать недостающий функционал под Linux.
5. Документация.

Если есть желание, присоединяйтесь к проекту. Буду рад помощи.