WinAPI и POSIX , бой насмерть

[Qraizer]

Цитата Majestio @ 10.12.24, 14:47

Ты просто пойми, что линупсы и их апдейты растут как грибы - и гораздо чаще твоей сраной венды апдейтяться! И самое главное, а ни не просто растут - а выставляют стабильные и LTS ветки.

Ну так я и назвал это зоопарком. Ты пытаешься этим оправдать для себя несовместимость их API? Ну так вспомни, что я вот буквально только что писал про стандартизацию Языка. Оказывается, так можно.
А венда обновляется чаше, чем тебе кажется. Дважды в год. LTS на этом фоне выглядят как-то скромненько.

Добавлено 10.12.24, 19:56

Цитата D_KEY @ 10.12.24, 16:27

Что я, как разработчик софта, тут изменю в своем коде выше?

Ничего. Смиришься с потенциальными багами раз в полгода в сервисах 24/7? Флаг в руки. Знаешь, если атомарная операция не гарантирует атомарности... ну это ж POSIX же, чё. В WinAPI никогда новый HANDLE не будет выдан, если он полностью не вышел из использования. А вот в POSIX мультипотоковое ПО, оказывается, должно само об этом заботиться. Ну весело же.

Цитата D_KEY @ 10.12.24, 16:27

Так будет код-то?

А тебе мало было, что ли? Чай не первый холивар-то.

Цитата D_KEY @ 10.12.24, 16:27

Зоопарк разнородных подходов (пример привел выше с handle), функции с миллионом параметров, монструозные структуры данных и т.д. и т.п.

Пример с INVALIDE_HANDLE_VALUE чётко следует (внезапно) POSIXовой же традиции при ошибках возвращать -1, потому что бинарно с ним совместим, а бинарно совместимый с нулём NULL является вполне себе корректным stdin. В совокупности это нивелирует проблемы совместимости с криво писаным легаси, которые в 90-ых были весьма значимы. Нынче это не проблема, однако совместимость документированных интерфейсов ОСей требует. Ну и странно видеть наезд на WinAPI там, где она унаследовала архитектуру POSIX.
Функции с миллионом параметров 100500 дадут вперёд одному структурному параметру с миллионом полей в плане защиты от человеческого фактора. Параметр ты не пропустишь, инициализацию поля же легко. Особо важные параметры, которые если поменять местами, могут поломать поведение кода из-за незамеченной ядром ошибки их порядка в аргументах, не пройдут компиляцию из-за несовместимых типов. Это вам не int на все случаи жизни. А за монструозные структуры вообще странно в контексте негатива в адрес миллиона параметров. Я вот счас ещё вспомню про версии API, которые в WinAPI определяются элементарно sizeof() в первом поле, а в POSIX как (c_legacy_cast)какой_то_поинтер_на_мамой_клянусь_правильную_структуру. Ой, вспомнил.

Сообщение отредактировано: Qraizer - 10.12.24, 19:59

[D_KEY]

Цитата Qraizer @ 10.12.24, 19:39

Смиришься с потенциальными багами раз в полгода в сервисах 24/7? Флаг в руки.

Писал в течение некольких лет, все было в порядке. Явно надежнее сервисов под windows, кстати. Хотя там сама ОС чудила чаще

Добавлено 10.12.24, 20:26

Цитата Qraizer @ 10.12.24, 19:39

Ну весело же.

Нормально
Поверь мне, это будет последнее из-за чего упадет твой сервис

Цитата Qraizer @ 10.12.24, 19:39

Пример с INVALIDE_HANDLE_VALUE чётко следует (внезапно) POSIXовой же традиции при ошибках возвращать -1, потому что бинарно с ним совместим, а бинарно совместимый с нулём NULL является вполне себе корректным stdin.

При чем тут это? У тебя один и тот же тип объектов, возвращенный разными функциями, при ошибке то будет равен одному значению, то другому, в зависимости от конкретной функции. Постоянно нужно сверятся с документацией конкретной функции. Это просто странно.

Цитата Qraizer @ 10.12.24, 19:39

Ну и странно видеть наезд на WinAPI там, где она унаследовала архитектуру POSIX.

У POSIX всегда будет -1. А для указателей всегда будет NULL (если одна единственная функция, которая действует не так из-за легаси, но ее очень редко используют - sbrk).

Цитата Qraizer @ 10.12.24, 19:39

Функции с миллионом параметров 100500 дадут вперёд одному структурному параметру с миллионом полей в плане защиты от человеческого фактора.

Не согласен. С объектами гораздо легче работать, чем с параметрами функций. Их удобо отдельно валидировать, сохранять, модифицировать и т.д.
Писать обертки для C++ так же удобнее.

