Начни читать отсюда: https://ru.wikipedia.org/wiki/POSIXWindows - это не UNIX-подобная ОС. У нее по-другому работает ядро. Причем есть было несколько операционных систем, которые называли Windows. Та из них, которая Windows NT - это скорее VMS-подобная ОС.
https://ru.wikipedia.org/wiki/OpenVMS
В обоих ОС совместимость с POSIX была всегда сбоку, у них своё юзерспейсное API, своя логика системных вызовов и специфика работы с модулями ядра и шинами данных. То есть API POSIX для Windows NT исторически был модулем ядра, который предлагает альтернативное API. Работал, кстати, из рук вон плохо, потому что Microsoft не писал свою реализацию POSIX в Windows NT, он её зааутсорсил и потом как попало обновлял. Те кому был нужен POSIX на Windows применяли специфические разделяемые библиотеки в пространстве пользователя, а не то барахло, что было в ядре Windows, например тот же Cygwin.
Дальше нужно держать в уме 2 тезиса:
- Windows (юзерспейсные части ядра, системные службы, Desktop) работает на C++ и в их компиляторе есть поддержка подмножества стандарта языка С99, которое входит в стандарты С++
- POSIX - это стандарт системного API строго для языка С.
Вам нужен компилятор языка С на Windows, разделяемые библиотеки С (а не С++) для вашего POSIX-софта, наличие системных вызовов или их трансформация сквозь разделяемые библиотеки того же Cygwin, который это превращает в вызовы Windows NT. Вот зачем он нужен.
Затем в какой-то момент времени (клиенты просили docker на Windows) Microsoft снизошел переписывать реализацию POSIX, но ему не нужен был настоящий POSIX, ему нужно было эмулировать системные вызовы конкретно Linux. Так появился WSL и был добавлен вторичный clang как бэкенд для С2-коппилятор. WSL некоторое время был конкурентом Cygwin, потому что в ядро Windows добавили поддержку ELF. Даже перекомпилировать ПО было не нужно, просто ставь свои бинарные библиотеки. Это уже уровень "Wine-наоборот". https://learn.microsoft.com/en-us/shows/one-dev-minute/windo...
А потом Microsoft WSL из-за стоимости сопровождения. Гоняться за изменениями в Linux и писать базы совместимости софта для WSL столь же неблагодарное занятие, сколько и то чем занимается Wine/Crossover. Так появился WSL2, который запускает полноценное ядро в виртуальной машине. Только я сразу предупреждаю, не ищите заговора, там чисто технически чудовищный объем тащить WSL. В WSL очень медленное I/O, но быстрые вычисления. В WSL2 наоборот. Для большинства приложений I/O важнее чем скорость исполнения инструкций.
Ну и главное нужно понять, что POSIX - это очень старое системное API, которое:
- изначально придумывалось для борьбы с зоопарком в мире UNIX
- архитектурно оптимизировано для компьютеров, которых больше не производят
- ужасно работает с локализацией
- имеет плохую поддержку мультитрединга.
Современные процессоры с ассиметричными ядрами и NUMA это не про POSIX. pthreads, который появился очень поздно, не часто применяется. Вся архитектура многозадачности вменяет вам shared memory и архитектуру fork-join, где вы порождаете дочерние процессы на каждый чих, https://en.wikipedia.org/wiki/Fork%E2%80%93jo...
И вот смена локали в приложении ломает тут абсолютно всё. На современном процессоре, рассчитанном на треды, ядра группируются в кластеры и подключаются к нескольким контроллерам памяти, также внутрь группы добавляеются шины PCI Express - все это создаёт узел NUMA. Архитектура ccNUMA, которая стала повсеместной даже в консьюмерском сегменте ПК не совместимо с концепциями shared memory и fork от слова "совсем", поэтому POSIX как таковой не применяется даже в Linux.
Linux - это POSIX-совместимая ОС, но она имеет такое количесвто adhoc-линуксизмов, что код написанный для Linux требует прослойки-линуксатора в другой POSIX ОС. Поэтому поддержка Linux и поддержка POSIX это "две большие разницы".
А теперь посмотрите на это с точки зрения разработчика. Если разработчик пишет кроссплатформенное приложение "MyLovelyApp" он может:
1. Создать группу проектов, которые называет одним и тем же именем "MyLovelyApp", но это на самом деле разные программы для разных ОС, которые имеют 80% общей кодовой базы, и 20% ОС-зависимых обвязок. Тогда в каждую ОС нужно собирать такой софт по-разному. Путь Google Chrome, например.
2. Воспользоваться разделяемыми библиотеками и кроссплатформенным компилятором, которые снимут бремя по написанию ОС-зависимого бойлерплейта. Например, это Qt и то подмножество чисто юзеспейсных вопросов, который может msys2, хотя прежде всего речь про mingw.
3. Привязать себя к стандарту POSIX и попытаться сэмулироваться средствами ОС. То есть заставить пользователя поставить поставить POSIX-модули ядра, линуксаторы и прочий WSL.
4. Привязать себя к стандарту POSIX и поcтараться сделать полную эмуляцию всех POSIX функций, которые используются в приложении "MyLovelyApp" даже в ущерб производительности. Это путь Cygwin.
Если вам понятнее Wine, то он работает также. Wine - это прежде всего реализация Win32, которая может быть подключена как разделяемая библиотека в юзерспейсе к вашему Windows-специфичному коду. Teamviewer для Linux - хороший пример. То есть cygwin - это wine наоборот. В ядро Wine не лезет и слоем эмуляции в том смысле, в котором это делает та же WSL. Опять же, cygwin можно использовать также как используют пакеты wine в дистрибутивах линукс, сформировать кусочек ОС в префиксе и поставить кучу софта.
