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

[Majestio]

Цитата Qraizer @ 09.12.24, 14:36

Что до Win32 API, так он и разрабатывался по заказу самой IBM для использования в её OS/2, которая по итогу должна была выйти как OS/2 NT или как-то так.

Нет. Ну я "со свечкой не стоял". Но там был разрыв ни "до" и не "после". А "во время". Я просто тебе напомню еще один короткий, но скажем так, "знаменательный" стандарт того времени - Win32s. На сколько я помню, вот именно в этот момент они и ... и что ... они и РАЗОСРАЛИСЬ Впереди маячило лютое бабло.

Опять же, я рядом не стоял. Но ты сам прикинь - IBM с кучей баблищя, рядом толковые недооцененные Мелкомягкие. Они щито, по-твоему, могли чисто по-братски разойтись краями?

[D_KEY]

Цитата Qraizer @ 03.12.24, 18:36

P.S. Я тем не менее с удовольствием посмотрел бы на транслятор сигналов POSIX в C++EH хотя бы краем глаза.

Разные реализации JVM делают подобное для java. Можно там поглядеть.

Я как-то делал костыли тоже сто лет назад, но код не найду уже

[Majestio]

Qraizer, сорян, туплю!
Ты вообще о чем? Приведи плс примеры, которые мы вместе с тобой сперва будем гнобить, а потом попробуем порешать. А пока это только твой взрыв негодований.
Давай по полкам? В плане действий - ты делаешь "я сделал всё по доке посикса, а оно-говно не работает". Мы вместе все смотрим. Oke?

[D_KEY]

Цитата Qraizer @ 09.12.24, 14:36

тогда как реализации POSIX делают вид, что они совместимы с POSIX, а по факту нет

Ну так они и не сертифицированы linux официально не posix (не сертифицирован), хотя по факту большинство важные вещей использовать можно.

Добавлено 09.12.24, 15:15

Цитата Qraizer @ 09.12.24, 14:36

Мне чтобы написать полностью переносимое POSIX-приложение придётся опуститься до уровня его API образца эдак 199x-ых и лишиться всего его 30 летнего последующего развития.

Верно. Но никакой альтернативы не существует. С чем ты сравниваешь? winapi-то вообще не переносимо

Цитата Qraizer @ 09.12.24, 14:36

А чтобы воспользоваться этим развитием, оно же вкусное как-никак, я обязан буду сосредотачиваться на его частных реализациях и с головой окунуться в ад портабельности и саппорта.

Да. Я сам описал выше кейс с epoll/io_uring/kqueue/etc. vs select/poll.
Но вопрос тот же. С чем ты сравниваешь?

Цитата Qraizer @ 09.12.24, 14:36

Да-да, есть библиотеки, которые вроде бы должны это брать на себя. Вот только это самое «бы». Ад просто сменил место дислокации и теперь не в POSIX, а в этих библиотеках, потом что у них точно такая же трабля.

Ну так библиотеки (хорошие) ты просто используешь, не задумываясь об ОС. Тот же asio тому пример.
Хотя бывают специфические траблы и баги под конкретные ОС, то это всегда так в низкоуровневой кроссплатформе.

Сообщение отредактировано: D_KEY - 09.12.24, 15:16

[Majestio]

Qraizer, конечно шютка но у тебя есть возможность стать POSIX-совместимым модератором исходников. Просто пройди тест сертификации!

[Majestio]

Ну я не буду Джордано Бруно, и не открою вам секреты мироздания, но кернель спейс и юзер спейс - это всего лишь абстракции. У каждной оси есть свои, скажем так, "области ответственности" для кернеля и юзерспейса. И не для никого не секрет, что если в юзерспейсе что-то запрещено, то мы пишем дрова, и оно, волшебным образом становится/может становиться разрешено. Вывод - везде можно сделать всё!