Цитата Qraizer @ 10.12.24, 19:39

Параметр ты не пропустишь, инициализацию поля же легко.

Да брось ты, зачастую люди просто заглушки туда ставят, погуглив две минуты. Потому что это ад с таким работать.

Ну и вообще функции с миллионом параметров в принципе означают плохой дизайн. Классика же, "If you have a procedure with 10 parameters, you probably missed some"

Добавлено 10.12.24, 20:35
А вообще, еще раз, странно сравнивать. Оба API уродливы, каждый по своему (мне posix нравится больше winapi, но он все равно кривой). При этом POSIX касается большого числа совершенно разных ОС, от совершенно разных производителей и для разных задач. Соответственно, кривость хоть как-то можно оправдать. В случае winapi, который является поделкой одной единственной компании, наличие косяков выглядит более странным.

Добавлено 10.12.24, 20:40
Хм. Возможно, вы упускаете, что сначала распладилось куча unix-подобных ОС, с несколько разными API. А потом только появился POSIX, как попытка это все привести в порядок.
Не было такого, что сначала кто-то придумал стандарт, а остальные начали его реализовывать, делая с нуля свои ОС.

Сообщение отредактировано: D_KEY - 10.12.24, 20:40

[Qraizer]

Цитата D_KEY @ 10.12.24, 20:16

Явно надежнее сервисов под windows, кстати.

Ой ли. У тебя какое-то странное мнение о сервисах. У меня вот аптаймы ОСей в стендовой почти по два года, с момента их переезда с нашего этажа. Четыре штуки. Они от инета отключены, поэтому обновлений на них не прилетает, ребутать нет причин. Свет вырубался, но они под UPSами и хибернетом. Да, мои апликухи там тоже есть. Не оформлены сервисами, но по факту они самые. (Одну из них ты даже должен помнить, архитектуру я малёхо описывал в теме про объекты синхронизации.) С аптаймом поменьше, потому как они изредка апдейтятся под меняющиеся ТЗ на них.
Ты вероятно просто не сталкивался с серьёзным тестированием, D_KEY. Я легко могу поверить и пруфов не потребую, что у тебя там всё хорошо. Потому что вот конкретно твоё окружение не имеет проблем. Вот только когда речь заходит за высококритичное ПО, во главу угла ставится документация, а не испытания. И коли там сказано, что вот так оно могёт быть, твоё ПО не пройдёт аудит, если ты не предусмотришь у себя обработку сего. И пофик, что структурное покрытие его никогда не покроет. Будет написан модульный тест, имитирующий оговоренный отказ. Готовить своё приложение для такого случая придётся. Каждое приложение для каждого подобного случая. Можешь сам зайти на маны, почитать и посчитать ноуты под каждой функцией и прикинуть объём "никому не нужной" работы.
P.S. Библиотеки не спасут вообще ни разу. Только хуже сделают, т.к. для них тоже будет аудит. Я как-то уже упоминал, что флай-код в авионике отключает стандартные библиотеки и в лучшем случае пилит их аналоги, обычно сильно упрощённые. Так их хоть как-то можно сертифицировать за разумные деньги. А уж за third party и говорить нечего.

Цитата D_KEY @ 10.12.24, 20:16

Хм. Возможно, вы упускаете, что сначала распладилось куча unix-подобных ОС, с несколько разными API. А потом только появился POSIX, как попытка это все привести в порядок.

Возможно. Но ведь появление POSIX ставило своею целью унификацию, разве нет? Но что-то пошло не так.

Сообщение отредактировано: Qraizer - 11.12.24, 14:34

[D_KEY]

Цитата Qraizer @ 11.12.24, 14:31

Ой ли. У тебя какое-то странное мнение о сервисах. У меня вот аптаймы ОСей в стендовой почти по два года

Ну стендовая это не считается
На моем опыте аптайм на линуксах был всегда очень хороший на реальных серваках. И был всегда такой себе на windows. Но может там админы плохие были у нас, не знаю

Добавлено 11.12.24, 14:49

Цитата Qraizer @ 11.12.24, 14:31

Ты вероятно просто не сталкивался с серьёзным тестированием, D_KEY.

В моей команде или в компании всегда были специалисты сильнее меня в этих вопросах. Вообще у нас были сервисы и с 99.9999% надежностью. И большая часть с 99.999%. Да и багов было немного.
Впрочем, это зависило от компании. Сейчас у меня другая история немного.

Добавлено 11.12.24, 14:53

Цитата Qraizer @ 11.12.24, 14:31

Но ведь появление POSIX ставило своею целью унификацию, разве нет? Но что-то пошло не так.

Еще раз, по сравнению с чем? У кого-то получилось лучше? Я не вижу

