forum.opennet.ru - "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " (50)

"Выпуск Cygwin 3.5.0, GNU-окружения для Windows "

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
Сообщение от opennews (??), 01-Фев-24, 16:40
Компания Red Hat опубликовала стабильный релиз пакета Cygwin 3.5.0, включающего DLL-библиотеку для эмуляции базового Linux API в Windows, позволяющую с минимальными изменениями собирать созданные для Linux программы. В пакет также входят непосредственно собранные для выполнения в Windows стандартные Unix-утилиты, серверные приложения, компиляторы, библиотеки и заголовочные файлы... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60535
Ответить \| Правка \| Cообщить модератору

Оглавление

Либо я что-то не понимаю, либо короче, я сто лет юзаю msys2 и там tmux всегда, Аноним (1), 16:40 , 01-Фев-24, (1) +1

Держи плюс, приятель Но по теме, msys и cygwin - это вроде проекты-конкуренты, н, Аноним (8), 17:33 , 01-Фев-24, (8)

Спс Да я тож хз, но мне казалось, что msys2 ющает сингвинские либы, Аноним (13), 17:55 , 01-Фев-24, (13) +1

Не совсем В репозиториях есть разные пакеты, которые зависит от типа рантайма, , Аноним (32), 01:09 , 02-Фев-24, (32)
Когда-то давно msys отделились от cygwin из-за разных целей Cygwin в максимальн, Александр (??), 00:49 , 03-Фев-24, (42)

cygwin опирается на эмуляцию POSIX API под виндой В нём работает mc, есть катал, Аноним (52), 16:02 , 05-Фев-24, (52)

Нет поддержки Windows XP В топку , banonymous (?), 16:47 , 01-Фев-24, (2) +5

Я тоже считаю, что это полное безобразие Кому он нужен такой XP x64 прекрасно по, Аноним (3), 16:58 , 01-Фев-24, (3) +1

Объективно любой код тех времён максимально проблемный Да-да, в то время как ка, Аноним (5), 17:18 , 01-Фев-24, (5) +2

Мозг просит подробностей , Аноним (8), 17:31 , 01-Фев-24, (7) +2
Ты действительно считаешь, что в коде Win 12 меньше проблем чем в семерке , Аноним (9), 17:37 , 01-Фев-24, (9) +3

Всё так Я действительно считаю, что 12 менее уязвима для малвари и содержит мен, Аноним (5), 17:50 , 01-Фев-24, (11) –1

Скрыто модератором, Аноним (39), 16:58 , 02-Фев-24, (39)

Даже простая работа, на уровне консольного приложения, в ХП, 7ке, и 10ке приличн, _kp (ok), 22:27 , 01-Фев-24, (29) +2

Я всё ещё не понимаю зачем нужен сабж Почему не собрать нативно , Аноним (10), 17:38 , 01-Фев-24, (10)

я может что-то не понял, но разве нативный код не зависит от хидеров, который ес, penetrator (?), 17:52 , 01-Фев-24, (12) +3

mingw-w64 как раз и является прослойкой хидеров, сабж дополнительная либа-просло, Аноним (5), 17:59 , 01-Фев-24, (15)

так хидеры фактически описывают таблицу экспорта, те же шары вид сбоку, penetrator (?), 06:01 , 02-Фев-24, (33)

Так в Windiws системные dll не экспортируют например mremap Вот Cygwin и эмул, n00by (ok), 08:26 , 02-Фев-24, (35) +1

системные либы в винде вообще не экспотируют что-то типа mremap там везде паскал, penetrator (?), 07:08 , 04-Фев-24, (44)

Не надо путать конвенцию вызова Pascall там нет, в 32-х разрядной Windows была , n00by (ok), 10:58 , 04-Фев-24, (47)

а в 64 битной по-другому ясно понятно define WINAPI __stdcallэто н, penetrator (?), 19:33 , 04-Фев-24, (50)

Да как бы не до смеху Набрать в поисковике windows 64 calling convention и пр, n00by (ok), 16:42 , 05-Фев-24, (53)

из виндового SDK, там всегда был __stdcall в сырцах и для 32-битных функций и 64, penetrator (?), 22:32 , 05-Фев-24, (54)

Не понимаю Будь добр и объясни, зачем ты мне это пишешь Напомню, что ты начал , n00by (ok), 07:53 , 06-Фев-24, (55)

Не совсем Windows не совместим с POSIX Cygwin и msis - это по сути POSIX подси, Александр (??), 00:51 , 03-Фев-24, (43)

строго говоря до Windows 8 там была Microsoft POSIX subsystem, потом воткнули WS, penetrator (?), 07:11 , 04-Фев-24, (45)

