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

Цитата scrambrella @ 19.04.21, 16:01

1) Страуструп - чисто по С++
2) Фреймворк QT 5
3) Кнут. Искусство программирования. - по всем остальным вопросам

А Лафоре норм?

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

Цитата Alexandrietz @ 24.04.21, 13:55

А Лафоре норм?

Это кто?

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

Цитата scrambrella @ 26.04.21, 07:23

Цитата Alexandrietz @ 24.04.21, 13:55

А Лафоре норм?

Это кто?

Книга по С++ от Роберта Лафоре. У него еще вроде по Питону есть. Есть еще Шильдт, Липманн, Страуступ(но для нуба она тяжелая)

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

Цитата shm @ 23.04.21, 12:40

Что есть "с приоритетом у писателей"? Эта фраза мне мало о чем говорит. И в чем практический смысл такого приоритета?

В том, что перед записью нужно захватить ресурс монопольно, и следовательно читатели должны его держать, когда они есть, и отпускать, когда ни один из них не держит ресурс, но и не блокировать друг друга, ибо в этом нет надобности, они его не меняют. В другом крайнем случае, когда на одного писателя будет 100500 читателей, без приоритетности он чёрта с два дождётся обнуления их активного количества. Серьёзно? Мне пришлось это написать?
С одним писателем достаточно двух объектов синхронизации и по одному API-вызову на входе/выходе в/из КС со стороны читателей и по два для писателя. В ситуации с несколькими писателями дело усложняется.

Цитата shm @ 23.04.21, 12:40

Собственно, эффективную (без пробуждения всех читателей при записи) и простую (сопоставимую по сложности с CV) реализацию писателей-читателей (можно без приоритетов) на евентах я бы тоже хотел увидеть.

Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.

Цитата shm @ 23.04.21, 12:40

А какие с CV дедлоки? Там есть ложные пробуждения, но это не так страшно, как обратная ситуация с Event'ами.

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

Цитата shm @ 23.04.21, 12:40

И cv в подавляющем большинстве случаев хватает одной, чего не скажешь о event'а.

И это абсолютно неважно, когда речь идёт о скорости и стоимости выхода в стадию продакнша.

Цитата shm @ 23.04.21, 12:40

Она нифига не атомарная на SMP системах, о чем у них и написано в документации.

Она выполняется ровно так, как описано. Пробуждение другой нити перед вызвавшей SignalObjectAndWait() суть нормальное явление, ибо для объектов синхронизации все ожидающие нитки равноправны. Такова их архитектура. Ничего не поменялось бы, если б сигнализирующий объект переводился бы в сигнальное состояние после того, как вызывающая SignalObjectAndWait() нитка реально вошла б режим ожидания. Всё равно при наличии нескольких ожидающий проснуться может любая, и решает это планировшик потоков. То, что написано в документации как предупреждение, суть просто напоминание, фактически ему там делать нечего, просто Note для забывчивых. Я ж говорю, мат.часть надо знать.
Смак SignalObjectAndWait() в том, что она гарантирует перевод вызвавшей её нитки в ожидающее состояние перед тем, как она отсигналит сигнализирующим объектом. Ты просто не сможешь простым путём это сделать никак иначе.

Цитата shm @ 23.04.21, 12:40

Скольким разработчикам этот функционал нужен? 0.1% наберется?

Всем, кто пишет сервисы. Таковых много? Я не знаю. Но без этого функционала они связаны по рукам и ногам.
Просто посмотри, например, на такую ситуацию: ты пишешь код обновления своего ПО, которое может эксплуатироваться одновременно под разными учётками в терминальных сессиях или даже просто под fast user switch, и тебе нужно сделать это правильно, т.е. выгрузив все свои экземпляры и после обновления загрузить снова, не потеряв при этом данных пользователей, которые вот прям счас с твоим ПО активно работают, а главное – не быть уязвимым к злонамеренным атакам, посредством фэйковых служебных пакетов саботирующих работу твоего ПО. Конечно, это вполне себе решается и в POSIX, но насколько это проще, безопаснее и быстрее решается в WinAPI, лично я могу сравнивать. Там тебе всё готовое уже. Даже журналирование стандартизировано, что легко автоматизирует множество административных задач, на которых уже построена значительная часть корпоративной инфраструктуры твоей компании, и встроить туда ещё один объект аудита занимает пару минут. На рубеже прошлых десятилетий мне пришлось плотно окунуться в сферу сервисов и security API. Если заглянешь в раздел WinAPI у нас, то я отметился, пожалуй, в каждой теме по сервисам. Правда, о security вопросов там, вроде бы, не было.

