нюанс в том, что в большинстве проектов где-нибудь что-нибудь да написано криво, где-нибудь спрятано использование недокументированных фич
Но почему я не вижу этого в «большинстве проектов»? Большинство — это хотя бы больше 50%. В моей практике 90% старого ПО работает отлично без танцев, 99% с минимальными танцами, и остальное решается скальпелем.
Они сделали возможным запуск linux приложений под виндой, но не наоборот.
Windows как бы ОС этой компании, они её и развивают. Логично же. Линус Торвальдс, когда развивает Linux, не обязан попутно развивать FreeBSD, MacOS, или Windows. Не Canonical добавила поддержку Linux в Windows, а сама Microsoft. Это же логично, что каждый развивает свой продукт. Странно ожидать чего-то другого.
Вы не видите в этом монопольной практики или не хотите видеть?
Вы совсем недавно придиралсь к Microsoft что они не позволяют писать кроссплатформенный код, создавая всякие нестандартные расширения. Но когда выяснилось, что они сильно облегчили написание кроссплатформенного кода, вы тут же внезапно повысили требования до того, что хотите, чтобы Microsoft портировала Windows на Linux. Вы вообще в своём уме? Разработчики Linux/FreeBSD/MacOS не могут договориться между собой, чтобы упростить написание совместимого кода сразу под все эти ОС, которые во многом похожи. А тут совершенно непохожая Windows. Это были бы сотни миллионов долларов, выпущенные на ветер совершенно с непонятной целью, так как у такого решения очевидно совместимость будет на порядок хуже, чем у родной ОС.
это не «в linux крайне сложно с UTF-16», а «какого-то лешего в винде вместо адекватного UTF-8 склеенный соплями веер 16-битных кодировок, которые для вызовов ядра конвертируются в UTF-32».
Вы явно не в теме. Бесплатный экскурс в историю. Ядро Windows NT использует UTF-16 с самого начала и до сих пор. Когда проектировалась и разрабатывалась Windows NT (начиная с 1989), UTF-8 ещё не существовало в природе (он появился только в 1992). На тот момент UTF-16 было самым прогрессивным видением будущего, казалось что в будущем все на него перейдут, и достаточно долго это отношение к нему сохранялось, даже после появления UTF-8. Тогда он попал в Java, JavaScript, C# (и чуть не попал в PHP, планировалось в невышедшем PHP 6). Авторы UTF-8 ставили целью совместимость с ASCII как раз для того, чтобы было проще старый код адаптировать на новый лад. Но к тому времени Microsoft уже успела пойти по более сложному пути с введением UTF-16, и добавлением слоя совместимости со старыми ANSI-приложениями. Годы спустя многим стало понятно, что UTF-16 был ошибкой, и лучше было следовать по пути совместимости с ASCII, то есть UTF-8, но уже слишком поздно это менять.
Linux в этом плане повезло, так как когда понадобился Unicode, UTF-8 уже был придуман, и не пришлось так запариваться. Ну а Microsoft поплатилась за то, что одна из первых взялась поддержку Unicode. Они по сути проделали гораздо больше работы (всё пришлось писать с нуля, все API пришлось продублировать), при этом создав скорее проблему, так как весь мир в итоге так и не перешёл на UTF-16, и продолжает пользоваться в основном ASCII-совместимыми кодировками.
Я вообще вам много могу рассказать о возможных причинах несовместимости, так как я реверсил и исправлял подобные проблемы (хобби), и во всех случаях оказывалось, что был виноват крайне кривой код.
Например, рендерер DX6 для Need For Speed III начинал падать после установки более свежей версии драйвера на видеокарту (или при переходе на новую версию ОС, где сразу идёт новый драйвер). Пользователи ругали Nvidia и Microsoft. А оказалось, что игра хранила информацию о поддерживаемых драйвером форматов текстур в фиксированном массиве, при заполнении которого не проверялся выход за пределы массива. Когда поддерживаемых форматов текстур стало больше 13, игра стала падать.
Или игра измеряет частоту процессора, количество оперативной памяти, и видеопамяти, и в зависимости от этого определяет, насколько у пользователя мощный компьютер, и насколько высокую детализацию в игре надо использовать. Так вот, все три этих параметра — int32. Как только частоты процессоров перевалили за 2 гигагерца, а количество видеопамяти и оперативной памяти перевалило за 2 гигабайта, начались проблемы. Need For Speed 5 выбирает самый низкий уровень детализации для машин (выглядит отвратительно и не настраивается, нужен патч), Need For Speed III выбирает по умолчанию самые низкие настройки для всего (но это можно починить из настроек) и отказывается показывать кабину машины при виде «из машины» (но это настройками не починить, нужен патч) и т.д.
на винде знаете тоже не любой давности софт работает
Корректно написанный софт для Windows NT 3.5 или 95 и новее, который не опирается сильно на какие-то недокументированные фичи — отлично работает. У меня огромное количество древнего ПО на компьютере (считайте хобби), в редких случаях были проблемы с запуском на современных версиях ОС, и все решились танцами, чаще всего тривиальными. Самое большое потрясение было при переходе на 64-разрядную версию системы: там нет поддержки 16-разрядных приложений. Да, у меня есть маленькая кучка и 16-разрядных приложений эпохи до Windows 95. Для них держу виртуалку.
Даже на уровне драйверов, где API гораздо менее стабилен, неплохой уровень совместимости сохраняется. У меня на работе наш драйвер поддерживал все ОС начиная от Windows XP и заканчивая самой последней Windows 10 (вот буквально один бинарник на все версии ОС). Несколько месяцев назад только XP и Vista дропнули. Сравните это с Linux, где драйвер должен быть собран под конкретную версию ядра.
однако их использование не приветствуется.
Может быть в вашем мире и так, а в жизни я часто вижу такую картину: we strongly recommend that most users install Certbot through the snap.
Вместо того чтобы двигаться в направлении переносимости кода между windows и linux MS встроили WSL2 в винду, чтобы в ней можно было выполнять линуксовый код, но не наоборот.
Вот именно, что они добавили ряд вещей в Windows, чтобы упростить написание кроссплатформенного кода под Windows и под Linux. Поддержку UTF-8 в консоль завезли (вместо UTF-16, с которым крайне сложно в Linux), поддержку обычных esc-последовательностей, поддержку unix-сокетов, и т.д. Компилятор свой родной привели в гораздо более соответствующий стандартам вид, вместе с Visual Studio предлагают поставить и Clang для кроссплатформенной разработки. Даже .NET нынче самой Microsoft официально поддерживается и развивается под все популярные платформы.
нет, о совместимости как раз таки другие оси заботятся больше
Именно поэтому в этих ОС старый софт не работает. Логично.
А еще там не принято тянуть все недостающие библиотеки в установщике приложения.
Именно поэтому и придумали snap и flatpak. Логично.
как вообще проектировать стандарты для ОС компании, которая намеренно отклоняется от стандартов чтобы сохранить монополию на рынке ОС за счет обеспечения непереносимости кода?
в этом конкретном случае другим ОС ничто не помешало соответстовать стандарту
Эти другие ОС не заботятся так о совместимости. Linux/FreeBSD просто целиком со всем ПО пересобирают с новым рантаймом C. MacOS раз в 5 лет дропает поддержку всего старого ПО.
Зато на Windows я могу прямо сейчас взять бинарник бородатого Firefox (Phoenix) 0.1, и он сразу запустится. А на Linux или MacOS у вас так не выйдет. Даже собрать из исходников наверняка окажется весьма непросто, придётся очень много и долго танцевать.
А то что стандарт написали так, что где-то без серьёзных недостатков его не реализовать в полной мере, то это явно недосмотр писателей стандарта. Стандарт C обычно учитывает самые невероятные варианты использования языка, а тут недосмотрели. Могли бы прописать, что вот есть aligned_realloc и aligned_free, которые будут всегда и везде работать с тем, что было выделено через aligned_malloc, а возможность использовать realloc и free в этом случае зависит от реализации. На мой взгляд это было бы гораздо более практичной вещью, нежели формальная поддержка 9 и более битных char и подобного, с чем можно столкнуться только в каких-то невероятно специфичных условиях.
Ну вот есть стандарт, а есть реальный мир. В этом реальном мире нет красивого решения для реализации aligned_malloc в стандартной библиотеке VC++ без недостатков. В стандарте позаботились о том, что char может быть 9 бит, но не позаботились о том, что освобождение выделенной через aligned_malloc памяти при помощи free может быть неприемлемым. Мир неидеален.
В большой программе, если её писали сразу строго под Linux, даже при портировании на MacOS или FreeBSD будет масса проблем. Мне вот недавно надо было при получении UDP-пакета заглянуть какой именно IP-адрес назначения был указан в пакете (чтобы определить был ли он broadcast). И у всех ОС для этого свои нестандартные расширения. Хотя казалось бы, обычные сокеты… В любой достаточно большой программе таких примеров будет масса.
А если заранее задаваться вопросами кроссплатформенности, то и проблема с выделением и освобождением выровненной памяти на всех ОС решается достаточно просто.
мешает то, что _aligned_free не может освобождать память, выделенную через malloc.
Это не мешает писать кроссплатформенный код. Выделил память через aligned_malloc/_aligned_malloc? Значит освобождай через algined_free (который под Windows будет синонимом _aligned_free, а под POSIX будет просто free).
На C/C++ написаны такие огромные и важные системы, что в ближайшие лет 100 он точно никуда не денется. Никто не станет переписывать тот же Blink на каком-то другом языке. Слишком дорого. Проще потихонечку причёсывать сам C/C++.
Ничто не мешает для POSIX-ОС объявить aligned_realloc и aligned_free как синонимы для realloc, и free, и использовать именно эти синонимы при работе с выровненными данными, чтобы получался кроссплатформенный код.
Разработчики стандартной библиотеки VC++ могли бы сделать malloc и aligned_malloc совместимыми, но наверное их останавливает то, что тогда бы пришлось пожертвовать совместимостью с системным HeapAlloc, которая хоть и не заявлялась в документации, но какими-то разработчиками воспринималась как нечто очевидное, и какой-то софт на это наверняка полагается. Также катастрофически сломалась бы совместимость разных библиотек, использующих разные версии рантайма, где данные выделяются в одной библиотеке, а освобождаются в другой. Такой вариант использования тоже официально не поддерживается, но наверняка случается. Ну и Microsoft старается без острой надобности не ломать даже такие кривые случаи, когда код неправильный, и оно вроде как работает, но совсем по счастливому стечению обстоятельств.
Лучше бы, конечно, Microsoft добавила системный HeapAllocAligned, совместимый с HeapAlloc/HeapFree, и через лет 10 его можно было бы уже везде использовать без дополнительных танцев…
Так можно же организовать аукцион не за конкретные видеокарты поштучно, а за (грубо говоря) место в очереди. Ты просто указываешь, сколько хочешь заплатить, и видишь своё место в очереди. Можешь подвинуть своё место в очереди вперёд указав большую сумму, или подождать пока рыночная стоимость упадёт до желаемой суммы. Сумма, за которую можно «выиграть на аукционе» видеокарту прямо сегодня (то есть оказаться в начале очереди) — и есть её рыночная стоимость.
Не хочешь ждать — делаешь большую ставку и выигрываешь свою карту в этот же день. Можешь подождать — делаешь ставку поменьше и просто ждёшь, когда рыночная цена упадёт до желаемого уровня.
Ещё раз перечитайте этот ответ вам. Разжёвываю. Через 10 лет вы захотите новую видеокарту. То, насколько крутые карты будут на рынке через 10 лет, зависит в том числе и от сегодняшенго дохода Nvidia. А то что сегодя вам без разницы как там будет потом — ну так это ваши проблемы, что вы не хотите смотреть дальше вашего носа. Дешевле рынка вы всё равно карту не купите. А при прочих равных лучше, чтобы деньги шли производителю. На этом завершаю этот непродуктивный разговор.
Как раз таки это вы додумали. Перечитайте ещё раз статью. Там нет совершенно ничего про решение проблемы дефицита карт «по рекомендованной цене» в магазинах. Наоборот, он предлагает организовать аукцион, чтобы видеокарты уходили по максимально возможной цене сразу от производителя. Это по сути отказ от рекомендованной цены, которая всё равно не работает, так как она не соответствует рынку.
Для конечных потребителей это не плюс и не минус. Для них нет никакой разницы.
В долгосрочной перспективе разница есть. Рано или поздно вы захотите обновить своё железо, и желательно, чтобы к тому времени оно стало как можно производительнее. А это зависит от вложений денег в развитие, которые в свою очередь зависят от прибыли.
Не вижу проблем если сама Nvidia будет продавать карты по рыночной цене (вы называете это ценой перекупщиков). Это плюс по сравнению с текущей ситацией, так как она эти деньги может потратить на дальнейшее развитие своей продукции. Я не сторонник коммунизма. Если за продукт готовы платить в 2-3 раза больше и его всем не хватает, значит его и надо продавать в 2-3 раза дороже, чтобы не было дефицита.
Цена просто поднимется до рыночной. Плюс в том, что разница пойдёт в карман не перекупам, а Nvidia, которая сможет вложить эти деньги в дальнейшее развитие.
Поддержка нормального масштабирования лежит на ПО. Если ПО не умеет адаптироваться под разную плотность пикселей, ОС может только растянуть финальное изображение. Microsoft не может пойти на полный отказ от легаси, чтобы заставить разработчиков обновить весь свой старый GUI на новый.
Windows как бы ОС этой компании, они её и развивают. Логично же. Линус Торвальдс, когда развивает Linux, не обязан попутно развивать FreeBSD, MacOS, или Windows. Не Canonical добавила поддержку Linux в Windows, а сама Microsoft. Это же логично, что каждый развивает свой продукт. Странно ожидать чего-то другого.
Вы совсем недавно придиралсь к Microsoft что они не позволяют писать кроссплатформенный код, создавая всякие нестандартные расширения. Но когда выяснилось, что они сильно облегчили написание кроссплатформенного кода, вы тут же внезапно повысили требования до того, что хотите, чтобы Microsoft портировала Windows на Linux. Вы вообще в своём уме? Разработчики Linux/FreeBSD/MacOS не могут договориться между собой, чтобы упростить написание совместимого кода сразу под все эти ОС, которые во многом похожи. А тут совершенно непохожая Windows. Это были бы сотни миллионов долларов, выпущенные на ветер совершенно с непонятной целью, так как у такого решения очевидно совместимость будет на порядок хуже, чем у родной ОС.
Вы явно не в теме. Бесплатный экскурс в историю. Ядро Windows NT использует UTF-16 с самого начала и до сих пор. Когда проектировалась и разрабатывалась Windows NT (начиная с 1989), UTF-8 ещё не существовало в природе (он появился только в 1992). На тот момент UTF-16 было самым прогрессивным видением будущего, казалось что в будущем все на него перейдут, и достаточно долго это отношение к нему сохранялось, даже после появления UTF-8. Тогда он попал в Java, JavaScript, C# (и чуть не попал в PHP, планировалось в невышедшем PHP 6). Авторы UTF-8 ставили целью совместимость с ASCII как раз для того, чтобы было проще старый код адаптировать на новый лад. Но к тому времени Microsoft уже успела пойти по более сложному пути с введением UTF-16, и добавлением слоя совместимости со старыми ANSI-приложениями. Годы спустя многим стало понятно, что UTF-16 был ошибкой, и лучше было следовать по пути совместимости с ASCII, то есть UTF-8, но уже слишком поздно это менять.
Linux в этом плане повезло, так как когда понадобился Unicode, UTF-8 уже был придуман, и не пришлось так запариваться. Ну а Microsoft поплатилась за то, что одна из первых взялась поддержку Unicode. Они по сути проделали гораздо больше работы (всё пришлось писать с нуля, все API пришлось продублировать), при этом создав скорее проблему, так как весь мир в итоге так и не перешёл на UTF-16, и продолжает пользоваться в основном ASCII-совместимыми кодировками.
Например, рендерер DX6 для Need For Speed III начинал падать после установки более свежей версии драйвера на видеокарту (или при переходе на новую версию ОС, где сразу идёт новый драйвер). Пользователи ругали Nvidia и Microsoft. А оказалось, что игра хранила информацию о поддерживаемых драйвером форматов текстур в фиксированном массиве, при заполнении которого не проверялся выход за пределы массива. Когда поддерживаемых форматов текстур стало больше 13, игра стала падать.
Или игра измеряет частоту процессора, количество оперативной памяти, и видеопамяти, и в зависимости от этого определяет, насколько у пользователя мощный компьютер, и насколько высокую детализацию в игре надо использовать. Так вот, все три этих параметра — int32. Как только частоты процессоров перевалили за 2 гигагерца, а количество видеопамяти и оперативной памяти перевалило за 2 гигабайта, начались проблемы. Need For Speed 5 выбирает самый низкий уровень детализации для машин (выглядит отвратительно и не настраивается, нужен патч), Need For Speed III выбирает по умолчанию самые низкие настройки для всего (но это можно починить из настроек) и отказывается показывать кабину машины при виде «из машины» (но это настройками не починить, нужен патч) и т.д.
Даже на уровне драйверов, где API гораздо менее стабилен, неплохой уровень совместимости сохраняется. У меня на работе наш драйвер поддерживал все ОС начиная от Windows XP и заканчивая самой последней Windows 10 (вот буквально один бинарник на все версии ОС). Несколько месяцев назад только XP и Vista дропнули. Сравните это с Linux, где драйвер должен быть собран под конкретную версию ядра.
Может быть в вашем мире и так, а в жизни я часто вижу такую картину: we strongly recommend that most users install Certbot through the snap.
Вот именно, что они добавили ряд вещей в Windows, чтобы упростить написание кроссплатформенного кода под Windows и под Linux. Поддержку UTF-8 в консоль завезли (вместо UTF-16, с которым крайне сложно в Linux), поддержку обычных esc-последовательностей, поддержку unix-сокетов, и т.д. Компилятор свой родной привели в гораздо более соответствующий стандартам вид, вместе с Visual Studio предлагают поставить и Clang для кроссплатформенной разработки. Даже .NET нынче самой Microsoft официально поддерживается и развивается под все популярные платформы.
Именно поэтому и придумали snap и flatpak. Логично.
Как вам там в 90-х?
Зато на Windows я могу прямо сейчас взять бинарник бородатого Firefox (Phoenix) 0.1, и он сразу запустится. А на Linux или MacOS у вас так не выйдет. Даже собрать из исходников наверняка окажется весьма непросто, придётся очень много и долго танцевать.
А то что стандарт написали так, что где-то без серьёзных недостатков его не реализовать в полной мере, то это явно недосмотр писателей стандарта. Стандарт C обычно учитывает самые невероятные варианты использования языка, а тут недосмотрели. Могли бы прописать, что вот есть aligned_realloc и aligned_free, которые будут всегда и везде работать с тем, что было выделено через aligned_malloc, а возможность использовать realloc и free в этом случае зависит от реализации. На мой взгляд это было бы гораздо более практичной вещью, нежели формальная поддержка 9 и более битных char и подобного, с чем можно столкнуться только в каких-то невероятно специфичных условиях.
В большой программе, если её писали сразу строго под Linux, даже при портировании на MacOS или FreeBSD будет масса проблем. Мне вот недавно надо было при получении UDP-пакета заглянуть какой именно IP-адрес назначения был указан в пакете (чтобы определить был ли он broadcast). И у всех ОС для этого свои нестандартные расширения. Хотя казалось бы, обычные сокеты… В любой достаточно большой программе таких примеров будет масса.
А если заранее задаваться вопросами кроссплатформенности, то и проблема с выделением и освобождением выровненной памяти на всех ОС решается достаточно просто.
Разработчики стандартной библиотеки VC++ могли бы сделать malloc и aligned_malloc совместимыми, но наверное их останавливает то, что тогда бы пришлось пожертвовать совместимостью с системным HeapAlloc, которая хоть и не заявлялась в документации, но какими-то разработчиками воспринималась как нечто очевидное, и какой-то софт на это наверняка полагается. Также катастрофически сломалась бы совместимость разных библиотек, использующих разные версии рантайма, где данные выделяются в одной библиотеке, а освобождаются в другой. Такой вариант использования тоже официально не поддерживается, но наверняка случается. Ну и Microsoft старается без острой надобности не ломать даже такие кривые случаи, когда код неправильный, и оно вроде как работает, но совсем по счастливому стечению обстоятельств.
Лучше бы, конечно, Microsoft добавила системный HeapAllocAligned, совместимый с HeapAlloc/HeapFree, и через лет 10 его можно было бы уже везде использовать без дополнительных танцев…
Не хочешь ждать — делаешь большую ставку и выигрываешь свою карту в этот же день. Можешь подождать — делаешь ставку поменьше и просто ждёшь, когда рыночная цена упадёт до желаемого уровня.
А в целом на рынке дефицита нет. Если вы готовы заплатить достаточно много, перекупы найдут вам видеокарту.