Это неэмулятор линукса Если какой-то софт поддерживает сборку без линукса, то, , Аноним (5), 17:56 , 01-Фев-24, (14) +2

Начни читать отсюда https ru wikipedia org wiki POSIXWindows - это не UNIX-по, Аноним (49), 14:01 , 04-Фев-24, (49) +1

Никто не мешает через Cygwin сменить права POSIX на файлы в NTFS или процессы, и, EULA (?), 07:17 , 05-Фев-24, (51)

Скрыто модератором, Mr.Who (?), 18:01 , 01-Фев-24, (16) –4
И эти туда же Ну и чем мешало Опять красношапка со своим запланированным устар, Аноним (17), 18:07 , 01-Фев-24, (17)

В чем проблема обновить древнюю ОС И что мешает поставить Linux в dual boot, и , Аноним (18), 18:22 , 01-Фев-24, (18) +3

В том, что виндовс 7 используется как ось для виртуалки, чтобы с минимальными за, anonymous (??), 20:19 , 01-Фев-24, (24)

а зачем вам в виртуалке цигвин Нельзя обрабатывать ввод вывод вин-онли программ, фф (?), 09:57 , 02-Фев-24, (37)

Windows 7 официально EoL с 14 января 2020, о чём MS заявила ещё в момент выпуска, Аноним (25), 20:58 , 01-Фев-24, (25)

Если бы и поддерживалось , то толку с того, у 7ки API прилично другое И тут ил, _kp (ok), 22:30 , 01-Фев-24, (30) +1
поддерживалась до 1 января 2023 года клиент, и 2024 года сервер 2008 R2, но все , penetrator (?), 07:13 , 04-Фев-24, (46)

Я вот чего не понимаю Если вы сидите на системе пятнадцатилетней давности, чем , Аноним (39), 16:59 , 02-Фев-24, (40) +1

Зачем оно, если есть WSL, а там где его нет, теперь нет и Cygwin , AKTEON (?), 19:14 , 01-Фев-24, (19) +4

Не дождетесь, все там есть WSL нужен детям на ворованной винде , Аноним (21), 19:46 , 01-Фев-24, (21) –2

Чтобы что , Аноним (23), 20:08 , 01-Фев-24, (23) +1
WSL спокойно работает из коробки даже в Windows Home Single Language Ибо начина, Аноним (32), 01:04 , 02-Фев-24, (31) +3

Порой запускать виртуалку ради запуска небольших приложений не очень хорошая иде, Аноним (34), 08:18 , 02-Фев-24, (34) +1

Эта 171 виртуалка 187 пошустрее сабжа работает , Аноним (39), 17:00 , 02-Фев-24, (41) –1

Да установите уже Linux , Аноним (20), 19:25 , 01-Фев-24, (20) +3

Скрыто модератором, turbodog (-), 21:29 , 01-Фев-24, (28) +2

Скрыто модератором, turbodog (-), 21:26 , 01-Фев-24, (27)
Так это Red Hat разрабы, я то всё думал почему оно на моей машине не заводится , Scalpi (?), 12:48 , 02-Фев-24, (38)
В винде давно есть WSL, Cygwin был нужен скорее на 7-ке , Аноним (48), 11:06 , 04-Фев-24, (48)

Сообщения [Сортировка по времени | RSS]

1. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от Аноним (1), 01-Фев-24, 16:40

> Разрешён доступ к устройствам консолей (/dev/consN) из процессов, присоединённых к другим консолям или pty-терминалам. Изменение позволило обеспечить возможность запуска в консоли утилит GNU screed и tmux.
Либо я что-то не понимаю, либо... короче, я сто лет юзаю msys2 и там tmux всегда работал

Ответить | Правка | Наверх | Cообщить модератору

8. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Аноним (8), 01-Фев-24, 17:33

Держи плюс, приятель.
Но по теме, msys и cygwin - это вроде проекты-конкуренты, не? (я не очень в теме)

Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от Аноним (13), 01-Фев-24, 17:55

Спс :) Да я тож хз, но мне казалось, что msys2 ющает сингвинские либы

Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Аноним (32), 02-Фев-24, 01:09

>мне казалось, что msys2 ющает сингвинские либы
Не совсем. В репозиториях есть разные пакеты, которые зависит от типа рантайма, в котором это добро и запускается. Есть и с сигвиновскими либами, и напрямую скомпиленные под Винду, и даже варианты, собранные через компиляторы от самих мелкомягких (насколько я помню).

Ответить | Правка | Наверх | Cообщить модератору

42. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Александр (??), 03-Фев-24, 00:49

Когда-то давно msys отделились от cygwin из-за разных целей. Cygwin в максимальную совместимость, msys в меньшую монструозность. Я думаю с тех времён что-нибудь и осталось.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

52. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Аноним (52), 05-Фев-24, 16:02

cygwin опирается на эмуляцию POSIX API под виндой. В нём работает mc, есть каталог /dev, alsa и X11. Что-то похожее на WSL1, только целиком в userspace.
msys - это порт линуксовых программ в win32. Для coreutils, make, gcc много не надо. Вызов fork использовать нельзя, а вот open/read/write/close имеются в msvcrt.dll (со своими заморочками). Много чего и в msys "доэмулируется", но масштабы не такие как в cygwin (cygwin претендует на полноценная совместимость с POSIX и Linux).
P.S. Чтобы понятнее - msys увидит файл C:\mydir\readme.txt (может и C:/mydir/readme.txt, но так и сама винда много где может), а cygwin увидит что-то типа /mnt/disk_c/mydir/readme.txt.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

2. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +5 +/–

Сообщение от banonymous (?), 01-Фев-24, 16:47

Нет поддержки Windows XP? В топку!

Ответить | Правка | Наверх | Cообщить модератору

3. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от Аноним (3), 01-Фев-24, 16:58

Я тоже считаю, что это полное безобразие.
Кому он нужен такой?

XP x64 прекрасно поддерживает сколько угодно памяти, а также полностью поддерживает unicode.
А свои "инновации" ... придержите до лучших времён.

Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +2 +/–

Сообщение от Аноним (5), 01-Фев-24, 17:18

Объективно любой код тех времён максимально проблемный. Да-да, в то время как как раз и начали прозревать.

Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +2 +/–

Сообщение от Аноним (8), 01-Фев-24, 17:31

Мозг просит подробностей.

Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +3 +/–

Сообщение от Аноним (9), 01-Фев-24, 17:37

Ты действительно считаешь, что в коде Win 12 меньше проблем чем в семерке?

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

11. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " –1 +/–

Сообщение от Аноним (5), 01-Фев-24, 17:50

> Ты действительно считаешь, что в коде Win 12 меньше проблем чем в
> семерке?
Всё так. Я действительно считаю, что 12 менее уязвима для малвари и содержит меньше деструктивных багов, таких как рассыпание MFT. А так же 12 более производительна, работает с современным железом, и, не самое последнее, нормально подерживает юникод. Конечно же, современные технологии тоже. Ещё не деградирует так сильно при обновлениях, но это уже не актуально.

Ответить | Правка | Наверх | Cообщить модератору

39. Скрыто модератором +/–

Сообщение от Аноним (39), 02-Фев-24, 16:58

На всякий случай напомню, что XP всего лишь на три года младше Win98.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

29. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +2 +/–

Сообщение от _kp (ok), 01-Фев-24, 22:27

Даже простая работа, на уровне консольного приложения, в ХП, 7ке, и 10ке прилично отличается.
И даже если без Цигвина желать приложение, то тут или не использовать весьма полезные новшества, или  писать херовое ПО под ОС начала века.
Так, пока мы далеко в API не лезли, и речь была и простом консольном приложении.
Очевидное решение ограничиться поддержкой Windows10+.
(Про Win8.1 понятия не имею)

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

10. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Аноним (10), 01-Фев-24, 17:38

Я всё ещё не понимаю зачем нужен сабж? Почему не собрать нативно?

Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +3 +/–

Сообщение от penetrator (?), 01-Фев-24, 17:52

я может что-то не понял, но разве нативный код не зависит от хидеров, который есть только в линухе? кто будет это транслировать в Win32 API?

Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Аноним (5), 01-Фев-24, 17:59

> я может что-то не понял, но разве нативный код не зависит от
> хидеров, который есть только в линухе? кто будет это транслировать в
> Win32 API?
mingw-w64 как раз и является прослойкой хидеров, сабж дополнительная либа-прослойка неэмулятора линукс и репозитории собранных файлов. Дело не в хидерах, а в недоступных апи в либц венды.

Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от penetrator (?), 02-Фев-24, 06:01

так хидеры фактически описывают таблицу экспорта, те же шары вид сбоку

Ответить | Правка | Наверх | Cообщить модератору

35. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от n00by (ok), 02-Фев-24, 08:26

Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и эмулирует её через memcpy() (или уже передалали на резерв+коммит?)

Ответить | Правка | Наверх | Cообщить модератору

44. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от penetrator (?), 04-Фев-24, 07:08

> Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и
> эмулирует её через memcpy() (или уже передалали на резерв+коммит?)
системные либы в винде вообще не экспотируют что-то типа mremap там везде паскалевская нотация и два варианта функций с уникодом и без (W / A), а еще STDCALL, там свое апи
и ты вообще не туда полез, я говорю что заголовочные файлы для сишки "фактически" описывают таблицу экспорта конкретных либ, и сами по себе не имеют смысла

Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от n00by (ok), 04-Фев-24, 10:58

>> Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и
>> эмулирует её через memcpy() (или уже передалали на резерв+коммит?)
> системные либы в винде вообще не экспотируют что-то типа mremap там везде
> паскалевская нотация и два варианта функций с уникодом и без (W
> / A), а еще STDCALL, там свое апи
Не надо путать конвенцию вызова (Pascall там нет, в 32-х разрядной Windows была stdcall и в редких случаях fastcall) и предоставляемые системные сервисы (API).
Ближайшим аналогом mmap() является NtMapViewOfSection() или обёртка над ней VirtualAllocEx() из Win32 API. То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос, транслятор выдаст рабочий exe-шник, при инициализации процесса он слинкуется с чем надо. C mremap() так просто не получится (работать будет, но не так быстро как в Linux).
> и ты вообще не туда полез, я говорю что заголовочные файлы для
> сишки "фактически" описывают таблицу экспорта конкретных либ, и сами по себе
> не имеют смысла
Не знаю, кто куда полез, но вот первое попавшееся "описание таблицы экспорта"
#define malloc(foo) HeapAlloc(GetProcessHeap(), HEAP_NO_SERIALIZE, foo)

Ответить | Правка | Наверх | Cообщить модератору

50. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от penetrator (?), 04-Фев-24, 19:33

> в 32-х разрядной Windows была stdcall
а в 64 битной по-другому? ясно понятно )))))))
#define WINAPI      __stdcall
> То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос
это не означает, что не будет таких функций которые нельзя заинлайнить через макрос и им не нужна библиотека
A header file is a file with extension .h contains C function declarations and macro definitions.
Все что не макрос (константа и бла бла бла), то декларация экспортируемой функции библиотеки, для которой этот хидер файл написан. Азы сей... нах это жевать?

Ответить | Правка | Наверх | Cообщить модератору

53. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от n00by (ok), 05-Фев-24, 16:42

>> в 32-х разрядной Windows была stdcall
> а в 64 битной по-другому? ясно понятно )))))))
Да как бы не до смеху. Набрать в поисковике "windows 64 calling convention" и прочитать
The first four arguments are placed onto the registers. That means RCX, RDX, R8, R9 (in that order) for integer, struct or pointer arguments, and XMM0, XMM1, XMM2, XMM3 for floating point arguments. Additional arguments are pushed onto the stack (right to left).
В fastcall использовались первые два регистра из списка. В __stdcall всё идёт через стек.
> #define WINAPI      __stdcall
Это откуда и к чему?
>> То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос
> это не означает, что не будет таких функций которые нельзя заинлайнить через
> макрос и им не нужна библиотека
Я вот реально не пойму, что тут написано. Какая библиотека? Вот реализация стандартной библиотеки плюсов (в т.ч. включает и сишную) https://github.com/icestudent/ontl практически всё header-only, которой нужна только ntdll.dll. Так же возможно и POSIX туда добавить.
> A header file is a file with extension .h contains C function
> declarations and macro definitions.
> Все что не макрос (константа и бла бла бла), то декларация экспортируемой
> функции библиотеки, для которой этот хидер файл написан. Азы сей... нах
> это жевать?
И я не знаю, зачем жевать азы, когда есть стандарт. Там, внезапно, не обнаруживается определение термина "header file". Есть понятие единица трансляции, и директива #include может включать в неё что угодно, лишь бы препроцессор прожевал:
6.10.2 Source file inclusion
Constraints
1 A #include directive shall identify a header or source file that can be processed by the implementation.

Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от penetrator (?), 05-Фев-24, 22:32

из виндового SDK, там всегда был __stdcall в сырцах и для 32-битных функций и 64-битных функций, но есть нюанс, который называется Microsoft x64 calling convention
When compiling for the x64 architecture in a Windows context (whether using Microsoft or non-Microsoft tools), stdcall, thiscall, cdecl, and fastcall all resolve to using this convention.
-----
ну не понимаешь так не понимаешь

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от n00by (ok), 06-Фев-24, 07:53

Не понимаю. Будь добр и объясни, зачем ты мне это пишешь? Напомню, что ты начал с "там везде паскалевская нотация". Намекаешь, что понял свою ошибку?

Ответить | Правка | Наверх | Cообщить модератору

43. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Александр (??), 03-Фев-24, 00:51

Не совсем. Windows не совместим с POSIX. Cygwin и msis - это по сути POSIX подсистема и окружение.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

45. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от penetrator (?), 04-Фев-24, 07:11