Цитата shm @ 23.04.21, 12:40

У POSIX можно открыть исходники и понять как оно реализовано, что ни скажешь о API MS.

Этот аргумент не просто ни разу не аргумент, а никогда им и не был. Прикинь, когда — не дай бог – падает самолёт, комиссии смотрят код в последнюю очередь и в очень малом проценте инцидентов. Почему? Потому что это не требуется. Вся инфа берётся из документации и логов. А этого в свою очередь достаточно, потому что там исчерпывающая документация. Если бы это было не так, в комиссиях должны были бы состоять исключительно программисты, но среди них крайне мало конструкторов, схемотехников, специалистов по физике атмосферы, прочнистов итд итп и др.
Для сравнения могу предложить такую задачку. В Холиварах никто не захотел задуматься, предлагаю задуматься тут. Чтоб не отправлять по ссылке, сцитачу сюда:

Цитата Qraizer @ 14.04.21, 11:11

В документации сказано: «функция void sort(int *vec, size_t size) должна выполнять сортировку массива vec, размером size. Сортировка осуществляется по возрастанию, результат замещает исходный vec.» Требуется разработать набор тестовых сценариев для проверки этого требования. Естественно так, чтобы их можно было рассматривать как доказательную базу корректности реализации sort() согласно описанию её поведения.

Поначалу может показаться, что это некая ересь, как можно что-то тестировать глубже, чем интуитивно потыкать по кнопкам, не зная, как оно устроено, а тут аж доказательную базу хотят. Но немного подумав, внезапно окажется, что алгоритм и сырцы для этого без надобности от слова совсем. Мы знаем, как должна вести себя эта функция. Мы можем однозначно определить, каким должен быть её результат по абсолютно любому набору входов. Что ещё надо-то? Качество документации — вот главный пасс-критерий качества кода, и его реально достаточно.
Это, конечно, простой пример, потому что мы все прекрасно знаем, что такое сортировка, но а чем качественно-то отличается любая другая функция от этой? Риторический вопрос. В общем, забудьте и больше никогда не вспоминайте о тезисе, что открытый код якобы надёжней, потому что в него всегда можно заглянуть. Это миф.

Цитата shm @ 23.04.21, 12:40

Да причем тут гибкость? Адекватно вообще пихать столько аргументов в одну функцию?

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

Цитата shm @ 23.04.21, 12:40

ЗЫ: я раньше тоже был сторонником WinApi. Пока серьезно не занялся осдевом (как хобби) и не понял внутренне устройство ОС. После этого мои взгляды резко изменились.

Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.

Добавлено 30.04.21, 22:12

Цитата shm @ 23.04.21, 13:02

И кстати, если модель синхронизации винды так прекрасна, то почему те же евенты не добавили в c++? Только не надо говорить, что "потому что их нет в ядре nix": там они тривиально реализуются на фьютексах. А причина, насколько я знаю, в том, что в комитете справедливо решили, что Event'ы очень часто порождают весьма не очевидные баги в синхронизации

Нет, в Комитете решили, что на этот момент существует уже слишком много доСтандартных решений, и так будет гораздо проще рефакторить много легаси. А почему их много, думаю, объяснять не надо: проще было с...лямзить готовый и открытый pthread, чем писать и отлаживать свои самокаты.

Добавлено 30.04.21, 22:32