Но как говорили многие ораторы в этой теме - важно "договориться". Для кросс-платформеров вопрос возможностей уже. Для видовс-фагов он почти 100% в своей области. Но нет ничего абсолютно нерешаемого. Цитирую DKE_Y:

Цитата D_KEY @ 09.12.24, 15:11

Ну так библиотеки (хорошие) ты просто используешь, не задумываясь об ОС. Тот же asio тому пример.

Или, например, libevent.

Другой вопрос кросс-соместимости по всем 100% возможностей разных осей А кто сказал, что вы в сказку попали?

[D_KEY]

В общем, winapi можно сравнивать с конкретным API конкретной ОС. Например, macos (которая тож posix, если что). Сравнивать же непосредственно с posix можно будет тогда, когда winapi будет использоваться разными ОС от разных производителей.

[Qraizer]

D_KEY, а чем тебе Windы не разные ОСи? Притом, что родной API для NT линейки вообще ни разу не Win32, а т.н. Native API. Сравни возможности Win32s, упомянутый Majestio костыль для 16-битных Win3xx, Win32c сиречь отменённое обозначение Win32 для Win9x, настоящее Win32 для исходно 32-битных NT до WinXP включительно и нынешнее Win32 под современные Win7/8/10/11, включая редакции для 64-битных ОСей. (Одно время MS хотела, впрочем, отказаться от процедурного API в Win8, заставив всех перейти на объектный API из .NET, но слава богу передумала пересаживать разработчиков исключительно в универсальные приложения, так что классические до сих пор в ходу и ещё долго будут в ходу.) Это всё единый API для целой кучи ОСей, слабо связанных между собой архитектурно, но по-прежнему совместимых програмно. Нормально (без читов в лице юзанья недокументированностей) писанные ещё под Win98 (а может и Win95) приложения до сих пор работают и на ...Win10, за Win11 не скажу, не юзал. Вот это – экосистема.

Добавлено 09.12.24, 19:47

Цитата Majestio @ 09.12.24, 15:04

А "во время". Я просто тебе напомню еще один короткий, но скажем так, "знаменательный" стандарт того времени - Win32s. На сколько я помню, вот именно в этот момент они и ... и что ... они и РАЗОСРАЛИСЬ

Та не. Win32s (s означает subset, кажется) не планировалась, но в итоге была выпущена для облегчения миграции разработчиков под ...хм, правильные 32-битные ОСи. И это неплохо получилось, я на Win3.1 + Win32s сидел аж до 98-го года, пока не вышла Win98SE, и у меня всё мне нужное работало. Игры под DirectX не работали, да, но тогда это не имело значения, аппаратный рендер был ещё в диковинку. Имеет ли это какое-то отношение к разрыву сотрудничества, ну... честно не знаю, но сомневаюсь.

Добавлено 09.12.24, 19:56
P.S. Решил погуглить и нашёл вот такую статью. Похожа на объективную. Краткое резюме: IBM захотела занять нишу системного ПО для своих же ПК, вытеснив т.с. с рынка Microsoft, последняя решила побороться и выиграла.

Добавлено 09.12.24, 19:59

Цитата Majestio @ 09.12.24, 15:17

Просто пройди тест сертификации!

Свят-свят. Во-первых, если б я что-то мог решать в стандартизации, я б ещё моооооожет быть и подумал , но что-то мне подсказывает с очевидным для вас итогом. Во-вторых, мне наших задач по сертификациям в РосАвиации за глаза хватает.

[D_KEY]

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

D_KEY, а чем тебе Windы не разные ОСи?

Тем, что это версии одной ОС и производства одной компании. Не смотря на разные технологии и их развитие. Это суть не меняет. У них коммерческая задача - сохранить совместимость.

Добавлено 09.12.24, 20:34

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

Это всё единый API для целой кучи ОСей, слабо связанных между собой архитектурно, но по-прежнему совместимых програмно. Нормально (без читов в лице юзанья недокументированностей) писанные ещё под Win98 (а может и Win95) приложения до сих пор работают и на ...Win10, за Win11 не скажу, не юзал. Вот это – экосистема.