> Не совсем. Windows не совместим с POSIX. Cygwin и msis - это
> по сути POSIX подсистема и окружение.
строго говоря до Windows 8 там была Microsoft POSIX subsystem, потом воткнули WSL
но это вообще никак не связано с тем что я написал изначально

Ответить | Правка | Наверх | Cообщить модератору

14. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +2 +/–

Сообщение от Аноним (5), 01-Фев-24, 17:56

> Я всё ещё не понимаю зачем нужен сабж? Почему не собрать нативно?
Это неэмулятор линукса. Если какой-то софт поддерживает сборку без линукса, то, как правило, он оказывается менее функциональным в таком виде. И с кучей особенностей. В msys2 к примеру, всгда было разделение, что-то можно собрать "нативно", что-то только с прослойкой. А какой-то софт вообще можно собирать не гцц, а майкрософтовскими компиляторами.

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

49. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от Аноним (49), 04-Фев-24, 14:01

Начни читать отсюда: https://ru.wikipedia.org/wiki/POSIX
Windows - это не 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 в дистрибутивах линукс, сформировать кусочек ОС в префиксе и поставить кучу софта.

Ответить | Правка | Наверх | Cообщить модератору

51. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от EULA (?), 05-Фев-24, 07:17

Никто не мешает через Cygwin сменить права POSIX на файлы в NTFS или процессы, и в итоге System не будет иметь возможности что-то сделать с файлом или процессом.

Ответить | Правка | Наверх | Cообщить модератору

16. Скрыто модератором –4 +/–

Сообщение от Mr.Who (?), 01-Фев-24, 18:01

FreeBSD пишется под macOS, а Linux - под виндой. Всё, что нужно знать о стремлении этих людей делать десктопные ОС.

Ответить | Правка | Наверх | Cообщить модератору

17. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Аноним (17), 01-Фев-24, 18:07

>Выпуск примечателен прекращением поддержки Windows 7
И эти туда же. Ну и чем мешало? Опять красношапка со своим запланированным устареавнием. Ничему, что они касаются, доверять нельзя.

Ответить | Правка | Наверх | Cообщить модератору

18. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +3 +/–

Сообщение от Аноним (18), 01-Фев-24, 18:22

В чем проблема обновить древнюю ОС? И что мешает поставить Linux в dual boot, и дальше пользоваться своим nero burning rom, и решать современные задачи?

Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от anonymous (??), 01-Фев-24, 20:19

В том, что виндовс 7 используется как ось для виртуалки, чтобы с минимальными затратами оперативки запускать виндовс-онли программы. Раньше использовалась XP, которая жрала в три раза меньше памяти, но её софт перестал поддерживать.
Новая ось в виртуалке нафиг не нужна.

Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от фф (?), 02-Фев-24, 09:57

а зачем вам в виртуалке цигвин? Нельзя обрабатывать ввод/вывод вин-онли программы на хосте?

Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Аноним (25), 01-Фев-24, 20:58

Windows 7 официально EoL с 14 января 2020, о чём MS заявила ещё в момент выпуска семёрки. Зачем проекту поддерживать то, что 4 года не поддерживается производителем? И как именно в этом виноват Ред Хат? Не говоря уже о том, что старые версии у тебя никто не отбирает и они дальше будут работать как работали.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

30. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от _kp (ok), 01-Фев-24, 22:30

Если бы и "поддерживалось", то толку с того, у 7ки API прилично другое.
И тут или забить на старое, или игнорировать новое. Выбор очевиден.

Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от penetrator (?), 04-Фев-24, 07:13

> Windows 7 официально EoL с 14 января 2020, о чём MS заявила
> ещё в момент выпуска семёрки. Зачем проекту поддерживать то, что 4
> года не поддерживается производителем? И как именно в этом виноват Ред
> Хат? Не говоря уже о том, что старые версии у тебя
> никто не отбирает и они дальше будут работать как работали.
поддерживалась до 1 января 2023 года клиент, и 2024 года сервер 2008 R2, но все за денежку

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

40. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от Аноним (39), 02-Фев-24, 16:59

Я вот чего не понимаю. Если вы сидите на системе пятнадцатилетней давности, чем вас не устраивает Cygwin пятнадцатилетней давности?

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

19. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +4 +/–

Сообщение от AKTEON (?), 01-Фев-24, 19:14

Зачем оно, если есть WSL, а там где его нет, теперь нет и Cygwin ??

Ответить | Правка | Наверх | Cообщить модератору

21. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " –2 +/–

Сообщение от Аноним (21), 01-Фев-24, 19:46

>там где его нет, теперь нет и Cygwin
Не дождетесь, все там есть. WSL нужен детям на ворованной винде.

Ответить | Правка | Наверх | Cообщить модератору

23. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от Аноним (23), 01-Фев-24, 20:08

  Чтобы что?

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +3 +/–

