Компания Red Hat опубликовала стабильный релиз пакета Cygwin 3.5.0, включающего DLL-библиотеку для эмуляции базового Linux API в Windows, позволяющую с минимальными изменениями собирать созданные для Linux программы. В пакет также входят непосредственно собранные для выполнения в Windows стандартные Unix-утилиты, серверные приложения, компиляторы, библиотеки и заголовочные файлы...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60535
> Разрешён доступ к устройствам консолей (/dev/consN) из процессов, присоединённых к другим консолям или pty-терминалам. Изменение позволило обеспечить возможность запуска в консоли утилит GNU screed и tmux.Либо я что-то не понимаю, либо... короче, я сто лет юзаю msys2 и там tmux всегда работал
Держи плюс, приятель.Но по теме, msys и cygwin - это вроде проекты-конкуренты, не? (я не очень в теме)
Спс :) Да я тож хз, но мне казалось, что msys2 ющает сингвинские либы
>мне казалось, что msys2 ющает сингвинские либыНе совсем. В репозиториях есть разные пакеты, которые зависит от типа рантайма, в котором это добро и запускается. Есть и с сигвиновскими либами, и напрямую скомпиленные под Винду, и даже варианты, собранные через компиляторы от самих мелкомягких (насколько я помню).
Когда-то давно msys отделились от cygwin из-за разных целей. Cygwin в максимальную совместимость, msys в меньшую монструозность. Я думаю с тех времён что-нибудь и осталось.
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.
Нет поддержки Windows XP? В топку!
Я тоже считаю, что это полное безобразие.Кому он нужен такой?
XP x64 прекрасно поддерживает сколько угодно памяти, а также полностью поддерживает unicode.А свои "инновации" ... придержите до лучших времён.
Объективно любой код тех времён максимально проблемный. Да-да, в то время как как раз и начали прозревать.
Мозг просит подробностей.
Ты действительно считаешь, что в коде Win 12 меньше проблем чем в семерке?
> Ты действительно считаешь, что в коде Win 12 меньше проблем чем в
> семерке?Всё так. Я действительно считаю, что 12 менее уязвима для малвари и содержит меньше деструктивных багов, таких как рассыпание MFT. А так же 12 более производительна, работает с современным железом, и, не самое последнее, нормально подерживает юникод. Конечно же, современные технологии тоже. Ещё не деградирует так сильно при обновлениях, но это уже не актуально.
На всякий случай напомню, что XP всего лишь на три года младше Win98.
Даже простая работа, на уровне консольного приложения, в ХП, 7ке, и 10ке прилично отличается.
И даже если без Цигвина желать приложение, то тут или не использовать весьма полезные новшества, или писать херовое ПО под ОС начала века.
Так, пока мы далеко в API не лезли, и речь была и простом консольном приложении.Очевидное решение ограничиться поддержкой Windows10+.
(Про Win8.1 понятия не имею)
Я всё ещё не понимаю зачем нужен сабж? Почему не собрать нативно?
я может что-то не понял, но разве нативный код не зависит от хидеров, который есть только в линухе? кто будет это транслировать в Win32 API?
> я может что-то не понял, но разве нативный код не зависит от
> хидеров, который есть только в линухе? кто будет это транслировать в
> Win32 API?mingw-w64 как раз и является прослойкой хидеров, сабж дополнительная либа-прослойка неэмулятора линукс и репозитории собранных файлов. Дело не в хидерах, а в недоступных апи в либц венды.
так хидеры фактически описывают таблицу экспорта, те же шары вид сбоку
Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и эмулирует её через memcpy() (или уже передалали на резерв+коммит?)
> Так в Windiws системные dll не экспортируют например mremap(). Вот Cygwin и
> эмулирует её через memcpy() (или уже передалали на резерв+коммит?)системные либы в винде вообще не экспотируют что-то типа mremap там везде паскалевская нотация и два варианта функций с уникодом и без (W / A), а еще STDCALL, там свое апи
и ты вообще не туда полез, я говорю что заголовочные файлы для сишки "фактически" описывают таблицу экспорта конкретных либ, и сами по себе не имеют смысла
>> Так в 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)
> в 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.
Все что не макрос (константа и бла бла бла), то декларация экспортируемой функции библиотеки, для которой этот хидер файл написан. Азы сей... нах это жевать?
>> в 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.
из виндового SDK, там всегда был __stdcall в сырцах и для 32-битных функций и 64-битных функций, но есть нюанс, который называется Microsoft x64 calling conventionWhen 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.
-----
ну не понимаешь так не понимаешь
Не понимаю. Будь добр и объясни, зачем ты мне это пишешь? Напомню, что ты начал с "там везде паскалевская нотация". Намекаешь, что понял свою ошибку?
Не совсем. Windows не совместим с POSIX. Cygwin и msis - это по сути POSIX подсистема и окружение.
> Не совсем. Windows не совместим с POSIX. Cygwin и msis - это
> по сути POSIX подсистема и окружение.строго говоря до Windows 8 там была Microsoft POSIX subsystem, потом воткнули WSL
но это вообще никак не связано с тем что я написал изначально
> Я всё ещё не понимаю зачем нужен сабж? Почему не собрать нативно?Это неэмулятор линукса. Если какой-то софт поддерживает сборку без линукса, то, как правило, он оказывается менее функциональным в таком виде. И с кучей особенностей. В msys2 к примеру, всгда было разделение, что-то можно собрать "нативно", что-то только с прослойкой. А какой-то софт вообще можно собирать не гцц, а майкрософтовскими компиляторами.
Начни читать отсюда: 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 в дистрибутивах линукс, сформировать кусочек ОС в префиксе и поставить кучу софта.
Никто не мешает через Cygwin сменить права POSIX на файлы в NTFS или процессы, и в итоге System не будет иметь возможности что-то сделать с файлом или процессом.
FreeBSD пишется под macOS, а Linux - под виндой. Всё, что нужно знать о стремлении этих людей делать десктопные ОС.
>Выпуск примечателен прекращением поддержки Windows 7И эти туда же. Ну и чем мешало? Опять красношапка со своим запланированным устареавнием. Ничему, что они касаются, доверять нельзя.
В чем проблема обновить древнюю ОС? И что мешает поставить Linux в dual boot, и дальше пользоваться своим nero burning rom, и решать современные задачи?
В том, что виндовс 7 используется как ось для виртуалки, чтобы с минимальными затратами оперативки запускать виндовс-онли программы. Раньше использовалась XP, которая жрала в три раза меньше памяти, но её софт перестал поддерживать.Новая ось в виртуалке нафиг не нужна.
а зачем вам в виртуалке цигвин? Нельзя обрабатывать ввод/вывод вин-онли программы на хосте?
Windows 7 официально EoL с 14 января 2020, о чём MS заявила ещё в момент выпуска семёрки. Зачем проекту поддерживать то, что 4 года не поддерживается производителем? И как именно в этом виноват Ред Хат? Не говоря уже о том, что старые версии у тебя никто не отбирает и они дальше будут работать как работали.
Если бы и "поддерживалось", то толку с того, у 7ки API прилично другое.
И тут или забить на старое, или игнорировать новое. Выбор очевиден.
> Windows 7 официально EoL с 14 января 2020, о чём MS заявила
> ещё в момент выпуска семёрки. Зачем проекту поддерживать то, что 4
> года не поддерживается производителем? И как именно в этом виноват Ред
> Хат? Не говоря уже о том, что старые версии у тебя
> никто не отбирает и они дальше будут работать как работали.поддерживалась до 1 января 2023 года клиент, и 2024 года сервер 2008 R2, но все за денежку
Я вот чего не понимаю. Если вы сидите на системе пятнадцатилетней давности, чем вас не устраивает Cygwin пятнадцатилетней давности?
Зачем оно, если есть WSL, а там где его нет, теперь нет и Cygwin ??
>там где его нет, теперь нет и CygwinНе дождетесь, все там есть. WSL нужен детям на ворованной винде.
Чтобы что?
>WSL нужен детям на ворованной винде.WSL спокойно работает из коробки даже в Windows Home Single Language. Ибо начиная ещё с Win10 18xx Hyper-V разделили на 2 части - "платформу виртуализации Windows" (виндовый аналог KVM/Xen), и непосредственно саму Hyper-V (теперь уже как аналог Virt-Manager для этой самой "платформы виртуализации"). И вот первое спокойно работает и на Windows Home, вместе с WSL, Docker Desktop, и прочими плюшками, из коробки, и на 100% легально.
Порой запускать виртуалку ради запуска небольших приложений не очень хорошая идея
Эта «виртуалка» пошустрее сабжа работает.
Да установите уже Linux !
За это не платят.
Желающих пользоваться поделиями фридрисктоп.орг всё меньше и меньше.
Так это Red Hat разрабы, я то всё думал почему оно на моей машине не заводится. Теперь всё встало на свои места.
В винде давно есть WSL, Cygwin был нужен скорее на 7-ке.