Сообщение отредактировано: D_KEY - 11.12.24, 14:57

[Majestio]

Цитата D_KEY @ 11.12.24, 14:46

Еще раз, по сравнению с чем? У кого-то получилось лучше? Я не вижу

Наброшу и плюсую Законный вопрос: а есть какойта более другой способ стандартизации и унификации программных вызовов в сериях независимых осей, кроме как POSIX?

[Qraizer]

Цитата D_KEY @ 11.12.24, 14:46

Ну стендовая это не считается
На моем опыте аптайм на линуксах был всегда очень хороший на реальных серваках. И был всегда такой себе на windows. Но может там админы плохие были у нас, не знаю

Почему это не считается? Там полноценная ОСь, без отключений чего-либо и кастраций, даже Защитник работает. Файрволл, правда, отключён. Или ты имеешь в виду рабочие нагрузки? Ты ж их даже не спросил.
У меня такое впечатление, что ты неправильно употребляешь термин "сервис". Стандартные сервисы из ОСи вполне себе надёжны, аптайм как бы вот он. Самописные... ну по реализации они не сервисы, но по факту они самые, т.к. работают те же 24/7. Может быть у вас там с виндой не всё гладко просто потому, что спецы по сервисам не такие уж и спецы? Это не наезд ни в коем случае, создание сервисов не вполне то же самое, что обычных приложений. Я вот по демонам никакой, не приходилось за ненадобностью.
А так-то в целом... не думаю, что открою большой секрет: все процессы разработки и верификации флай-кода ориентированы на винду. POSIX встречается крайне, реально крайне, вот прям очень крайне редко. Как исполнительная платформа для эмбеддед – бывает, но там обычно форкают, кастрируют скорее даже режут по живому, оставляя только потенциально требуемый минимум функционала. Мы как-то занимались верификацией RTEMS для одного из заказчиков, отправленное количество Сообщений о Проблемах я не припомню, но на каждый модуль (архитектурный) десяток в среднем набирался. Где-то больше, где-то меньше. Та ёлки, там баги даже в системных заголовках были, явно расходились с даташитами к PPC. И это притом, что RTEMS на MPC5200 вполне себе официально портирована и довольно давно.

Добавлено 13.12.24, 16:30
Majestio, я знаю только один пример: ARINC-653. Очень жёсткий и строгий. Но это не совсем то, что ты имел в виду, похоже.

Сообщение отредактировано: Qraizer - 13.12.24, 16:33

[macomics]

Как же хорошо на asm x86. Просто возвращаешь CF как идентификатор ошибки, если нужно и не придумываешь костыли типа std::expected

[Majestio]

Цитата Qraizer @ 13.12.24, 16:26

Majestio, я знаю только один пример: ARINC-653. Очень жёсткий и строгий. Но это не совсем то, что ты имел в виду, похоже.

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения. Но, тут соглашусь, не слышал - но варик достойный! Ибо решает вопросы не все, но в своей теме. Тут уважуха!

[Qraizer]

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

Угу. С конкретно Wind River я сталкивался, работать с ней сложно и неудобно, зато всё безопасно и уже сертифицировано до нас. Причём это вполне себе полноценная ОСь, в ней даже слой OpenGL есть. Но и стоят такие ОСи баснословно. Гораздо чаще выходит дешевле написать свою realtime ОСь на коленке, полностью её оттестировать модульными (а как иначе, если это тупо набор .o собранных в набор либ) со 100% покрытием, предоставить отчёты по WCET и WCSU, разработать и предоставить наборы сценариев для квалификационных её испытаний в составе будущего прикладного ПО под неё и сертифицировать в таком виде.

Добавлено 13.12.24, 17:21
macomics, с ассеблерами плохо даже не то, что они все разные, а то, что конкретное ABI соблюдать придётся руками. Ну или как вариант писать на ассемблере всё, тогда на ABI можно забить, конечно. В частности в ABI для x86/64 через CF ты ничего не передашь, разве что между собственно обоими ассемблерными функциями

Сообщение отредактировано: Qraizer - 13.12.24, 17:21

[macomics]

Цитата Qraizer @ 13.12.24, 17:16

macomics, с ассеблерами плохо даже не то, что они все разные, а то, что конкретное ABI соблюдать придётся руками. Ну или как вариант писать на ассемблере всё, тогда на ABI можно забить, конечно. В частности в ABI для x86/64 через CF ты ничего не передашь, разве что между собственно обоими ассемблерными функциями

Да я про DOS API вспомнил, пока вы тут про WinAPI и POSIX рассуждаете

[D_KEY]

Цитата Qraizer @ 13.12.24, 16:26

