Комментарии 6
«Месье знает толк в извращениях» :)
Я пытаюсь в свободное время GO изучать, честно говоря их инновационный подход, когда начинают стран вещи переделывать (как например работу с внешними зависимостями) слегка напрягает.
Вроде можно же было все нормально с самого начала сделать. Но хотели как лучше а получилось как всегда.
И как тут на язык закладываться когда у него с обратной портированность проблемы. Есть конечно вариант - Linux :), но некоторые товарищи упорствуют и продолжают на старых версиях Windows сидеть
Это самая шизоидная картинка которую я видел.
Кстати, все эти выпиливания Windows 7 выглядят как будто намеренные, даже можно заговор при желании углядеть, как будто её специально пытаются выпилить отовсюду )
И что самое интересное — это делают все кто угодно, но не сам Microsoft, ибо МС до сих пор даже не випилила «семёрку» из последнего SDK для Windows 11
Особенно отметился именно Google, который одним из первых исключил Win 7 в Chromium, попутно поломав ещё и весь софт на Electron и на всевозможных cromium embeded..
Ту же замену SystemFunction036 в обсуждении Go, мотивировали якобы тем, что он deprecated и не документирован, хотя сам Microsoft до сих пор использует его внутри вызовов rand() в ucrt, и внутри RtlGenRandom, и явно не собирается исключать их из API в обозримом будущем.
Да даже если и deprecated, сам же Microsoft вместо RtlGenRandom рекомендует использовать CryptGenRandom, который есть даже в XP, но в "go" почему-то сидели все эти годы и ждали — когда же уже можно наконец-то одним коммитом убить ОС заменив на вызов ProcessPrng, который практически ничего существенного-то и не меняет, но ломает кучу зависимого от Go софта.
А софта там очень много: всевозможные vpn либы: wireshark, tun2socks... написаны на go, и весь vpn-софт сейчас практически перестал работать на Windows 7.
Касаемо «console handle»: именно так же буквально недавно сломали vcpkg — тоже пришлось патчить.
Там стандартные консольные STDOUT и STDIN автоматически наследуются при передаче в CreateProcess и имеют тип FILE_TYPE_CHAR и нужды заполнять PROC_THREAD_ATTRIBUTE_HANDLE_LIST как бы вообще нет.
В семёрке CreateProcess на такой тип хендлов в PROC_THREAD_ATTRIBUTE_HANDLE_LIST просто выбрасывал ошибку, и нужно проверять тип на != FILE_TYPE_CHAR
Аналогичная история с rust, несущественными функциями сломали поддержку всего зависимого софта..
Я понимаю, что поддерживать зоопарк тяжело, но это же нужно было найти время, найти в коде всё что касается «семёрки», сломать реально же работающий во всех существующих версиях код, заменить один вызов API другим, хотя старый продолжал бы наверняка ещё работать долгое время..
Вместо этого можно было потратить час на подобное добавление всего каких-то пары строк, меняющих вызов в рантайме, если уж так приспичило использовать новое API, и не сломав при этом кучу зависимого софта.
Кстати, все эти выпиливания Windows 7 выглядят как будто намеренные, даже можно заговор при желании углядеть, как будто её специально пытаются выпилить отовсюду )
Как ни странно да, в стороннем софте удаление поддержки Windows 7 выглядит именно так. И разумного ответа у меня нет.
Что касается самих MS то они поступают разумно и за отдельный прайс готовы поддерживать хоть Windows 95, только плати.
Насколько я помню, началось всё с того, что сам майкрософт начал выдвигать какие-то условия производителям железа — типа, что нельзя выпускать драйвера под семёрку для новых устройств, иначе не разрешим писать "made for Windows" на упаковке (будто кому-то есть дело до этого, ей богу). А то ишь чего, совсем офигели тут, продолжать пользоваться последней версией винды, которая уважает пользователя и не портит интерфейс поддержкой сенсорных экранов.
Бобер который смог: бекпорт Golang на Windows 7