Сообщение от Аноним (32), 02-Фев-24, 01:04

>WSL нужен детям на ворованной винде.
WSL спокойно работает из коробки даже в Windows Home Single Language. Ибо начиная ещё с Win10 18xx Hyper-V разделили на 2 части - "платформу виртуализации Windows" (виндовый аналог KVM/Xen), и непосредственно саму Hyper-V (теперь уже как аналог Virt-Manager для этой самой "платформы виртуализации"). И вот первое спокойно работает и на Windows Home, вместе с WSL, Docker Desktop, и прочими плюшками, из коробки, и на 100% легально.

Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

34. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +1 +/–

Сообщение от Аноним (34), 02-Фев-24, 08:18

Порой запускать виртуалку ради запуска небольших приложений не очень хорошая идея

Ответить | Правка | Наверх | Cообщить модератору

41. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " –1 +/–

Сообщение от Аноним (39), 02-Фев-24, 17:00

Эта «виртуалка» пошустрее сабжа работает.

Ответить | Правка | Наверх | Cообщить модератору

20. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +3 +/–

Сообщение от Аноним (20), 01-Фев-24, 19:25

Да установите уже Linux !

Ответить | Правка | Наверх | Cообщить модератору

28. Скрыто модератором +2 +/–

Сообщение от turbodog (-), 01-Фев-24, 21:29

За это не платят.

Ответить | Правка | Наверх | Cообщить модератору

27. Скрыто модератором +/–

Сообщение от turbodog (-), 01-Фев-24, 21:26

Желающих пользоваться поделиями фридрисктоп.орг всё меньше и меньше.

Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Scalpi (?), 02-Фев-24, 12:48

Так это  Red Hat разрабы, я то всё думал почему оно на моей машине не заводится. Теперь всё встало на свои места.

Ответить | Правка | Наверх | Cообщить модератору

48. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows " +/–

Сообщение от Аноним (48), 04-Фев-24, 11:06

В винде давно есть WSL, Cygwin был нужен скорее на 7-ке.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+1 +/–
Сообщение от Аноним (1), 01-Фев-24, 16:40
> Разрешён доступ к устройствам консолей (/dev/consN) из процессов, присоединённых к другим консолям или pty-терминалам. Изменение позволило обеспечить возможность запуска в консоли утилит GNU screed и tmux. Либо я что-то не понимаю, либо... короче, я сто лет юзаю msys2 и там tmux всегда работал
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от Аноним (8), 01-Фев-24, 17:33
	Держи плюс, приятель. Но по теме, msys и cygwin - это вроде проекты-конкуренты, не? (я не очень в теме)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+1 +/–
	Сообщение от Аноним (13), 01-Фев-24, 17:55
	Спс :) Да я тож хз, но мне казалось, что msys2 ющает сингвинские либы
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от Аноним (32), 02-Фев-24, 01:09
	>мне казалось, что msys2 ющает сингвинские либы Не совсем. В репозиториях есть разные пакеты, которые зависит от типа рантайма, в котором это добро и запускается. Есть и с сигвиновскими либами, и напрямую скомпиленные под Винду, и даже варианты, собранные через компиляторы от самих мелкомягких (насколько я помню).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от Александр (??), 03-Фев-24, 00:49
	Когда-то давно msys отделились от cygwin из-за разных целей. Cygwin в максимальную совместимость, msys в меньшую монструозность. Я думаю с тех времён что-нибудь и осталось.
	Ответить \| Правка \| К родителю #13 \| Наверх \| Cообщить модератору


	52. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от Аноним (52), 05-Фев-24, 16:02
	cygwin опирается на эмуляцию POSIX API под виндой. В нём работает mc, есть каталог /dev, alsa и X11. Что-то похожее на WSL1, только целиком в userspace. msys - это порт линуксовых программ в win32. Для coreutils, make, gcc много не надо. Вызов fork использовать нельзя, а вот open/read/write/close имеются в msvcrt.dll (со своими заморочками). Много чего и в msys "доэмулируется", но масштабы не такие как в cygwin (cygwin претендует на полноценная совместимость с POSIX и Linux). P.S. Чтобы понятнее - msys увидит файл C:\mydir\readme.txt (может и C:/mydir/readme.txt, но так и сама винда много где может), а cygwin увидит что-то типа /mnt/disk_c/mydir/readme.txt.
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору

2. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+5 +/–
Сообщение от banonymous (?), 01-Фев-24, 16:47
Нет поддержки Windows XP? В топку!
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+1 +/–
	Сообщение от Аноним (3), 01-Фев-24, 16:58
	Я тоже считаю, что это полное безобразие. Кому он нужен такой? XP x64 прекрасно поддерживает сколько угодно памяти, а также полностью поддерживает unicode. А свои "инновации" ... придержите до лучших времён.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+2 +/–
	Сообщение от Аноним (5), 01-Фев-24, 17:18
	Объективно любой код тех времён максимально проблемный. Да-да, в то время как как раз и начали прозревать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+2 +/–
	Сообщение от Аноним (8), 01-Фев-24, 17:31
	Мозг просит подробностей.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+3 +/–
	Сообщение от Аноним (9), 01-Фев-24, 17:37
	Ты действительно считаешь, что в коде Win 12 меньше проблем чем в семерке?
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	11. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	–1 +/–
	Сообщение от Аноним (5), 01-Фев-24, 17:50
	> Ты действительно считаешь, что в коде Win 12 меньше проблем чем в > семерке? Всё так. Я действительно считаю, что 12 менее уязвима для малвари и содержит меньше деструктивных багов, таких как рассыпание MFT. А так же 12 более производительна, работает с современным железом, и, не самое последнее, нормально подерживает юникод. Конечно же, современные технологии тоже. Ещё не деградирует так сильно при обновлениях, но это уже не актуально.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	39. Скрыто модератором	+/–
	Сообщение от Аноним (39), 02-Фев-24, 16:58
	На всякий случай напомню, что XP всего лишь на три года младше Win98.
	Ответить \| Правка \| К родителю #3 \| Наверх \| Cообщить модератору


	29. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+2 +/–
	Сообщение от _kp (ok), 01-Фев-24, 22:27
	Даже простая работа, на уровне консольного приложения, в ХП, 7ке, и 10ке прилично отличается. И даже если без Цигвина желать приложение, то тут или не использовать весьма полезные новшества, или писать херовое ПО под ОС начала века. Так, пока мы далеко в API не лезли, и речь была и простом консольном приложении. Очевидное решение ограничиться поддержкой Windows10+. (Про Win8.1 понятия не имею)
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору

10. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
Сообщение от Аноним (10), 01-Фев-24, 17:38
Я всё ещё не понимаю зачем нужен сабж? Почему не собрать нативно?
Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+3 +/–
	Сообщение от penetrator (?), 01-Фев-24, 17:52
	я может что-то не понял, но разве нативный код не зависит от хидеров, который есть только в линухе? кто будет это транслировать в Win32 API?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от Аноним (5), 01-Фев-24, 17:59
	> я может что-то не понял, но разве нативный код не зависит от > хидеров, который есть только в линухе? кто будет это транслировать в > Win32 API? mingw-w64 как раз и является прослойкой хидеров, сабж дополнительная либа-прослойка неэмулятора линукс и репозитории собранных файлов. Дело не в хидерах, а в недоступных апи в либц венды.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	33. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от penetrator (?), 02-Фев-24, 06:01
	так хидеры фактически описывают таблицу экспорта, те же шары вид сбоку
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+1 +/–
	Сообщение от n00by (ok), 02-Фев-24, 08:26
	Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и эмулирует её через memcpy() (или уже передалали на резерв+коммит?)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от penetrator (?), 04-Фев-24, 07:08
	> Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и > эмулирует её через memcpy() (или уже передалали на резерв+коммит?) системные либы в винде вообще не экспотируют что-то типа mremap там везде паскалевская нотация и два варианта функций с уникодом и без (W / A), а еще STDCALL, там свое апи и ты вообще не туда полез, я говорю что заголовочные файлы для сишки "фактически" описывают таблицу экспорта конкретных либ, и сами по себе не имеют смысла
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от n00by (ok), 04-Фев-24, 10:58
	>> Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и >> эмулирует её через memcpy() (или уже передалали на резерв+коммит?) > системные либы в винде вообще не экспотируют что-то типа mremap там везде > паскалевская нотация и два варианта функций с уникодом и без (W > / A), а еще STDCALL, там свое апи Не надо путать конвенцию вызова (Pascall там нет, в 32-х разрядной Windows была stdcall и в редких случаях fastcall) и предоставляемые системные сервисы (API). Ближайшим аналогом mmap() является NtMapViewOfSection() или обёртка над ней VirtualAllocEx() из Win32 API. То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос, транслятор выдаст рабочий exe-шник, при инициализации процесса он слинкуется с чем надо. C mremap() так просто не получится (работать будет, но не так быстро как в Linux). > и ты вообще не туда полез, я говорю что заголовочные файлы для > сишки "фактически" описывают таблицу экспорта конкретных либ, и сами по себе > не имеют смысла Не знаю, кто куда полез, но вот первое попавшееся "описание таблицы экспорта" #define malloc(foo) HeapAlloc(GetProcessHeap(), HEAP_NO_SERIALIZE, foo)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	50. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от penetrator (?), 04-Фев-24, 19:33
	> в 32-х разрядной Windows была stdcall а в 64 битной по-другому? ясно понятно ))))))) #define WINAPI __stdcall > То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос это не означает, что не будет таких функций которые нельзя заинлайнить через макрос и им не нужна библиотека A header file is a file with extension .h contains C function declarations and macro definitions. Все что не макрос (константа и бла бла бла), то декларация экспортируемой функции библиотеки, для которой этот хидер файл написан. Азы сей... нах это жевать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	53. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от n00by (ok), 05-Фев-24, 16:42
	>> в 32-х разрядной Windows была stdcall > а в 64 битной по-другому? ясно понятно ))))))) Да как бы не до смеху. Набрать в поисковике "windows 64 calling convention" и прочитать The first four arguments are placed onto the registers. That means RCX, RDX, R8, R9 (in that order) for integer, struct or pointer arguments, and XMM0, XMM1, XMM2, XMM3 for floating point arguments. Additional arguments are pushed onto the stack (right to left). В fastcall использовались первые два регистра из списка. В __stdcall всё идёт через стек. > #define WINAPI __stdcall Это откуда и к чему? >> То есть mmap() можно реализовать в заголовочном файле как inline функцию или макрос > это не означает, что не будет таких функций которые нельзя заинлайнить через > макрос и им не нужна библиотека Я вот реально не пойму, что тут написано. Какая библиотека? Вот реализация стандартной библиотеки плюсов (в т.ч. включает и сишную) https://github.com/icestudent/ontl практически всё header-only, которой нужна только ntdll.dll. Так же возможно и POSIX туда добавить. > A header file is a file with extension .h contains C function > declarations and macro definitions. > Все что не макрос (константа и бла бла бла), то декларация экспортируемой > функции библиотеки, для которой этот хидер файл написан. Азы сей... нах > это жевать? И я не знаю, зачем жевать азы, когда есть стандарт. Там, внезапно, не обнаруживается определение термина "header file". Есть понятие единица трансляции, и директива #include может включать в неё что угодно, лишь бы препроцессор прожевал: 6.10.2 Source file inclusion Constraints 1 A #include directive shall identify a header or source file that can be processed by the implementation.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от penetrator (?), 05-Фев-24, 22:32
	из виндового SDK, там всегда был __stdcall в сырцах и для 32-битных функций и 64-битных функций, но есть нюанс, который называется Microsoft x64 calling convention When compiling for the x64 architecture in a Windows context (whether using Microsoft or non-Microsoft tools), stdcall, thiscall, cdecl, and fastcall all resolve to using this convention. ----- ну не понимаешь так не понимаешь
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от n00by (ok), 06-Фев-24, 07:53
	Не понимаю. Будь добр и объясни, зачем ты мне это пишешь? Напомню, что ты начал с "там везде паскалевская нотация". Намекаешь, что понял свою ошибку?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от Александр (??), 03-Фев-24, 00:51
	Не совсем. Windows не совместим с POSIX. Cygwin и msis - это по сути POSIX подсистема и окружение.
	Ответить \| Правка \| К родителю #33 \| Наверх \| Cообщить модератору


	45. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от penetrator (?), 04-Фев-24, 07:11
	> Не совсем. Windows не совместим с POSIX. Cygwin и msis - это > по сути POSIX подсистема и окружение. строго говоря до Windows 8 там была Microsoft POSIX subsystem, потом воткнули WSL но это вообще никак не связано с тем что я написал изначально
	Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+2 +/–
	Сообщение от Аноним (5), 01-Фев-24, 17:56
	> Я всё ещё не понимаю зачем нужен сабж? Почему не собрать нативно? Это неэмулятор линукса. Если какой-то софт поддерживает сборку без линукса, то, как правило, он оказывается менее функциональным в таком виде. И с кучей особенностей. В msys2 к примеру, всгда было разделение, что-то можно собрать "нативно", что-то только с прослойкой. А какой-то софт вообще можно собирать не гцц, а майкрософтовскими компиляторами.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	49. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+1 +/–
	Сообщение от Аноним (49), 04-Фев-24, 14:01
	Начни читать отсюда: https://ru.wikipedia.org/wiki/POSIX Windows - это не 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 в дистрибутивах линукс, сформировать кусочек ОС в префиксе и поставить кучу софта.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Выпуск Cygwin 3.5.0, GNU-окружения для Windows "	+/–
	Сообщение от EULA (?), 05-Фев-24, 07:17
	Никто не мешает через Cygwin сменить права POSIX на файлы в NTFS или процессы, и в итоге System не будет иметь возможности что-то сделать с файлом или процессом.
	Ответить \| Правка \| Наверх \| Cообщить модератору