Так это одна компания, конечно, она будет бороться за совместимость. Кто будет обновлять ОС, если старые программы перестанут работать?

По поводу отсутствия читов и недокументированных особеностей почитай что пишут разработчики wine. Как раз основные проблемы, что реальные приложения по факту опираются на недокументированные особенности (причем это происходит зачастую неявно, просто пишут код, тестируют и пр. под одну систему и там все работает, а как только переносим на другую реализацию winapi (wine), формально соответствующую документации, работает иначе).

Я тебя не понимаю, честно.
Вот живет одна компания, которая одна делает свою ОС. Конечно, она обеспечивает совместимость. Конечно, у нее будет более заточенное под ее применимость API.

Тут скорее нужно удивляться, почему winapi такое уродливое. Вон macos современный вообще вполне себе хорошо живет еще и с новым нормальным языком (swift), при этом сохраняя совместимость с их старым objective-С (который, кстати, совместим с Си). И там как-то симпатичнее все выглядит.
И сравни с winapi, на котором никто сейчас писать программу не станет, возьмет либы.

Сообщение отредактировано: D_KEY - 09.12.24, 21:02

[D_KEY]

Ну раз мы уже в холиварах, то наброшу.
WinAPI не способна даже определиться с тем, что является кривым HANDLE: INVALID_HANDLE_VALUE или NULL (или -1 для 16битных версий, впрочем об этом уже можно забыть). А это ведь базовая вещь, о чем тут вообще можно говорить?

Сообщение отредактировано: D_KEY - 09.12.24, 21:02

[D_KEY]

struct unique_fd
{
    explicit unique_fd(int fd = -1) noexcept
        : fd_(fd)
    {
    }
 
    unique_fd(const unique_fd &) = delete;
    unique_fd& operator=(const unique_fd &) = delete;
 
    unique_fd(unique_fd && other) noexcept
        : fd_(other.release())
    {
    }
 
    unique_ptr& operator=(unique_ptr&& other) noexcept
    {
        reset(other.release());
 
        return *this;
    }
 
    ~unique_fd()
    {
        reset(-1);
    }
 
    void reset(int fd) noexcept
    {
        if (fd_ != -1)
            ::close(fd_);
        fd_ = fd;
    }
    
    [[nodiscard]] int release() noexcept
    {
        int res = fd_;
        fd_ = -1;
        return res;
    }
 
    int get() noexcept
    {
        return fd_;
    }
 
private:
    int fd_;
};

Вот еще упражнение, написать для winapi с той же степенью применимости для объектов разного рода (файлов, сокетов, pipe, ...).

P.S. код не проверял, сильно не пинайте. Идея, надеюсь, понятна.

Сообщение отредактировано: D_KEY - 09.12.24, 21:51

[Qraizer]

D_KEY, насмешил, ага.

Цитата close(2) — Linux manual page

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes.
...
It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be reused, there are some obscure race conditions that may cause unintended side effects

Те в натуре серьёзно думаешь, что однотипное API для разнородных объектов является преимуществом? Ну, даже если натянуть сову и предположить, что это преимущество... POSIX вон не может стравиться даже с гарантиями безотказности атомарной операции для одного типа объектов. Давай уже не надо, правда. Если ты считаешь WinAPI уродским, то интересно почему. Я вот припоминаю, как ругался на то или иное, но поразмыслив всегда приходил к выводу, что это сделано намерено по вполне объективным причинам. Один из таких примеров – как раз отделение INVALID_HANDLE_VALUE от NULL в ряде применений ради обеспечения отсутствия утечек ресурсов и гарантий атомарности сложных операций во многозадачных средах. Я вот считаю POSIX спроектированным каким-то индусом без школьной информатики за плечами, и пояснил, почему. Я даже не могу элементарный контейнер из сокетов создать, потому что по факту сокеты полиморфны, а в API они тупо int. Нафик эту однотипность.