Почему это не считается?

Потому что не продакшн окружение, не продакшн нагрузки и не продакшн поведение запросов.

Впрочем, ты прав, возможно что у вас супер стенды со всем вышеперечисленным и имитацией реальных запросов с реальными данными, реальной частотой и пр.

Добавлено 13.12.24, 23:50

Цитата Qraizer @ 13.12.24, 16:26

У меня такое впечатление, что ты неправильно употребляешь термин "сервис". Стандартные сервисы из ОСи вполне себе надёжны, аптайм как бы вот он. Самописные... ну по реализации они не сервисы, но по факту они самые, т.к. работают те же 24/7.

Ну термины нельзя использовать правильно или неправильно. О терминах договариваются.

Но я действительно неточно выразился. Имел в виду аптайм именно самих серверов, сервисы оставались доступны вовне за счёт масштабирования, а если ты имеешь в виду сервисы/демоны на конкретной машине, то случались баги, конечно, но я тебе про то, что у нас сами машины перезагружали или ещё что-то с ними делали - хз. Я это видел только в zabbix, в основном.

Добавлено 13.12.24, 23:52

Цитата Qraizer @ 13.12.24, 16:26

А так-то в целом... не думаю, что открою большой секрет: все процессы разработки и верификации флай-кода ориентированы на винду. POSIX встречается крайне, реально крайне, вот прям очень крайне редко.

Не знаю, о чем ты, но серваки в основном на linux'ах по всему миру. Не помню точно статистику, но под 90%. А у топовых компаний процент ещё выше.

Добавлено 14.12.24, 00:04

Цитата macomics @ 13.12.24, 16:37

Как же хорошо на asm x86. Просто возвращаешь CF как идентификатор ошибки, если нужно и не придумываешь костыли типа std::expected

И что ты предлагаешь? Писать софт на asm x86 из-за этого?
И в чем костыльность std:: expected?

Добавлено 14.12.24, 00:06

Цитата Qraizer @ 13.12.24, 17:16

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

Угу. С конкретно Wind River я сталкивался, работать с ней сложно и неудобно, зато всё безопасно и уже сертифицировано до нас.

А разве это не linux?

Добавлено 14.12.24, 00:07

Цитата macomics @ 13.12.24, 18:13

Да я про DOS API вспомнил, пока вы тут про WinAPI и POSIX рассуждаете

Пишешь под DOS?

Сообщение отредактировано: D_KEY - 14.12.24, 00:38

[D_KEY]

Цитата D_KEY @ 13.12.24, 23:42

Цитата Qraizer @ 13.12.24, 17:16

Цитата Majestio @ 13.12.24, 16:42

Похоже это "перпендикулярный" стандарт, который отталкивается не от Оси, а от прикладного применения.

Угу. С конкретно Wind River я сталкивался, работать с ней сложно и неудобно, зато всё безопасно и уже сертифицировано до нас.

А разве это не linux?

Или ты имеешь в виду VxWorks? А она разве POSIX не поддерживает?

[Majestio]

Цитата D_KEY @ 14.12.24, 09:15

А она разве POSIX не поддерживает?

Вполне себе поддерживает.

Но гугление немного прояснило суть последних тем. POSIX - это считают стандартом, а ARINC-653 - это спецификация, стандартизующая определенный интерфейс(ы). Таким образом, POSIX - предназначен для обеспечения переносимости и повторного использования кода. Тогда как ARINC-653 предназначена для обеспечения пространственной и временной разделяемости в критически важных авионических системах реального времени. И не только в авионических, в любых RTOS системах, где безопасность и надежность являются критически важными. Сюда можно отнести и космонавтику, и военные системы. Таким образом наблюдается "перпендикулярность" Ибо они решают совсем разные проблемы проектирования.

[macomics]

Цитата D_KEY @ 13.12.24, 23:42

Пишешь под DOS?

Освежите у себя в памяти DOS API. Там было простое и элегантное решение по определению ошибок. Просто в ответ по мимо ax возвращался еще и cf. cf=0, то ax=результат. cf=1, тогда в ax=код ошибки. И не надо городить огороды со структурами, типизицией итд итп.

[D_KEY]

Цитата Majestio @ 14.12.24, 09:58

Цитата D_KEY @ 14.12.24, 09:15

А она разве POSIX не поддерживает?

Вполне себе поддерживает.

А WinAPI?

Добавлено 14.12.24, 10:56

Цитата macomics @ 14.12.24, 10:51

Просто в ответ по мимо ax возвращался еще и cf. cf=0, то ax=результат. cf=1, тогда в ax=код ошибки. И не надо городить огороды со структурами, типизицией итд итп.

Чем это лучше-то?