Цитата scrambrella @ 23.04.21, 13:50

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

Пробежаться в цикле тебе и без QVector::fill() было бы несложно, согласись, но коли речь зашла за сервисные функции и методы, то речь идёт об обобщённой задаче, ибо на каждую хотелку методов не напасёшься. Например

std::replace_if(db.begin(), db.end(), [](auto i) { return i % 7 == 4; }, 0);

зануляет все, которые при делении на 7 дают в остатке 4. При этом db может быть чем угодно, лишь бы поддерживало модель контейнер+итераторы, и предикат пиши сам, какой нужен. А ещё первым параметром можно указать политику параллельного исполнения, типа там std::execution::parallel_policy, и если в твоей библиотеке оно реализовано, то ок. Ну, не реализовано, ну и ладно, а у кого-то реализовано, и этот код получит профит. Наверно, получит профит... слишком простая задача. Но ведь и гораздо сложнее бывают.

Цитата scrambrella @ 23.04.21, 13:50

А если по-русски?

Эм... забей. Слишком много писать объяснений для того, на что ответ я и так представляю.

Добавлено 30.04.21, 22:44

Цитата shm @ 23.04.21, 16:26

С другой стороны, если говорить WaitForMutlipleObject, то вещь это специфическая и для приложений с большой нагрузкой ввода-вывода малополезная (прежде всего сервера): там используются те же очереди на IOCP/epoll. Почему? Все просто: эта функция ограничена 64 объектами ожидания на поток (причем преодолеть это ограничение технически MS не может и на то есть объективные причины), что ставит крест на масштабируемости. Поэтому область ее применения все же не высоконагруженные приложения, где не так много объектов за которыми нужно следить, а в этом случае сложно увидеть разницу в производительности по сравнению с той же реализация на CV (ну проснутся потоки лишний раз и опять уснут, катастрофы нет).

Так её и не используют на высоких нагрузках. Так-то для этого уже мульён лет другие объекты синхронизации предназначены. А вот для чего пользуют (просто пример! пользовать в своих проектах не более чем как демонстрацию концепции):

HANDLE evAllowReaders = CreateEvent(NULL, TRUE, TRUE, NULL);
HANDLE mtExclusived   = CreateMutex(NULL, FALSE, NULL);
HANDLE rdLock[] = { evAllowReaders, mtExclusived };
 
// читатели
WaitForMultipleObjects(2, rdLock, TRUE, INFINITE);
/* бла-бла-бла */
ReleaseMutex(mtExclusived);
 
// писатель
ResetEvent(evAllowReaders);
WaitForSingleObject(mtExclusived);
/* бла-бла-бла */
SetEvent(evAllowReaders);
ReleaseMutex(mtExclusived);

Добавлено 30.04.21, 22:47

Цитата OpenGL @ 23.04.21, 19:26

Вот только почему-то такая штука как docker в лине есть нативно с его стрёмной системой прав, в винде же он надстройка над hyper-v. Без виртуализации, видимо, никак не сделать в столь гибкой системе.

А причём тут права?

Добавлено 30.04.21, 22:50

Цитата ЫукпШ @ 23.04.21, 20:27

Недавно в некотором проекте мне захотелось, чтобы вывод был не только в консоль,
а куда я захочу (или никуда) Тогда я написал класс MyCout. И реализовал
только те возможности, которые мне были необходимы. Только теперь этот класс
писал не в консоль, а в интерфейс.

А зачем было себя ограничивать в интерфейсе, если можно просто написать потомка std::basic_streambuf<> и перекрыть несколько виртуальных методов? И пиши себе стандартными классами хоть в сокеты, хоть в COM:, куда там ты напрограмишь в методах.

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

Сообщение отредактировано: Qraizer - 01.05.21, 22:37

Цитата Qraizer @ 30.04.21, 22:08

но и не блокировать друг друга, ибо в этом нет надобности, они его не меняют

Как не меняют-то? Типа извлечение элемента из очереди это "не меняют"?