Добавлено 10.12.24, 13:47

Цитата D_KEY @ 09.12.24, 20:27

У них коммерческая задача - сохранить совместимость.

Вот это ключевая фраза, если подумать. Опенсоурс не бесплатный, у него хоть и местами нулевая стоимость получения, но ни разу не дешёвая стоимость владения. Ему выгодно выпускать кривое, чтобы зарабатывать на саппорте. Собственно это мы и видим. В этом контексте проприетарщина честнее.

Добавлено 10.12.24, 13:49

Цитата D_KEY @ 09.12.24, 20:27

По поводу отсутствия читов и недокументированных особеностей почитай что пишут разработчики wine.

Скажем так: это не проблема API. Я в своём тесте чего-то там могу сломать любой его функционал, но это не значит, что функционал плохо спроектирован.

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

[Majestio]

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

[D_KEY]

Цитата Qraizer @ 10.12.24, 13:36

D_KEY, насмешил, ага.

Цитата close(2) — Linux manual page

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel uses the buffer cache to defer writes.
...
It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be reused, there are some obscure race conditions that may cause unintended side effects

И что? Что я, как разработчик софта, тут изменю в своем коде выше? Он будет работать в большинстве случаев, когда мне будет нужно. В некоторых редких я сделаю что-то еще (Deleter добавить не проблема, сам знаешь).

А отложенная запись нужна для оптимизаций и в реальном софте хорошо себя показывает. Для случаев, когда нужно флашить на диск, ты можешь это специально делать.
За многопоточкой тоже сам следишь, это тож во многом позволяет не накручивать лишней синхронизации со стороны ОС на ровном месте.

Так будет код-то? Или просто на словах признаешь, что придется писать одинотипные обертки для каждого случая?

Цитата Qraizer @ 10.12.24, 13:36

Те в натуре серьёзно думаешь, что однотипное API для разнородных объектов является преимуществом?

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

Цитата Qraizer @ 10.12.24, 13:36

Если ты считаешь WinAPI уродским, то интересно почему.

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

Для одной компании и одной ОС - странно.

Цитата Qraizer @ 10.12.24, 13:36

Один из таких примеров – как раз отделение INVALID_HANDLE_VALUE от NULL в ряде применений ради обеспечения отсутствия утечек ресурсов и гарантий атомарности сложных операций во многозадачных средах.

Можешь подробнее рассказать? Это может быть интересным.

Цитата Qraizer @ 10.12.24, 13:36

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

По-моему, не пояснил. Плюс продолжаешь игнорировать, что он для огромного числа совершенно разных ОС.

Цитата Qraizer @ 10.12.24, 13:36

Я даже не могу элементарный контейнер из сокетов создать, потому что по факту сокеты полиморфны, а в API они тупо int.

Поясни, пожалуйста. Не понял.

Цитата Qraizer @ 10.12.24, 13:36

Вот это ключевая фраза, если подумать. Опенсоурс не бесплатный, у него хоть и местами нулевая стоимость получения, но ни разу не дешёвая стоимость владения.

При чем тут вообще opensource? Есть и закрытые posix ОС

Цитата Qraizer @ 10.12.24, 13:36

Скажем так: это не проблема API.

Это проблема наличия только одной "настоящей" реализации API.
Впрочем, это вообще не проблема.

Никто на winapi уже почти и не пишет.

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

[D_KEY]

Зато чет захотелось прям понастольгировать и какую-нибудь кроссплатформенную шляпу запилить. Может что-то на тему iocp, io_uring и пр. (ну и kqueue тож сделать и потом на сдачу posixовый select/poll), но, в отличие от asio, например, накрутить там реактивные стримы или еще чего другого придумать, чтобы оправдать существование поделки