Комментарии 42
Comeau славился хорошей поддержкой 98го стандарта (включая export), должен справиться (если удастся его найти). Topspeed ещё в своё время был на слуху, но боюсь туда новомодные namespace/template не доехали.
Мне кажется, для легасей ничего лучше опенваткома не придумали ещё :)
Но может и казаться, конечно…
UPD: что-то охота поиграться с VGA для какого-нибудь элементарного рендерера типа Wolf3D. С нормальной пушкой — 320х200, а взял ночной снайперский прицел — включается 640х480, где рендерятся все 4 цветовые плоскости по очереди :) Такая цепочка «призраков» от прошлых кадров, типа это так ночная оптоэлектроника работает :) И 16 цветов, конечно, раз VGA 640x480. Может быть прикольно :)
Короче, меня тоже пробило на олдскул %)
Да это отличный компилятор. И мне нравится, что он может кросс компилировать под старые ОС. Но мне ещё интересен момент нативной сборки на устаревших ОС.
Мне это позволяет посмотреть и пощупать старые ОС, компиляторы и т.д
Я после gdi и xlib буду встраивать рендер в буфер, как это раньше делали с поддержкой палитры.
Короче, меня тоже пробило на олдскул %)
:)
Если под DOS - так можно и достаточно свежий gcc взять.
Надо брать последний компилятор под платформу. Согласно СО для VC это версия 2003, кстати была и бесплатная. Чтобы получше поддержка стандарта была.
Ну а так еще Ватком, мингв, симантек (dmc), борланд поновее, остальное совсем экзотика
Stl шла от dinkumware
VC2003 - это там где сервис пак на студию ставился очень-очень-очень долго по сравнению с установкой самой студии?
Сейчас проект собирается на следующих компиляторах, для компиляторов без 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.
В чем смысл затачивания кода под старые компиляторы? Какова вероятность, что кому-то потребуется собирать его именно ими?
Если что, VC++ вплоть до 6.0 не понимает многих библиотек из MS SDK (там новый формат).
Так-то нет никаких проблем собирать PE хоть под Win95 самыми последними версиями VC++.
В чем смысл затачивания кода под старые компиляторы?
Мне интересно собрать код нативно. Поставить старую ос, туда компилятор той старой версии, собрать проект.
К примеру ещё это позволит собирать проект из коробки на старых версиях Linux с поддержкой gcc >= 2.95, а может ещё и более древней версией компилятора.
Это большой плюс для тестирования производительности с тем оригинальным железом.
Я бы не сказал, что я прям затачиваю код под старые компиляторы. Код С++ 98 с STL и namespace. Куда уж стандартней Правда без новых фич, зато не отвлекают:)
Так-то нет никаких проблем собирать PE хоть под Win95 самыми последними версиями VC++.
Это как? Я как раз использую visual c++ 6.0 именно потому, что бинарник может работать под windows 9x.
собирать проект из коробки на старых версиях Linux с поддержкой gcc >= 2.95
С линуксами, где компилятор идет в составе ОС, как раз понятно. Непонятно с виндами, где под любой версией можно использовать [почти] любой компилятор.
Я как раз использую visual c++ 6.0 именно потому, что бинарник может работать под windows 9x
Коли уж Вы во все это полезли, стоило бы в общих чертах разобраться со структурой PE и особенностями средств сборки. :)
Система вообще ничего не знает о том, каким компилятором/линкером собирался PE - она тупо смотрит на его заголовок и таблицы, чтобы определить, сможет ли она его загрузить. В этом смысле компилятор вообще не имеет значения - только линкер.
Если значимые характеристики PE (платформа, подсистема, параметры секций, необходимые импорты и прочее) ее устраивают, то единственное, что может помешать загрузке - это номера версий системы/подсистемы, а их можно установить произвольно. Самые новые компиляторы не позволяют устанавливать номера ниже 5.1 или 5.0, но ничто не мешает использовать сторонние утилиты для правки версий уже после сборки.
Коли уж Вы во все это полезли, стоило бы в общих чертах разобраться со структурой PE и особенностями средств сборки. :)
Я исходил из практических целей простоты. Где не нужно, что то нестандартное колхозить. Пишем код на С++ 98, берём совместимый компилятор. Собираем и работает.
Я не спорю что можно собрать на последней версии msvc в асм. Прогнать через, какую нить прогу, которая создат асм совместимый с fasm бородатой версии и собрать уже на нативной системе.
Я исходил из простоты. Пока данный метод не подвёл.
можно собрать на последней версии msvc в асм
Не нужен никакой "асм". Компилируете cl.exe, собираете link.exe, больше ничего не требуется, кроме [возможной] правки номеров версий в заголовке полученного PE.
Последний CRT может не запуститься на Win98, а исходники/заголовки CRT от VC6 могут не компилироваться на MSVC 2022.
И последний, и даже десятилетней давности CRT не просто "может не запуститься", а гарантированно не запустится на Win9x. :) Именно поэтому и делают собственные CRT.
А вот зачем может потребоваться компилировать в VS 2022 исходники/заголовки CRT от VC 6, я не знаю - это какое-то редкое извращение.
А у msvcrt.dll насколько интерфейс стабилен? w64devkit сидит на ней, вроде хватает.
Я не изучал, но, судя по экспортам, бОльшая часть libc там есть, как и большинство функций CRT. Но у самих этих функций с течением времени менялись интерфейсы, так что тупо подсунуть msvcrt.lib вместо libc*.lib современным компиляторам не получится. Но, если CRT свой, msvcrt.dll вполне можно использовать.
так что тупо подсунуть msvcrt.lib вместо libc*.lib современным компиляторам не получится.
w64devkit как раз это и делает - там новый gcc, которому в качестве libc дают старый неверсионированный msvcrt (возможно с какими то подпорками, но других dll как у cygwin или msys нет). Вопрос, насколько скомпилированный таким образом бинарник переносим между разными версиями винды.
Ну, gcc тут как раз более конфигурабелен. Хотя и VC++ тоже весьма управляем. По сути, достаточно не включать автоматической генерации вызовов, не поддерживаемых самыми старыми версиями msvcrt.dll (например, поддержка RTC там появилась то ли в 7.x, то ли в 8.0), и будет совместимо насквозь.
Вот, сейчас скомпилил VC++ 15.00 (из VS 2008) простейший консольный пример с printf, подсунул линкеру msvcrt.lib от 4.2 - размер 2560 байт. Поправил версии в заголовке PE - работает от Win 95 OSR2 до Win 11 24H2.
Мне ещё кидали ссылку на патч для современной версии gcc, собирающейся и работающей на windows 98. Без потоков, но остальные фичи доступны. Но я пока не готов в этом разбираться, слишком временно затратно получается.
Коли уж Вы во все это полезли, стоило бы в общих чертах разобраться со структурой PE
Человек же ещё NEшные бинарники собирается генерировать, не говоря уж о прочей экзотике.
В будущем хотелось бы портировать на старые консоли и другое вообще железо. Там компилятор не обновлялся десятки лет.
Если что, VC++ вплоть до 6.0 не понимает многих библиотек из MS SDK (там новый формат).
О каких именно библиотеках речь?
Так-то нет никаких проблем собирать PE хоть под Win95 самыми последними версиями VC++.
Вообще то нет. Есть стартуп код, да и стандартные библиотеки зачастую новые системные вызовы используют
Правда в оригинале цвет должен быть красным, а не синим. Но пока вывод изображений не закончен.
Просто переставьте их местами. Где-то у вас перепутан порядок R и B в 16/32 битах цвета.
Спасибо понял. Я копирую в память созданного bitmap RGB, а он принимает BGR.
Тогда буду, до копирования массив пикселей преобразовывать в BGR, копировать в bitmap, потом обратно в RGB. Не знаете, почему в Windows приняли решение с BGR? К примеру в xlib, openGL и вроде как в DirectX, текстуры создаются из RGB массива байт.
Я уже не помню, но, вероятно, тут дело в старшем/младшем байте. В little-endian первым лежит младший байт. Итого, раскладка 32 бит от 31-го к нулевому будет:
11111111 rrrrrrrr gggggggg bbbbbbbb;
В памяти это ложится как B,G,R,0xFF. Поэтому, если у вас формат хранения байтовый (массив uint8_t), то задавать вам нужно B,G,R. А вот если uint32_t, то вот как битовая раскладка (0xff<<24)|(r<<16)|(g<<8)|(b<<0).
Установил в эмулятор 86box, windows 95 и 98. Хочу все же попытаться собрать на Visual C++ 2.0.
Ну а далее продукты Borland C++ тех лет.
Исправил цветность и протестировал на Windows 98 в эмуляторе.
Пишем легаси с нуля на С++, не вызывая подозрение у санитаров. 04 — Компиляторная археология