Коли уж Вы во все это полезли, стоило бы в общих чертах разобраться со структурой PE и особенностями средств сборки. :)
Я исходил из практических целей простоты. Где не нужно, что то нестандартное колхозить. Пишем код на С++ 98, берём совместимый компилятор. Собираем и работает.
Я не спорю что можно собрать на последней версии msvc в асм. Прогнать через, какую нить прогу, которая создат асм совместимый с fasm бородатой версии и собрать уже на нативной системе.
Я исходил из простоты. Пока данный метод не подвёл.
В чем смысл затачивания кода под старые компиляторы?
Мне интересно собрать код нативно. Поставить старую ос, туда компилятор той старой версии, собрать проект.
К примеру ещё это позволит собирать проект из коробки на старых версиях Linux с поддержкой gcc >= 2.95, а может ещё и более древней версией компилятора.
Это большой плюс для тестирования производительности с тем оригинальным железом.
Я бы не сказал, что я прям затачиваю код под старые компиляторы. Код С++ 98 с STL и namespace. Куда уж стандартней Правда без новых фич, зато не отвлекают:)
Так-то нет никаких проблем собирать PE хоть под Win95 самыми последними версиями VC++.
Это как? Я как раз использую visual c++ 6.0 именно потому, что бинарник может работать под windows 9x.
Сейчас проект собирается на следующих компиляторах, для компиляторов без STL я добавил свою реализацию std::string и stdint.h
Visual C++ 4.0
Visual C++ 5.0
Visual C++ 6.0
Собираю последней версией msvc 2022 и на linux gcc 13.
Всё, что выше Visual C++ 4.0 соберет, просто нужно протестировать. К примеру до версии MSVC 2010-2013 отсутствует stdint.h, его просто нужно добавить в пути сборки и должно все собраться. Для этого создал каталог support.
Тогда буду, до копирования массив пикселей преобразовывать в BGR, копировать в bitmap, потом обратно в RGB. Не знаете, почему в Windows приняли решение с BGR? К примеру в xlib, openGL и вроде как в DirectX, текстуры создаются из RGB массива байт.
Интересно надо будет посмотреть. С дос пойду таким же нативным путем. У в проекте все имена сорцов длиной 8 символов. Что бы нативно все собирать под dos и windows 3.1
В идеале собирать под максимальное количество компиляторов. Зачем? По фану:)
Да это отличный компилятор. И мне нравится, что он может кросс компилировать под старые ОС. Но мне ещё интересен момент нативной сборки на устаревших ОС.
Мне это позволяет посмотреть и пощупать старые ОС, компиляторы и т.д
Вы говорите о более функциональном фреймворке, что то близкое к движку. Я же пишу, библиотеку похожую на SDL, уж очень она мне нравится. Но на С++ и с поддержкой в том числе старых систем. Минимальный каркас абстрагирующий от нижележащей ОС.
Я придерживаюсь С++ 98. Так как существуют +- старые компиляторы которые могут собрать такой код нативно на старой ОС. Но ограничение только С++ 98 только для самой библиотеки. Вы же можете её собирать с любым новым стандартом С++ и с любой новой библиотекой.
К примеру я собираю компилятором msvc 2022 и gcc 13. Но он так же может быть собран компилятором намного старее, к примеру gcc 3.
Поддержку 3d ещё нужно встроить, OpenGL как пример. Что бы можно было создать окно с контекстом OpenGL. Я это запланировал но в будущих статьях.
Ответ: ничего искать не нужно, берете любую С/С++ библиотеку и используете. Намеренно искать старый компилятор не нужно.
Термин Легаси переводится как наследие. И использую я его именно в этом контексте. Поддерживая в том числе и старые ОС, типа windows 3.1 и windows 95. Этим и обусловлен замысел статей, gdi это Легаси api.
Я исходил из практических целей простоты. Где не нужно, что то нестандартное колхозить. Пишем код на С++ 98, берём совместимый компилятор. Собираем и работает.
Я не спорю что можно собрать на последней версии msvc в асм. Прогнать через, какую нить прогу, которая создат асм совместимый с fasm бородатой версии и собрать уже на нативной системе.
Я исходил из простоты. Пока данный метод не подвёл.
О каких именно библиотеках речь?
В будущем хотелось бы портировать на старые консоли и другое вообще железо. Там компилятор не обновлялся десятки лет.
Мне интересно собрать код нативно. Поставить старую ос, туда компилятор той старой версии, собрать проект.
К примеру ещё это позволит собирать проект из коробки на старых версиях Linux с поддержкой gcc >= 2.95, а может ещё и более древней версией компилятора.
Это большой плюс для тестирования производительности с тем оригинальным железом.
Я бы не сказал, что я прям затачиваю код под старые компиляторы. Код С++ 98 с STL и namespace. Куда уж стандартней Правда без новых фич, зато не отвлекают:)
Это как? Я как раз использую visual c++ 6.0 именно потому, что бинарник может работать под windows 9x.
Установил в эмулятор 86box, windows 95 и 98. Хочу все же попытаться собрать на Visual C++ 2.0.
Ну а далее продукты Borland C++ тех лет.
Да, хотелось перенести под множество систем. К примеру рендер основанный на буфере, можно и под микроконтроллеры портировать.
Сейчас проект собирается на следующих компиляторах, для компиляторов без STL я добавил свою реализацию std::string и stdint.h
Visual C++ 4.0
Visual C++ 5.0
Visual C++ 6.0
Собираю последней версией msvc 2022 и на linux gcc 13.
Всё, что выше Visual C++ 4.0 соберет, просто нужно протестировать. К примеру до версии MSVC 2010-2013 отсутствует stdint.h, его просто нужно добавить в пути сборки и должно все собраться. Для этого создал каталог support.
Спасибо понял. Я копирую в память созданного bitmap RGB, а он принимает BGR.
Тогда буду, до копирования массив пикселей преобразовывать в BGR, копировать в bitmap, потом обратно в RGB. Не знаете, почему в Windows приняли решение с BGR? К примеру в xlib, openGL и вроде как в DirectX, текстуры создаются из RGB массива байт.
Интересно надо будет посмотреть. С дос пойду таким же нативным путем. У в проекте все имена сорцов длиной 8 символов. Что бы нативно все собирать под dos и windows 3.1
В идеале собирать под максимальное количество компиляторов. Зачем? По фану:)
Я после gdi и xlib буду встраивать рендер в буфер, как это раньше делали с поддержкой палитры.
:)
Да это отличный компилятор. И мне нравится, что он может кросс компилировать под старые ОС. Но мне ещё интересен момент нативной сборки на устаревших ОС.
Мне это позволяет посмотреть и пощупать старые ОС, компиляторы и т.д
Спасибо, посмотрю.
Это был копипаст из статьи на которую я ссылаюсь. Я проверил, работает. И ничего не стал менять.
Open Watcom точно. Но если брать именно нативный, то что-то около borland C++ 4.0. STL нет, но можно часть функционала написать.string, vector.
Пишем нечто, поддерживающее легаси с нуля на С++, не вызывая подозрение у санитаров.
Теперь название стало лучше:)
Вы говорите о более функциональном фреймворке, что то близкое к движку. Я же пишу, библиотеку похожую на SDL, уж очень она мне нравится. Но на С++ и с поддержкой в том числе старых систем. Минимальный каркас абстрагирующий от нижележащей ОС.
Добавил голосование. В свете данного диалога.
Это каламбур.
Я создам опрос, что бы узнать многих ли напрягает такое название.
Я придерживаюсь С++ 98. Так как существуют +- старые компиляторы которые могут собрать такой код нативно на старой ОС. Но ограничение только С++ 98 только для самой библиотеки. Вы же можете её собирать с любым новым стандартом С++ и с любой новой библиотекой.
К примеру я собираю компилятором msvc 2022 и gcc 13. Но он так же может быть собран компилятором намного старее, к примеру gcc 3.
Поддержку 3d ещё нужно встроить, OpenGL как пример. Что бы можно было создать окно с контекстом OpenGL. Я это запланировал но в будущих статьях.
Ответ: ничего искать не нужно, берете любую С/С++ библиотеку и используете. Намеренно искать старый компилятор не нужно.
Термин Легаси переводится как наследие. И использую я его именно в этом контексте. Поддерживая в том числе и старые ОС, типа windows 3.1 и windows 95. Этим и обусловлен замысел статей, gdi это Легаси api.