Цитата Qraizer @ 30.04.21, 22:08

В другом крайнем случае, когда на одного писателя будет 100500 читателей, без приоритетности он чёрта с два дождётся обнуления их активного количества.

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

Цитата Qraizer @ 30.04.21, 22:08

Пф. Событие с автосбросом. Единственное изменение во всей процедуре – один флажок в одном из API-вызовов.

Да вот нифига. Сами мелкомягкие не дают адекватного решения на событиях с автосбросом. И призывают использовать iocp, или, внезапно, cv Пруф, разумеется, будет.

Цитата Qraizer @ 30.04.21, 22:08

Такие, что ты сам их пишешь и сам же управляешь потоками событий по ним.

Не понял аргумента вообще.

Цитата Qraizer @ 30.04.21, 22:08

Смак SignalObjectAndWait() в том, что она гарантирует перевод вызвавшей её нитки в ожидающее состояние перед тем, как она отсигналит сигнализирующим объектом. Ты просто не сможешь простым путём это сделать никак иначе.

Это понятно, но...

Цитата

Use extreme caution when using SignalObjectAndWait and PulseEvent with Windows 7, since using these APIs among multiple threads can cause an application to deadlock. Threads that are signaled by SignalObjectAndWait call PulseEvent to signal the waiting object of the SignalObjectAndWait call. In some circumstances, the caller of SignalObjectAndWait can't receive signal state of the waiting object in time, causing a deadlock.

Очевидно, что в SMP системах профит от нее намного меньше. И в отличие от фьютексов функция непригодна для user-mode примитивов синхронизации.

Цитата Qraizer @ 30.04.21, 22:08

Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.

Про бизнес очень сомнительные утверждения.

Цитата Qraizer @ 30.04.21, 22:08

Правда, о security вопросов там, вроде бы, не было.

Вот вот...

Цитата Qraizer @ 30.04.21, 22:08

Прикинь, когда — не дай бог – падает самолёт, комиссии смотрят код в последнюю очередь и в очень малом проценте инцидентов. Почему? Потому что это не требуется. Вся инфа берётся из документации и логов. А этого в свою очередь достаточно, потому что там исчерпывающая документация. Если бы это было не так, в комиссиях должны были бы состоять исключительно программисты, но среди них крайне мало конструкторов, схемотехников, специалистов по физике атмосферы, прочнистов итд итп и др.

Ты пытаешься натянуть сову на глобус. Юридические аспекты в этом вопросе лично меня мало волнуют. Для отдельных отраслей есть специальные дистрибутивы linux'а, где много чего гарантируется и документировано. По факту там просто деньги отмыли на этом, но это разговор для другой темы.

Цитата Qraizer @ 30.04.21, 22:08

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

Я нигде не писал о надежности, я писал о кривости архитектуры, что не одно и тоже. На кривой архитектуре можно вполне построить работоспособное приложение.

Цитата Qraizer @ 30.04.21, 22:08

А вот для чего пользуют (просто пример! пользовать в своих проектах не более чем как демонстрацию концепции):

Спасибо, капитан!

Скрытый текст

Аналог этой функции для своей игрушечной ОС я написал еще будучи студентом младших курсов

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

Сообщение отредактировано: shm - 01.05.21, 22:37

Цитата shm @ 01.05.21, 12:58

Как не меняют-то? Типа извлечение элемента из очереди это "не меняют"?

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

Цитата shm @ 01.05.21, 12:58

Если программист идиот, то он может и сделать 100500 потоков-читателей, а также сделать множество других глупостей.

Или 100500 коннектов к онлайн-магазину. Вот только не надо тут, что на API мол такого не пишут. Ага.

Цитата shm @ 01.05.21, 12:58

Пруф, разумеется, будет.

