LINUX.ORG.RU

Red Hat выпустила стабильную версию пакета Cygwin 3.4.0

 ,


0

2

Red Hat опубликовала стабильный релиз пакета Cygwin 3.4.0, который содержит DLL-библиотеку для эмуляции Linux API в Windows. Это позволяет собирать программы, созданные для Linux, с минимальными изменениями. В пакет также входят сборки Unix-утилит, серверных приложений, компиляторов, библиотек и заголовочных файлов, которые можно использовать в Windows.

Выпуск пакета особенно значим благодаря прекращению поддержки 32-разрядных систем и прослойки WoW64, которая используется для запуска 32-разрядных программ в 64-разрядной Windows. Также прекращена поддержка операционных систем Windows Vista и Windows Server 2008. В следующей версии (3.5) планируется прекратить поддержку Windows 7, Windows 8, Windows Server 2008 R2 и Windows Server 2012. Таким образом, в Cygwin 3.5.0 будут поддерживаться только Windows 8.1, Windows 10, Windows 11, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 и Windows Server 2022.

В новом релизе Cygwin 3.4.0 теперь можно запускать исполняемые файлы с рандомизацией адресного пространства (ASLR), которая включена по умолчанию в Cygwin DLL. Также удален специализированный обработчик файлов с расширением «.com». В пакет добавлены новые обработчики, такие как код для обработки вызова setrlimit(RLIMIT_AS) и масок сигналов в /proc//status. Также добавлены обработчики опций сокетов UDP_SEGMENT и UDP_GRO.

По умолчанию теперь установлена опция «CYGWIN=pipe_byte», которая заставляет неименованные каналы работать в байтовом режиме, а не в режиме передачи сообщений. В функциях ввода, определенных в stdio.h, отключены попытки чтения за концом файла (EOF), чтобы сделать поведение более похожим на Linux. Пустой путь в переменной окружения PATH теперь трактуется как указание на текущий каталог, что соответствует поведению в Linux.

>>> Подробности

★★★★☆

Проверено: cetjs2 ()
Последнее исправление: Virtuos86 (всего исправлений: 2)
Ответ на: комментарий от dmitry237

wsl 1 1.0 очень даже разумно, даже с файловой системой оно дружелюбней поступит.

faq2
()

Терпеть не мог Cygwin хоть и приходилось сталкиваться с ним изредка.

К счастью, сегодня оно настолько малопопулярное, что всякие васянские MSYS2/MinGW-W64 с кучей пактов и pacman’ом из Arch Linux заруливают там где этот Cygwin нужен.

Ну а современный WSL вообще ставит всю идею использования Cygwin под сомнения.

EXL ★★★★★
()
Ответ на: комментарий от CrX

или встретив fork()

Если программа, работающаю в ОС Windows, использует fork, то в момент этого самого fork’а должно произойти полное копирование адресного процесса, так как никакого CoW там нет by design. Соответсвтенно, если процесс большой, этот вызов будет адски медленным. Поэтому по возможности софт стараются портировать на винду нативно, а не через cygwin.

annulen ★★★★★
()
Ответ на: комментарий от pihter

В таком, что POSIX-овские fork(), mmap(), ioctl(), и т.д. не реализованы — придётся под win-api переписывать.

CrX ★★★★★
()
Ответ на: комментарий от pihter

Масса библиотек есть, луа всякие..

Причём тут луа?

Ты точно не ошибаешься?

Точно. Собственно для обеспечения POSIX-совместимости Cygwin и нужен.

О как: годами пользуюсь и не знал.

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

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от Mischutka

В некоторых случаях проще развернуть виртуалку целевого дистрибутива нужной версии и разрабатывать в ней. Сам cygwin до недавнего времени имел двойное лицензирование и для коммерческой разработки с его помощью нужно было покупать отдельную лицензию. Зато всегда можно было выкачать заранее все пакеты и доустанавливать из локального репозитория, поставив соответствующие галочки в установщике. Но я им пользовался чуть-чуть в последний раз лет 15 назад.

grem ★★★★★
()
Ответ на: комментарий от CrX

Причём тут луа?

Ну как пример всякого-этакого, что есть ( точнее, его в MCE не было – я его сам собираю для винды )

Точно. Собственно для обеспечения POSIX-совместимости Cygwin и нужен.

Да. Я уже погуглил. Спасибо за ответ

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

Да самописное. Но у меня – векторный графический редактор и всякое станкокодогенерирование, fork был не нужен :) отдельно для винды пришлось только работу с последовательным портом писать – но тут понятно почему. А так – весь GTK, Lua – без проблем. Ну и куча ГТК-зависимостей – все собирается mingw-шкой. Я даже не знал что на винде аналога форка нет..

pihter ★★★★★
()
Последнее исправление: pihter (всего исправлений: 1)
Ответ на: комментарий от CrX

Да, пожалуй. Я-то по наивности думал что можно просто на виндовом АПИ реализовать линуксовые вызовы и для компилируемой программы сие пройдет незаметно, ну что ж, век живу – век учусь

pihter ★★★★★
()
Ответ на: комментарий от token_polyak

Да, это похоже на то что я видел.

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от rumgot

Для серьезных проектов в здравом уме выбрать cygwin вместо win api - это нужно иметь очень высокую степень авантюрности.

Вообще-то, виндовое прикладное ПО на голом API уже сто лет как почти никто не пишет. То есть реальный выбор — между абстракцией, прибитой гвоздями к винде, и абстракцией кроссплатформенной (это даже если не брать тех, кто этим вообще не заморачивается и суёт браузер в программу, а их с каждым годом всё больше).

И в этих условиях, по-моему, выбор очевиден.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

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

Например какие нибудь либы для работы с сетью используют на низком уровне более нативное api на каждой платформе.

rumgot ★★★★★
()
Ответ на: комментарий от hobbit

между абстракцией, прибитой гвоздями к винде, и абстракцией кроссплатформенной

Еще вопрос в том, что cygwin имеет снижение в производительности, а также большой вопрос к надежности и поддержке, учитывая, что это не официальное api.

rumgot ★★★★★
()
Последнее исправление: rumgot (всего исправлений: 1)
Ответ на: комментарий от Bass

Git для Windows.

Кстати бесит, что эти гениусы так и не осилили сделать нормальный git клиент под винду. Надо всякое дерьмо тянуть в виде msys2 или работать в wsl.

cocucka ★★★★☆
() автор топика
Ответ на: комментарий от token_polyak

мне для MSYS2 )

Просто хочется под пару проектов сборку вести под линуксом.

В том числе под вин32. И как минимум 1 из проектов имеет особенности не сильно способствующие кросс-компиляции )

Slackware_user ★★★★★
()
Ответ на: комментарий от AVL2

Официально, насколько я знаю не до конца умер, а учитывая политику некрософта, жить оно будет чуть ли не дольше чем cygwin, т.к. уже оно попало в стабильную версию 1.0.

faq2
()
Ответ на: комментарий от anonmyous

Для кросскомпиляции есть mingw, про cygwin хз, можешь его под вайном поставить (шутка).

cocucka ★★★★☆
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.