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)

Ответ на: комментарий от Roy-Batty

Так тут птушники этот ваш рантайм пилят.

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

Ну вообще на этой штуке работает ruby on windows. А ruby on windows нужна для fastlane. А fastlane нужен для сборки мобильного срама на Unity и без него. Так что да. Ниша есть.

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

Для одной-двух утилит ставить wsl не практично. Посмотрел, sygwin.dll только у links.exe и cdd2wav.exe, которыми давно не пользовался.

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

Зачем оно вообще нужно когда есть WSL?

Вообще разные вещи же. WSL — это чтобы линуксовые программы запускать под виндой. Cygwin — просто ещё одна зависимость для нативных виндовых .exe прог.

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

Cygwin — просто ещё одна зависимость для нативных виндовых .exe прог.

Ээээ… а это точно нативные виндовые проги? Так и Wine можно назвать ещё одной зависимостью для нативных линуксовых прог. А чо? Особенно если с winelib собирать.

Алсо, WSL1 позволяет запускать линуксовые проги нативно в венде без прослоек. Там линупсовые системные вызовы прямо в ntoskrnl.exe всунуты (ну, почти). Гораздо нативнее цыгвина выходит.

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

Была же пара тем в толксах.

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

Алсо, WSL1 позволяет запускать линуксовые проги нативно в венде без прослоек. Там линупсовые системные вызовы прямо в ntoskrnl.exe всунуты (ну, почти). Гораздо нативнее цыгвина выходит.

А что они с fork сделали, в ядро добавили, или эмуляция как в Cygwin?

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

Ээээ… а это точно нативные виндовые проги?

Точно. Самые что ни на есть нативные.

Так и Wine можно назвать ещё одной зависимостью для нативных линуксовых прог. А чо?

Нет, нельзя. Wine запускает именно виндовые проги. Его примерным аналогом будет скорее уж WSL1.

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

Гораздо нативнее - mingw.

А еще нативнее - это при разработке использовать кроссплатформенные либы и использовать платформоспецифичный код в частях, которые будут собираться только на этих платформах и обеспечивать нормальную поддержку сборки на linix/win/mac изначально. Тогда необходимость cygwin/mingw/wsl будет стремиться к нулю.

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

Именно затем и нужно, чтобы использовать с mingw, и прога не валилась, например, от того, что абсолютные пути начинаются со слеша, а винда об этом не знает, или встретив fork().

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

mingw требует переписывания программ под себя. Cygwin даёт позволяет собирать нативные программы, если они совместимы с POSIX.

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

А что они с fork сделали, в ядро добавили, или эмуляция как в Cygwin?

Там всё интереснее. Насколько я понял, в ntoskrnl запилили модульный интерфейс для сисколлов, а реализация и вендовых вызовов, и лялексовых сделана через него подключаемыми модулями. Fork там тоже вроде был.

Где-то классная презентация была на эту тему, но я так и не смог её откопать.

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

А еще нативнее - это при разработке использовать кроссплатформенные либы и использовать платформоспецифичный код в частях, которые будут собираться только на этих платформах и обеспечивать нормальную поддержку сборки на linix/win/mac изначально. Тогда необходимость cygwin/mingw/wsl будет стремиться к нулю.

Зачем подстраиваться под тех, кто не следует стандартам? Кому это надо, если можно просто докинуть cygwin в зависимости и писать в соответствии со стандартом, не оглядываясь на винду со «своим особым путём»?

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

Нет, нельзя. Wine запускает именно виндовые проги.

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

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

Так вот и не нужно использовать платформозависымые фичи. А если говорить про слеш «/» в c++ (не знаю, что там в c), то std::filesystem на всех платформах прекрасно работает с прямым слеш «/».

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

Да, но страдает производительность. Лучше пепеписать.

Она «страдает» на уровне погрешности. И переписывать может быть просто никому нахрен не нужно — это трата человеческих ресурсов на систему, которая вообще не должна жить. Хотят на ней пользоваться софтом тем или иным — ну вот вам с cygwin скомпиленное.

А те моменты, где так уж прям критична каждая тысячная процента производительности, никаких posix вызовов и не имеют, там числодробилки какие-нибудь с циклами.

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

Так вот и не нужно использовать платформозависымые фичи.

POSIX — это не платформозависимая фича, это всеобщий стандарт. Ему следуют все, кроме винды. И ради неё изворачиваться ужом никто не будет. Точнее будут те, кому на неё и её юзеров не пофиг. Но многим пофиг, и это правильно.

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

Про какие стандарты речь?

Про POSIX. Хрен с ним со слешем (и речь была не про прямой/кривой, а про то, что если слеш в начале, это абсолютный путь).

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

Про какие стандарты речь? Про прямой слеш на юникс подобных ос? Я уже упомянул про то, как с этим в c++.

Хорошо что никто про RISC OS не вспоминает, где разделителем директорий были точки, а расширение файла шло после /. А то многих тут наверняка шок хватит!

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

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

Я бы сказал полу-нативной.

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

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

Кто сейчас пишет прикладные проги с использованием низкого уровня posix/winapi ? Только может какие то фрагменты. Но при выборе между cygwin и win api я точно выберу второе.

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

Я бы сказал полу-нативной.

Ну тогда и собранное с цыгвином будет полу-нативным. Разве нет?

Другой вопрос, что это не делает его более нужным. Если 20 лет назад он ещё хоть как-то был актуален, то сейчас можно просто закапывать.

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

И если такая библиотека планируется кросплатформенной, то под винду точно не будут делать ее на cygwin.

А что, если она не планируется кроссплатформенной (точнее планируется, но за исключением винды)? По остаточному принципу, «если очень надо, юзайте» пойдёт и cygwin.

Ну и да, я не знаю таких библиотек. Знаю вот, что irssi и rtorrent, например, собираются с cygwin и довольно активно юзаются под виндой без всяких WSL. Разработчикам лишний гемор с поддержкой «нитакихкакфсе» незачем, и это правильно.

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

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

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

Ну тогда и собранное с цыгвином будет полу-нативным. Разве нет?

Ну в какой-то степени да. Только там «эмулируется» намного меньше, чем в winelib, поэтому скорее что-то типа 90%-нативным или типа того ☺

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

Разработчикам лишний гемор с поддержкой «нитакихкакфсе» незачем, и это правильно.

Как бы я и ты не хейтили винду, у нее большая часть рынка. И я выберу для нее именно win api, как более надежную вещь именно для винды.

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

Ну ок, пусть так. Но на винде win api точно надежнее.

Ну естественно, если ставится целью поддержка винды, то надо юзать win api и писать эти моменты два раза, компилируя то или иное в зависисмости от платормы. Никто с этим и не спорит.

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

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

P.S. Думаю, мы смогли прийти к какому-никакому консенсусу.

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

Как бы я и ты не хейтили винду, у нее большая часть рынка.

Такая уж прям большая? Сколько процентов там у Windows Server нынче?

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

P.S. Думаю, мы смогли прийти к какому-никакому консенсусу.

Ну плюс минус так.

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

Хз. Я имел ввиду десктопы.

Ну вот не весь софт и не все серьёзные проекты ориентированы на (или вообще имеют в виду) десктопы ;)

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

WSL не поддерживается ниже Win10/Server 2019

Microsoft в принципе уже тоже.

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

Имхо, некорректное сравнение, либо покушать для, либо неразобравшись в стеке потому чо.

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