Вы меня навели на мысль, сравнить task manager на разных ос, от windows 2000 по windows 11. Интересно сравнить, затраты цпу, ОЗУ, количество вызовов функции вообще.
Советую сходить на несколько мок-собесов к разным людям, которые тебя не знают, и протестировать самопрезентацию на них. Если они тебе поверят и захотели бы нанять — она написана хорошо.
Автор вы графоман, это не плохо. Второй момент вы, все слишком усложняете. На техническом собесе и так плясать приходится, даже с опытом 10+ лет. Так ещё первый бос это непосредственно HR, который будет дрочить тебя на старте, бессмысленно и беспощадно. Спасибо, но такой ИТ, не нужон.
Я пришел устраиваться на работу, что бы выполнять техническую работу. Мне на старте нужно разбираться, что то там личностное прорабатывать. Я не к психологу пришел. Есть, знания, опыт, навыки, оцениваете и решайте подходит, не подходит. А не это ваше несоответствие знака девы, в тельце луны, козерога млечного пути:)
Мне ещё кидали ссылку на патч для современной версии gcc, собирающейся и работающей на windows 98. Без потоков, но остальные фичи доступны. Но я пока не готов в этом разбираться, слишком временно затратно получается.
Коли уж Вы во все это полезли, стоило бы в общих чертах разобраться со структурой 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
В идеале собирать под максимальное количество компиляторов. Зачем? По фану:)
Вы меня навели на мысль, сравнить task manager на разных ос, от windows 2000 по windows 11. Интересно сравнить, затраты цпу, ОЗУ, количество вызовов функции вообще.
Буду разбираться по ходу дела.
Статья огонь, плюсую нещадно. Добавьте плиз тэг старое железо.
Интересно почитать пару выпусков. Добавил себе в бэклог
Библиотека LDL будет ограничена единым кроссплатформенным API для графики. Все остальное, забота разработчика.
Исправил цветность и протестировал на Windows 98 в эмуляторе.
Это в школу разведки собес. Зачем всё это?
Стрелочка в обратную сторону не работает?;)
Автор вы графоман, это не плохо. Второй момент вы, все слишком усложняете. На техническом собесе и так плясать приходится, даже с опытом 10+ лет. Так ещё первый бос это непосредственно HR, который будет дрочить тебя на старте, бессмысленно и беспощадно. Спасибо, но такой ИТ, не нужон.
Я пришел устраиваться на работу, что бы выполнять техническую работу. Мне на старте нужно разбираться, что то там личностное прорабатывать. Я не к психологу пришел. Есть, знания, опыт, навыки, оцениваете и решайте подходит, не подходит. А не это ваше несоответствие знака девы, в тельце луны, козерога млечного пути:)
Мне ещё кидали ссылку на патч для современной версии gcc, собирающейся и работающей на windows 98. Без потоков, но остальные фичи доступны. Но я пока не готов в этом разбираться, слишком временно затратно получается.
В том числе, да.
Я исходил из практических целей простоты. Где не нужно, что то нестандартное колхозить. Пишем код на С++ 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
В идеале собирать под максимальное количество компиляторов. Зачем? По фану:)