Как видите, решение настолько простое и прямо напрашивается, что другой человек написал бы почти то же самое, просто имея похожую идею в голове =)
Впрочем, перед тем, как писать свой вариант (несколько лет назад), я немного гуглил, и мне почему-то попадались примеры оверинжиниринга. Кто-то даже использовал std::function для хранения лямбды (что совершенно не бесплатно и генерирует кучу ненужного в данном случае кода).
Об этом написано в самом конце статьи. С явным [&] выше гибкость (например, можно организовать условный defer, для которого необходимость выполнения вычисляется на месте defer), лучше наглядность (сразу понятно, что это лямбда, и return какого-то значения из неё никак не повлияет на результат внешней функции), и точка с запятой в конце имеет смысл (так как это defer callable;, а не некое подобие конструкции языка вроде if {}, где точка с запятой в конце не требуется). Ну и как вишенка на торте, когда я изначально делал этот макрос, был актуален пропозал добавить defer в Си, и он использовал именно такой синтаксис (но его, увы, не приняли, хотя как встроенная фича в Си он очень был бы кстати).
Не совсем понимаю в чем реализация полагается на C++17, тут C++11 должно быть достаточно.
Пришлось бы усложнять код, иначе не скомпилируется. В C++17 подтянули автовывод типов в шаблонах, плюс добавили гарантированный copy elision в некоторых случаях типа A a = A();. Кажется, с более старыми стандартами я не сталкивался уже более 5 лет. Нет смысла писать более сложный код под устаревшие компиляторы только потому, что это в принципе возможно.
Если бы C++23 был уже в мейнстриме, я бы сразу в него и целился. Там вместо громоздкого:
#define TOKEN_CONCAT_NX(a, b) a ## b
#define TOKEN_CONCAT(a, b) TOKEN_CONCAT_NX(a, b)
#define defer deferrer TOKEN_CONCAT(__deferred, __COUNTER__) =
можно было бы использовать недавно стандартизированный плейсхолдер _ и написать просто:
К сожалению, там используется шаблон под названием defer, поэтому макрос с таким же именем по понятным причинам несовместим с этим кодом. Можете попробовать заменить имя макроса на DEFER или что-то другое, что не пересекается с вашим кодом.
Как указано в первом абзаце статьи, defer хорош для низкоуровневого си-подобного кода. Boost в таком случае встречается редко, обычно нет поддержки исключений, часто нет полноценного STL, а иногда даже и стандартной библиотеки C. Если же у вас в проекте используются высокоуровневые библиотеки типа Boost.Asio, то наверное стоит и для всего остального использовать полноценные RAII-врапперы, либо же разделять высокоуровневый и низкоуровневый код по разным translation unit.
Вашему решению не хватает лаконичности и гибкости. Все те же задачи решаются простым defer из данной статьи, без введения лишних сущностей. Если вам нужен какой-то условный defer, вы можете просто явно прописывать эти условия в самой отложенной лямбде. Это мало того, что требует меньше кода, так ещё и более гибко: можно одной переменной отменять сразу несколько отложенных лямбд, в отличие от вашего решения.
Предложенный defer имеет очень простую концепцию. Его легко воспроизвести (всего десяток строк кода), легко усвоить (всего одно новое ключевое слово), и просто адаптировать прямо на месте под нужды вашей функции, добавляя любые условия как на месте вызова defer (путём захвата cond по значению), так и на месте выполнения лямбды (читая значения переменных по ссылкам).
Я же упомянул об этом прямо во втором предложении в статье:
Создание достойных RAII-врапперов для каждого используемого сишного API не всегда практично
Для полноты картины вам нужно учитывать объём кода всех созданных вами врапперов, а так же то, что они будут не везде применимы. Например, после CreateProcess у вас в структуре PROCESS_INFORMATION pi будут сырые хендлы pi.hProcess и pi.hThread, которые нужно закрыть, и вот вам уже нужно писать свой враппер для CreateProcess. Так вы быстро скатитесь к разработке целого C++ фреймворка на все случаи жизни вместо С-подобного низкоуровневого кода, о котором идёт речь в статье.
Google важно охватить актуальные ОС и железо. Я не вижу причин, зачем Google заморачиваться с поддержкой экзотических дистрибутивов Linux на экзотическом железе. Если это действительно кому-то нужно, они сами найдут ресурсы и время, чтобы собрать свежий Clang и другие зависимости, необходимые для сборки свежего Chromium.
Clang развивается в том числе и Google в том числе и для нужд разработки Chromium. Логично, что Chromium свободно использует желаемые новые возможности из С++20, и это задокументировано. Скорее наоборот, если кто-то напишет код в стиле C++98, то его завернут на ревью, если то же самое можно написать проще и лучше с фишками из C++20. Зачем писать заведомо устаревший код, если речь не идёт про разработку для устаревших систем?
Не нужно во всём видеть злой умысел MS. Visual C++ из самой последней Visual Studio 2022 пока ещё полностью поддерживает сборку программ совместимых с Windows 7, нет никаких ограничений. Qt и Boost не поддерживают Windows 7 только потому, что их авторы больше не видят смысла тратить время на её поддержку.
В случае с бесплатным обновлением Windows 7 на Windows 10 на самом деле сразу было заявлено, что акция временная. В случае же с бесплатным обновлением до Windows 11 никаких временных ограничений не указано.
Почему отдельная? Qt использует тот же самый WinAPI, который в целом кажется что тот же, но на самом деле изменений то тут то там полно, много новых полезных функций, которые хочется использовать в новом коде. А сохранение поддержки Windows 7 — это постоянная трата лишнего времени на тестирование и реализацию фоллбэков для недостающих функций.
А почему они отказываются? Что в Firefox 116 принципиально поменялось по сравнению со 115, что он стал несовместим с Windows 7? 99%, что это искусственное ограничение.
Причины те же. До этого разработчики регулярно тратили то тут то там время на поддержку Windows 7. В какой-то момент на их просьбу перестать это делать менеджмент дал добро, и они с облегчением скинули с себя этот груз. Да-да, это не злой менеджмент внезапно сказал разрабам «Срочно удаляем поддержку Windows 7. Выполнять!», на что разрабы скрепя сердце пошли удалять фрагменты любимого кода. На самом деле, разрабы 3 года ждали решения от менеджмента.
А все остальное — прогресс ради прогресса. Ввели новые API — для чего? Старые же работали...
С таким подходом можно было оставаться на Windows XP и IE6 с Macromedia Flash на пару. Старые API тоже работали и в принципе можно было сделать почти всё то же самое что и сейчас. Пускай с костылями, но можно же, так? Помните костылик для поддержки прозрачности в PNG, который работал почти везде? Ну и что, что он не работал с PNG в фоне, можно же было выкрутиться. Ну и что, что PNG8 с альфа-каналом всё равно не поддерживался, можно было же выкрутиться с PNG без палитры. Так что же, полноценная поддержка PNG не нужна? Ведь это почти то же самое, что и было до этого. Зато с костыликами пользователям не придётся пройти через муки обновления до IE7.
Вот и получается, что вместо исправления косяков старых API придумывают новые. :-(
Так проблемы старых функций тоже регулярно исправляются, они дорабатываются, появляются новые флаги и т.д. Например, стандартный контрол многострочного ввода в Windows 10 научился понимать не только \r\n, но и просто \n. Одновременно с этим стандартный блокнот научился показывать нормально текстовые файлы с такими переводами строк. Эта проблема так долго докучала людей, что об этом изменении даже в новостях писали.
Только проблемы несовместимости в таких случаях, когда используется какой-то новый флаг старого API, гораздо сложнее заметить. Программа запустится и будет работать, но Windows 7 будет игнорировать незнакомый ей флаг, и вроде внешне всё работает, но что-то где-то как-то странно глючит, и без полного тестирования всех возможных юзкейзов такие проблемы сложно отловить. А когда Windows 7 уже не используется при разработке, такие незаметные с первого взгляда баги будут неизбежно попадать в релиз, что неприемлемо.
Кстати, вот прямо вчера в MS STL Discord разработчики MSVC обсуждали отказ от поддержки Windows 7-8.1. Из обсуждения очевидно, что они ждут, когда уже наконец смогут дропнуть поддержку Windows 7-8.1 в рантайме. Ждут, когда менеджмент разрешит сделать новый бинарно-несовместимый рантайм, где уже не будет необходимости поддерживать устаревшие ОС, и где можно будет наконец решить некоторые накопившиеся за 10 лет проблемы (рантаймы VS2015-VS2022 бинарно совместимы по решению менеджмента, из-за чего у разрабов MS STL несколько связаны руки).
IE6, кстати, для своего времени был достаточно прорывным. Просто он задержался слишком надолго (IE7 вышел лишь через 5 лет и был относительно небольшим обновлением), и многие уже доступные в нём вещи позднее в стандарты попали в другом виде.
GUI тоже сильно изменился, и речь не только про новые модные WinUI. В целом очень много изменений касательно поддержки дисплеев с высокой плотностью пикселей, например.
Я почти не занимаюсь UI, но могу вам привести такой пример: Qt6 требует Windows 10 (1809 и новее). Почти наверняка у разработчиков Qt соображения были такие же — слишком много возни ради устаревшей версии ОС.
Qt5 работает на Windows 7, но у него бывают проблемы с HiDPI. Если программа на нём была запущена на мониторе с высокой плотностью пикселей, а потом оказалась на мониторе со стандартной плотностью, окно становится гигантским (и наоборот). Меня эта проблема беспокоит в Telegram Desktop. Он не может перерисовать себя нормально, когда я ноут с HiDPI дисплеем подключаю к внешнему монитору с обычным дисплеем. Как я понял, проблема в Qt5, и она решена в Qt6, но Qt6 требует Windows 10. То есть, по идее, когда Telegram полностью мигрирует на Qt6, проблема у пользователей современных версий Windows решится, но не останется поддержки Windows 7.
Софт, что опирается на Qt, потихонечку перебирается на Qt6. Недавно вот qBittorrent перешёл на новую версию фреймворка (и соответственно избавился от поддержки Windows 7).
Но вообще, для широких масс обязательно нужно обновляться на что угодно просто из-за того, что на Windows 7 скоро не останется ни одного поддерживаемого браузера. Chrome уже почти год как не поддерживает Windows 7, Firefox для Windows 7 остановился на версии 115 ESR, в котором обещают латать дыры до сентября 2024. На Windows 7 можно оставаться только вы не собираетесь из неё подключаться в интернет, а планируете, например, играть в какие-то старые игры или использовать какие-то старые программы.
Сама Microsoft пока что поддерживает сборку под Windows 7 в самой свежей VS2022, но так как софт массово отказывается от поддержки этой устаревшей ОС, не удивлюсь, если в условной VS2025 свежий рантайм также будет требовать не менее Windows 10. И это опять же будет не потому что разработчики в Microsoft такие злые, а просто потому что у них хватает других забот, кроме как заботиться о совместимости с неподдерживаемой и выходящей из употребления версией ОС.
Ну за 10+ лет со времён «семёрки» действительно многое изменилось, даже для обычных не низкоуровневых приложений.
Например, если вы просто хотите сделать обычное консольное приложение в 2023 году, и вас не интересует что там в ядре: поддержку esc-последовательностей для раскраски текста и родную поддержку UTF-8 завезли только в Windows 10+, и это сильно помогает писать кроссплатформенный код.
Некоторые из новых API вообще без страшных костылей не заменить в старых версиях ОС (например, псевдоконсоли, что позволяют встраивать консольку в ваше приложение).
Да, можно выкручиваться без этого, но зачем, если старыми ОС почти никто уже и не пользуется? Это как страдать без современных технологий ради поддержки давно забытого производителем IE6.
У нас не простое GUI-приложение, в котором все проблемы решаются авторами библиотек, на которые приложение полагается. У нас низкоуровневая разработка, мы работаем в основном на уровне ядра или близко к нему, GUI почти нет.
Пишу как любитель Windows XP (на которой я сидел до 2014) и Windows 7 (которая была основной на домашнем компьютере до 2022).
В нашем продукте тоже дропнули поддержку Windows 7 пару месяцев назад, и я лично потратил день на выпиливание всех связанных с ней костылей. Но причина не в том, что Microsoft прекратила поддержку (хотя это конечно развязывает нам руки), а в том, что на поддержку Windows 7 регулярно уходило время, при этом на ней сидит меньше 1% пользователей, так что реальной бизнес-необходимости поддерживать её не было уже давно.
Просто всё оставить как есть не получилось бы, поддержка Windows 7 не получалась сама по себе магическим образом, на это регулярно уходило время. Разработка ведётся на Windows 10-11, соответственно эти версии тестируются прямо во время разработки. Мы выпускаем новые версии нашего ПО каждый месяц. И каждый месяц перед релизом я проверял, а всё ли работает на Windows 7. И практически каждый раз выяснялось, что что-то серьёзно поломалось, и мне приходилось тратить время на починку.
И вот когда при приближении очередного релиза в очередной раз что-то сломалось на Windows 7, я предложил отказаться от поддержки устаревших ОС, и команда это единогласно поддержала. Поэтому вместо того, чтобы в очередной раз тратить время на починку, я потратил время на удаление тысяч строк старых костылей для Windows 7. Думаю, без меня поддержку Windows 7 дропнули бы ещё раньше, так как этим больше никто не хотел заниматься.
Ирония в том, что даже ошибку "Для работы программы требуется Windows 10 и новее" тоже умудрились недавно сломать, и я это вот прям вчера чинил. Даже вывод сообщения о том, что Windows 7 не поддерживается, приходится поддерживать на Windows 7 =) Ну то есть, пока мы хотим выводить внятную ошибку на Windows 7, нельзя, например, напрямую импортировать функции, которые появились только в Windows 10. Но со временем и это станет не нужно.
У меня всё ещё есть компьютер с Windows 7, но теперь он больше для ретро-целей. Старой ОС — старые программы и игры =)
Как видите, решение настолько простое и прямо напрашивается, что другой человек написал бы почти то же самое, просто имея похожую идею в голове =)
Впрочем, перед тем, как писать свой вариант (несколько лет назад), я немного гуглил, и мне почему-то попадались примеры оверинжиниринга. Кто-то даже использовал
std::functionдля хранения лямбды (что совершенно не бесплатно и генерирует кучу ненужного в данном случае кода).Вы правы, исправил пример. Спасибо за вашу внимательность =)
Об этом написано в самом конце статьи. С явным
[&]выше гибкость (например, можно организовать условный defer, для которого необходимость выполнения вычисляется на месте defer), лучше наглядность (сразу понятно, что это лямбда, и return какого-то значения из неё никак не повлияет на результат внешней функции), и точка с запятой в конце имеет смысл (так как этоdefer callable;, а не некое подобие конструкции языка вродеif {}, где точка с запятой в конце не требуется). Ну и как вишенка на торте, когда я изначально делал этот макрос, был актуален пропозал добавитьdeferв Си, и он использовал именно такой синтаксис (но его, увы, не приняли, хотя как встроенная фича в Си он очень был бы кстати).Пришлось бы усложнять код, иначе не скомпилируется. В C++17 подтянули автовывод типов в шаблонах, плюс добавили гарантированный copy elision в некоторых случаях типа
A a = A();. Кажется, с более старыми стандартами я не сталкивался уже более 5 лет. Нет смысла писать более сложный код под устаревшие компиляторы только потому, что это в принципе возможно.Если бы C++23 был уже в мейнстриме, я бы сразу в него и целился. Там вместо громоздкого:
можно было бы использовать недавно стандартизированный плейсхолдер
_и написать просто:Через несколько лет так и будем писать =)
К сожалению, там используется шаблон под названием
defer, поэтому макрос с таким же именем по понятным причинам несовместим с этим кодом. Можете попробовать заменить имя макроса наDEFERили что-то другое, что не пересекается с вашим кодом.Как указано в первом абзаце статьи,
deferхорош для низкоуровневого си-подобного кода. Boost в таком случае встречается редко, обычно нет поддержки исключений, часто нет полноценного STL, а иногда даже и стандартной библиотеки C. Если же у вас в проекте используются высокоуровневые библиотеки типа Boost.Asio, то наверное стоит и для всего остального использовать полноценные RAII-врапперы, либо же разделять высокоуровневый и низкоуровневый код по разным translation unit.Вашему решению не хватает лаконичности и гибкости. Все те же задачи решаются простым
deferиз данной статьи, без введения лишних сущностей. Если вам нужен какой-то условныйdefer, вы можете просто явно прописывать эти условия в самой отложенной лямбде. Это мало того, что требует меньше кода, так ещё и более гибко: можно одной переменной отменять сразу несколько отложенных лямбд, в отличие от вашего решения.Предложенный
deferимеет очень простую концепцию. Его легко воспроизвести (всего десяток строк кода), легко усвоить (всего одно новое ключевое слово), и просто адаптировать прямо на месте под нужды вашей функции, добавляя любые условия как на месте вызоваdefer(путём захватаcondпо значению), так и на месте выполнения лямбды (читая значения переменных по ссылкам).То же самое, что и в случае исключения в любом деструкторе. Не стоит бросать исключения в деструкторах =)
Это правда, но небольшая щепотка, которая облегчает жизнь, вполне допустима. Тем более в C-подобном коде, где ими и так щедро усыпано.
Я же упомянул об этом прямо во втором предложении в статье:
Для полноты картины вам нужно учитывать объём кода всех созданных вами врапперов, а так же то, что они будут не везде применимы. Например, после
CreateProcessу вас в структуреPROCESS_INFORMATION piбудут сырые хендлыpi.hProcessиpi.hThread, которые нужно закрыть, и вот вам уже нужно писать свой враппер дляCreateProcess. Так вы быстро скатитесь к разработке целого C++ фреймворка на все случаи жизни вместо С-подобного низкоуровневого кода, о котором идёт речь в статье.Если очень повезёт, то в C++26, но скорее всего в C++29.
Ого, как категорично!
Не помешало бы привести конкретный пример, демонстрирующий озвученные проблемы.
Google важно охватить актуальные ОС и железо. Я не вижу причин, зачем Google заморачиваться с поддержкой экзотических дистрибутивов Linux на экзотическом железе. Если это действительно кому-то нужно, они сами найдут ресурсы и время, чтобы собрать свежий Clang и другие зависимости, необходимые для сборки свежего Chromium.
Clang развивается в том числе и Google в том числе и для нужд разработки Chromium. Логично, что Chromium свободно использует желаемые новые возможности из С++20, и это задокументировано. Скорее наоборот, если кто-то напишет код в стиле C++98, то его завернут на ревью, если то же самое можно написать проще и лучше с фишками из C++20. Зачем писать заведомо устаревший код, если речь не идёт про разработку для устаревших систем?
Не нужно во всём видеть злой умысел MS. Visual C++ из самой последней Visual Studio 2022 пока ещё полностью поддерживает сборку программ совместимых с Windows 7, нет никаких ограничений. Qt и Boost не поддерживают Windows 7 только потому, что их авторы больше не видят смысла тратить время на её поддержку.
В случае с бесплатным обновлением Windows 7 на Windows 10 на самом деле сразу было заявлено, что акция временная. В случае же с бесплатным обновлением до Windows 11 никаких временных ограничений не указано.
Ну так Windows 11 и есть бесплатное обновление-дополнение для 10. От того что маркетинговое название изменилось суть не поменялась.
Почему отдельная? Qt использует тот же самый WinAPI, который в целом кажется что тот же, но на самом деле изменений то тут то там полно, много новых полезных функций, которые хочется использовать в новом коде. А сохранение поддержки Windows 7 — это постоянная трата лишнего времени на тестирование и реализацию фоллбэков для недостающих функций.
Причины те же. До этого разработчики регулярно тратили то тут то там время на поддержку Windows 7. В какой-то момент на их просьбу перестать это делать менеджмент дал добро, и они с облегчением скинули с себя этот груз. Да-да, это не злой менеджмент внезапно сказал разрабам «Срочно удаляем поддержку Windows 7. Выполнять!», на что разрабы скрепя сердце пошли удалять фрагменты любимого кода. На самом деле, разрабы 3 года ждали решения от менеджмента.
С таким подходом можно было оставаться на Windows XP и IE6 с Macromedia Flash на пару. Старые API тоже работали и в принципе можно было сделать почти всё то же самое что и сейчас. Пускай с костылями, но можно же, так? Помните костылик для поддержки прозрачности в PNG, который работал почти везде? Ну и что, что он не работал с PNG в фоне, можно же было выкрутиться. Ну и что, что PNG8 с альфа-каналом всё равно не поддерживался, можно было же выкрутиться с PNG без палитры. Так что же, полноценная поддержка PNG не нужна? Ведь это почти то же самое, что и было до этого. Зато с костыликами пользователям не придётся пройти через муки обновления до IE7.
Так проблемы старых функций тоже регулярно исправляются, они дорабатываются, появляются новые флаги и т.д. Например, стандартный контрол многострочного ввода в Windows 10 научился понимать не только
\r\n, но и просто\n. Одновременно с этим стандартный блокнот научился показывать нормально текстовые файлы с такими переводами строк. Эта проблема так долго докучала людей, что об этом изменении даже в новостях писали.Только проблемы несовместимости в таких случаях, когда используется какой-то новый флаг старого API, гораздо сложнее заметить. Программа запустится и будет работать, но Windows 7 будет игнорировать незнакомый ей флаг, и вроде внешне всё работает, но что-то где-то как-то странно глючит, и без полного тестирования всех возможных юзкейзов такие проблемы сложно отловить. А когда Windows 7 уже не используется при разработке, такие незаметные с первого взгляда баги будут неизбежно попадать в релиз, что неприемлемо.
Кстати, вот прямо вчера в MS STL Discord разработчики MSVC обсуждали отказ от поддержки Windows 7-8.1. Из обсуждения очевидно, что они ждут, когда уже наконец смогут дропнуть поддержку Windows 7-8.1 в рантайме. Ждут, когда менеджмент разрешит сделать новый бинарно-несовместимый рантайм, где уже не будет необходимости поддерживать устаревшие ОС, и где можно будет наконец решить некоторые накопившиеся за 10 лет проблемы (рантаймы VS2015-VS2022 бинарно совместимы по решению менеджмента, из-за чего у разрабов MS STL несколько связаны руки).
IE6, кстати, для своего времени был достаточно прорывным. Просто он задержался слишком надолго (IE7 вышел лишь через 5 лет и был относительно небольшим обновлением), и многие уже доступные в нём вещи позднее в стандарты попали в другом виде.
GUI тоже сильно изменился, и речь не только про новые модные WinUI. В целом очень много изменений касательно поддержки дисплеев с высокой плотностью пикселей, например.
Я почти не занимаюсь UI, но могу вам привести такой пример: Qt6 требует Windows 10 (1809 и новее). Почти наверняка у разработчиков Qt соображения были такие же — слишком много возни ради устаревшей версии ОС.
Qt5 работает на Windows 7, но у него бывают проблемы с HiDPI. Если программа на нём была запущена на мониторе с высокой плотностью пикселей, а потом оказалась на мониторе со стандартной плотностью, окно становится гигантским (и наоборот). Меня эта проблема беспокоит в Telegram Desktop. Он не может перерисовать себя нормально, когда я ноут с HiDPI дисплеем подключаю к внешнему монитору с обычным дисплеем. Как я понял, проблема в Qt5, и она решена в Qt6, но Qt6 требует Windows 10. То есть, по идее, когда Telegram полностью мигрирует на Qt6, проблема у пользователей современных версий Windows решится, но не останется поддержки Windows 7.
Софт, что опирается на Qt, потихонечку перебирается на Qt6. Недавно вот qBittorrent перешёл на новую версию фреймворка (и соответственно избавился от поддержки Windows 7).
Но вообще, для широких масс обязательно нужно обновляться на что угодно просто из-за того, что на Windows 7 скоро не останется ни одного поддерживаемого браузера. Chrome уже почти год как не поддерживает Windows 7, Firefox для Windows 7 остановился на версии 115 ESR, в котором обещают латать дыры до сентября 2024. На Windows 7 можно оставаться только вы не собираетесь из неё подключаться в интернет, а планируете, например, играть в какие-то старые игры или использовать какие-то старые программы.
Сама Microsoft пока что поддерживает сборку под Windows 7 в самой свежей VS2022, но так как софт массово отказывается от поддержки этой устаревшей ОС, не удивлюсь, если в условной VS2025 свежий рантайм также будет требовать не менее Windows 10. И это опять же будет не потому что разработчики в Microsoft такие злые, а просто потому что у них хватает других забот, кроме как заботиться о совместимости с неподдерживаемой и выходящей из употребления версией ОС.
Ну за 10+ лет со времён «семёрки» действительно многое изменилось, даже для обычных не низкоуровневых приложений.
Например, если вы просто хотите сделать обычное консольное приложение в 2023 году, и вас не интересует что там в ядре: поддержку esc-последовательностей для раскраски текста и родную поддержку UTF-8 завезли только в Windows 10+, и это сильно помогает писать кроссплатформенный код.
Некоторые из новых API вообще без страшных костылей не заменить в старых версиях ОС (например, псевдоконсоли, что позволяют встраивать консольку в ваше приложение).
Да, можно выкручиваться без этого, но зачем, если старыми ОС почти никто уже и не пользуется? Это как страдать без современных технологий ради поддержки давно забытого производителем IE6.
У нас не простое GUI-приложение, в котором все проблемы решаются авторами библиотек, на которые приложение полагается. У нас низкоуровневая разработка, мы работаем в основном на уровне ядра или близко к нему, GUI почти нет.
Пишу как любитель Windows XP (на которой я сидел до 2014) и Windows 7 (которая была основной на домашнем компьютере до 2022).
В нашем продукте тоже дропнули поддержку Windows 7 пару месяцев назад, и я лично потратил день на выпиливание всех связанных с ней костылей. Но причина не в том, что Microsoft прекратила поддержку (хотя это конечно развязывает нам руки), а в том, что на поддержку Windows 7 регулярно уходило время, при этом на ней сидит меньше 1% пользователей, так что реальной бизнес-необходимости поддерживать её не было уже давно.
Просто всё оставить как есть не получилось бы, поддержка Windows 7 не получалась сама по себе магическим образом, на это регулярно уходило время. Разработка ведётся на Windows 10-11, соответственно эти версии тестируются прямо во время разработки. Мы выпускаем новые версии нашего ПО каждый месяц. И каждый месяц перед релизом я проверял, а всё ли работает на Windows 7. И практически каждый раз выяснялось, что что-то серьёзно поломалось, и мне приходилось тратить время на починку.
И вот когда при приближении очередного релиза в очередной раз что-то сломалось на Windows 7, я предложил отказаться от поддержки устаревших ОС, и команда это единогласно поддержала. Поэтому вместо того, чтобы в очередной раз тратить время на починку, я потратил время на удаление тысяч строк старых костылей для Windows 7. Думаю, без меня поддержку Windows 7 дропнули бы ещё раньше, так как этим больше никто не хотел заниматься.
Ирония в том, что даже ошибку "Для работы программы требуется Windows 10 и новее" тоже умудрились недавно сломать, и я это вот прям вчера чинил. Даже вывод сообщения о том, что Windows 7 не поддерживается, приходится поддерживать на Windows 7 =) Ну то есть, пока мы хотим выводить внятную ошибку на Windows 7, нельзя, например, напрямую импортировать функции, которые появились только в Windows 10. Но со временем и это станет не нужно.
У меня всё ещё есть компьютер с Windows 7, но теперь он больше для ретро-целей. Старой ОС — старые программы и игры =)