Пруф чего? Того, как доC++11легаси, разработанный под WinAPI, переделать под std? А что ещё ты там вычитал? Ах да, ты ж написал, что.
Ну, молодец он, что могу сказать. Хорошая статья для чьего-нибудь FAQ-а. Но лично я забил рефакторить, ибо интерфейс моих классов 2001 года издания, обеспечивающие не меньшую портабельность между WinAPI и POSIX, гораздо удобнее pthreadнутого std. К тому же нет путаницы с названиями классов и интуитивным их пониманием, к которой в std нужно привыкнуть. А уж CV просто жуть. Я-то надеялся, что их поправят под что-то более удобоваримое, как-никак 21-ый век 10 лет уж как шагает по миру. Но нет, как были неудобным фуфлом в pthread, так им и остались.

Цитата shm @ 01.05.21, 12:58

Очевидно, что в SMP системах профит от нее намного меньше.

И снова просто note, эта фраза явным образом следует из... Я как будто и не писал выше о Рихтере, да? Его советы по недопущению дидлуков никем не читаны, да? Ну да фиг с ним, с Рихтером, как вы вообще тогда CV пишете, без знания теории? ...пожалуй, я не буду комментировать мат.часть. Ну вот как нет желания объяснять, почему, например, к std::string_view нельзя относиться так же, как к std::string. Джуну надо целый курс лекций читать, а профи и так знает.

Цитата shm @ 01.05.21, 12:58

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

Опять троллишь? Причём тут юриспруденция? Речь о корректно поставленном бизнес-процессе. Который корректно поставлен, благодаря полноте и качеству документации. Если не троллишь, а просто этого не понял, нахрена я тут тогда тут распинаюсь?

Цитата shm @ 01.05.21, 12:58

Спасибо, капитан!

Зачем тогда IO приплетал? Всё-таки троллишь? Ну ок, тогда до свиданья. Поехали!

Сообщения были разделены в тему "WinAPI и POSIX"

Это сообщение было перенесено сюда или объединено из темы "Не поздно ли начать изучать С++?"

Цитата Qraizer @ 23.04.21, 12:16

Вот как перенесу всё, кроме первой страницы, в Холивары, вот там и флудите на здоровье. Но-таки отвечу, коли сам начал.

M

Флудите на здоровье!

Цитата Qraizer @ 30.04.21, 22:08

Вот поэтому винда правит крупным бизнесом и домашними ПК, где важны стоимости корпоративных решений и простота администрирования, а POSIX – малым и средним бизнесом, где важны стоимости владений решениями и относительно велики бизнес-риски.

И где же винда правит крупным бизнесом?

Цитата Qraizer @ 01.05.21, 22:24

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

И что ты предлагаешь? Lock-free queue? Давай без загадок. К тому же про высоконагруженную области я не писал в контексте блокирующей очереди.

Цитата Qraizer @ 01.05.21, 22:24

Или 100500 коннектов к онлайн-магазину.

Ещё кто-то создаёт по потоку на соединение?

Цитата Qraizer @ 01.05.21, 22:24

Пруф чего?

Ты статью читал? Судя по всему, только заголовок. Ок, мой изначальный вопрос в силе: хочу увидеть реализацию блокирующей очереди (несколько писателей - читателей) на событии с автосбросом. Ты же сам сказал, что это проще, чем с cv. Я могу сразу прогнать тесты.

Скрытый текст

все простые реализации на event'ах, которые я тестировал, с треском проигрывают решениям на cv по производительности

Цитата Qraizer @ 01.05.21, 22:24

Ну да фиг с ним, с Рихтером, как вы вообще тогда CV пишете, без знания теории

Откуда такие выводы? Если уж на то пошло, то Рихтер - это ни разу не теория. Теория - этот тот же Таненбаум.

Цитата Qraizer @ 01.05.21, 22:24

Джуну надо целый курс лекций читать, а профи и так знает.

Ммм. Кто-то страницу назад доказывал, что с евентами все просто, а cv одни дэдлоки. А вот оно как... И про smp я не зря говорю, что там может произойти с состоянием эвента (особенно с ручным сбросом) в момент SignalObjectAndWait? А ведь большая часть программистов вообще плохо понимает как оно там устроено в ядре на smp-системах.

Цитата Qraizer @ 01.05.21, 22:24

Если не троллишь, а просто этого не понял, нахрена я тут тогда тут распинаюсь?

А с чего ты взял, что:
1. ваши производственные процессы идеальны?
2. Им нужно следовать в других компаниях (других отраслей и направленности)?
И вообще это оффтоп.

Цитата Qraizer @ 01.05.21, 22:24

Зачем тогда IO приплетал? Всё-таки троллишь? Ну ок, тогда до свиданья. Поехали!

Ты серьезно думаешь, что я не знаю как работает waitformultipleobjects? По моему троллишь как раз ты. Давно мог дать ссылку на простую (проще чем на cv) и эффективную реализацию очереди на евентах... Тогда бы вопрос был исчерпан.

Если самолёты управляются софтом на windows, то мне страшно.

По поводу крупного бизнеса нужны пруфы. Насколько мне известно, там мало windows.

По поводу сравнения с POSIX. Не очень понятно, зачем сравнивать конкретную ОС со стандартом, под который попадает очень широкий спектр ОС. А если рассмотрим частичную совместимость, так вообще большая часть существующих ОС.
Можно взять конкретный linux, например, и сравнивать, будет более корректно.

Добавлено 02.05.21, 08:38

Цитата shm @ 23.04.21, 16:26

там используются те же очереди на IOCP/epoll

На io_uring не смотрел случаем?

Добавлено 02.05.21, 08:43

Цитата Qraizer @ 30.04.21, 22:08

Так её и не используют на высоких нагрузках.

А саму винду-то на высоких нагрузках кто-то использует? Насколько мне известно, по крайней мере на серверах, её довольно мало.

Добавлено 02.05.21, 09:06
Вообще есть мнение, что MS скоро может переехать на linux ядро и тогда холивары потеряют актуальность
Придется им повозиться с совместимостью, но по-моему тенденции последних изменений намекают на возможность такого перехода.

Добавлено 02.05.21, 09:10

Цитата D_KEY @ 02.05.21, 08:34

А саму винду-то на высоких нагрузках кто-то использует? Насколько мне известно, по крайней мере на серверах, её довольно мало.

Даже в Azure самая используемая ОС - Linux

Добавлено 02.05.21, 09:21

Цитата OpenGL @ 23.04.21, 19:26

Вот только почему-то такая штука как docker в лине есть нативно с его стрёмной системой прав, в винде же он надстройка над hyper-v. Без виртуализации, видимо, никак не сделать в столь гибкой системе.

Ну справедливости ради, docker и основан на API линукса
Кстати, на POSIX голом никакой docker ты не сделаешь.

Ещё мне кажется, что в новых версиях винды таки смогли поддержать docker без виртуализации. WSL же, нет?

Цитата Qraizer @ 01.05.21, 22:24

Но лично я забил рефакторить, ибо интерфейс моих классов 2001 года издания, обеспечивающие не меньшую портабельность между WinAPI и POSIX, гораздо удобнее pthreadнутого std.

Если это какие-то личные поделки для себя, то вопросов нет. А так похоже на nih- синдром

Цитата Qraizer @ 22.04.21, 18:06

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

В первый раз вижу, чтобы жирность расценивалась как преимущество. Есть, конечно, борцы сумо, но это скорее исключение, чем правило.

Добавлено 02.05.21, 11:36

Цитата D_KEY @ 02.05.21, 08:34

Ну справедливости ради, docker и основан на API линукса

Если под «основан» ты понимаешь «построен», то да. Иначе — нет. Основан он на (идеях из) API Plan 9.

Сообщение отредактировано: korvin - 02.05.21, 11:36

Цитата korvin @ 02.05.21, 11:34

Цитата D_KEY @ 02.05.21, 08:34

Ну справедливости ради, docker и основан на API линукса

Если под «основан» ты понимаешь «построен», то да.

Да, имел в виду "построен"