4 ms·

Hadn't seen this until now. This project looks great. As someone who has mostly used the MSVC environment on Windows, can you comment on how often Cygwin allow

by jclay 8y ago

Hadn't seen this until now. This project looks great. As someone who has mostly used the MSVC environment on Windows, can you comment on how often Cygwin allows for a Linux port to compile and run with no source changes? I read a while back that the fork "emulation" is a performance hit. I wonder if Cygwin benefited from the WSL fork implementation [0] 0. https://news.ycombinator.com/item?id=11391797 https://news.ycombinator.com/item?id=11391797

rbanffy 8y ago
I never distributed my binaries to other Windows users - I merely used Cygwin to get a familiar Unix environment on Windows since 2007 or so. Everything worked seamlessly. I remember compiling multiple versions of Python using it.
- kazinator 8y ago
  Cygwin used to be GPL-ed, so there was a licensing hurdle. You couldn't legally do this kind of redistribution with proprietary programs, only with GPL-compatible programs. Two or three years ago there was an announcement on the mailing list that Cygwin it's switching to the LGPL. I kicked off the Cygnal project that very day, pretty much.
  - rurban 8y ago
    Not really. cygwin (the DLL) is MIT and cannot use any GPL sources. Hence most of the libc is taken from FreeBSD.
    - kazinator 8y ago
      The Cygwin DLL is based on something called Newlib from BSD, but it contains considerable new code from the Cygwin project. As a whole, it is LGPL-ed, with a special exception that also allows static linking. https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/CYGWIN_LICENSE;h=dba58e8dbfb2a9e833d8a05b9f8cfdf808e0f992;hb=HEAD https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob...
      - rurban 8y ago
        I missed that LPGL switch in 2016, but I obviously mixed that up somehow. We never could use any GPL sources in newlib, hence it was always far behind other libc's. And the biggest problem gone seems to be the mandatory CLA. But nowadays cygwin lost it's dominant role from a decade ago.
- aurora72 8y ago
  Cygwin is the pioneer in Unix on Windows but it's been superseded by the MSYS2. I say this with caution though: MSYS2 is inspired by the Cygwin. But it's just more authentic because you use real Windows applications doing Unix jobs.
  - rbanffy 8y ago
    Looks cool. I'm, however, very happy no attempt to make me use Windows was made since 2008 or so and, therefore, I didn't have much use for either system.
  - flukus 8y ago
    How does MYSYS2 supersede cygwin? From the wiki (https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-fr...) that's not really clear: > Cygwin tries to bring a POSIX-compatible environment to Windows so that most software that runs on unices will build and run on Cygwin without any significant modifications. Cygwin provides a large collection of packages containing such software, and libraries for their development. > MSYS2 tries to provide an environment for building native Windows software. MSYS2 provides a large collection of packages containing such software, and libraries for their development. As a large portion of the software uses GNU build tools which are tightly coupled to the unix world, this environment is also POSIX-compatible, and is in fact based on Cygwin. For someone that uses cygwin (still on windows 7) heavily everyday what benefit would I get from MYSYS2?
    - kazinator 8y ago
      > MSYS2 tries to provide an environment for building native Windows software. And that is pretty darn useless. People writing for Windows fall into two camps: FOSS people (and perhaps proprietary SW people also) who develop on Linux and Macs using POSIX API's. They need decent POSIX for porting the programs to Windows more easily. And then we have people who develop for Windows. They use Microsoft Visual Studio. Windows is proprietary; the idea that you need some free tools to write code that only works on a proprietary OS is absurd. Visual Studio with basic features can be obtained free-as-in-beer. The last time I developed a Windows-only program, I just used VS2008. Cygwin provides a decent POSIX porting experience to Windows. My "Cygnal" project, consiting of a small number of patches to Cygwin, allows programs ported to Windows via Cygwin to have more Windows-like personality. For path handling is Windows-style: drive letter names work, "currently logged directory" (per drive) works. The system() function in Cygnal uses cmd.exe, not /bin/sh, and even programs that try to fork and exec /bin/sh (reimplmeenting their own system, effectively) are redirected to cmd.exe. The PATH environment variable is semicolon-delimited; no conversion takes place on env vars. Various little things like this are fixed. And you don't have to rebuild anything; just compile a program for Cygwin, then deploy it with the patched cygwin1.dll. Programs can easily detect which one they are running with, in case it's useful to provide some alternative logic. The MinGW family provide a good solution for programs that are highly platform-independent, like certain kinds of "non-POSIX-heavy" utilities.
kazinator 8y ago
Not all programs need to fork, obviously. Programs that fork and immediately exec can be improved under Cygwin by using the spawn, family of system calls, like what I have here: http://www.kylheku.com/cgit/txr/tree/stream.c http://www.kylheku.com/cgit/txr/tree/stream.c in this source file there is a version of the run function that uses _wspawnvp, support for which is detected in my ./configure script. Well, _wspawnlp, but they're in the same family: printf "Checking for _wspawnlp ... " cat > conftest.c <<! #include "config.h" #include <process.h> #include <wchar.h> int main(int argc, char **argv) { wchar_t *wargv[] = { L"foo", L"bar", 0 }; int r = _wspawnlp(_P_WAIT, L"foo", wargv); return 0; } ! if conftest ; then printf "yes\n" printf "#define HAVE_WSPAWN 1\n" >> config.h else printf "no\n" fi The porting experience of Unix and Linux programs to Cygwin is pretty darn good. You can tell just from the large number of packages that are available under Cygwin. Even programs that use termios to put the TTY in raw mode and use ANSI escape sequences to control the screen work in Cygwin. Cygwin's I/O system contains a layer that translates ANSI codes to Win32 Console API calls. This works inside the Windows CMD.EXE console, not only the Cygwin terminall.
- ygra 8y ago
  > inside the Windows CMD.EXE console You have a typo in conhost.exe there. The Windows console has native support for those escape sequences by now too, though.
jijji 8y ago
I remember doing C development and noticing performance issues when using the posix functions versus the win32 api equivalent functions...
- kazinator 8y ago
  There is a layer there. The POSIX API's in Cygwin drive a framework of C++ objects, underneath which are ultimately Win32 functions. So that's not going to be faster than just those Win32 functions. The Win32 functions are available to Cygwin programs.
rurban 8y ago
When I had to work under Windows I maintained >200 cygwin packages. Only about 10% needed trivial fixes for linux'isms or BSD'isms. fork has its own implementation, cygwin is entirely unrelated to WSL (as before the Interix subsystem). It's extremely slow though. WSL or mingw are much faster. But mingw is a pain.
- kazinator 8y ago
  MinGW has a fork function? Maybe that newer MinGW-W64 project or whatever it is called. The original MinGW that just links programs to the system library called MSVCRT.DLL. It provides POSIX porting only the extent of the meagre support for a few POSIX functions in MSVCRT.DLL. That has things like open, read and dup2, and a half-baked stat and such.
  - rurban 8y ago
    No, only cygwin (and WSL) can emulate fork, mingw needs the slower spawn, without COW. Or mingw programs emulate fork via threads.

by jclay 8y ago

rbanffy 8y ago

I never distributed my binaries to other Windows users - I merely used Cygwin to get a familiar Unix environment on Windows since 2007 or so. Everything worked seamlessly. I remember compiling multiple versions of Python using it.

kazinator 8y ago
Cygwin used to be GPL-ed, so there was a licensing hurdle. You couldn't legally do this kind of redistribution with proprietary programs, only with GPL-compatible programs. Two or three years ago there was an announcement on the mailing list that Cygwin it's switching to the LGPL. I kicked off the Cygnal project that very day, pretty much.
- rurban 8y ago
  Not really. cygwin (the DLL) is MIT and cannot use any GPL sources. Hence most of the libc is taken from FreeBSD.
  - kazinator 8y ago
    The Cygwin DLL is based on something called Newlib from BSD, but it contains considerable new code from the Cygwin project. As a whole, it is LGPL-ed, with a special exception that also allows static linking. https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/CYGWIN_LICENSE;h=dba58e8dbfb2a9e833d8a05b9f8cfdf808e0f992;hb=HEAD https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob...
    - rurban 8y ago
      I missed that LPGL switch in 2016, but I obviously mixed that up somehow. We never could use any GPL sources in newlib, hence it was always far behind other libc's. And the biggest problem gone seems to be the mandatory CLA. But nowadays cygwin lost it's dominant role from a decade ago.
aurora72 8y ago
Cygwin is the pioneer in Unix on Windows but it's been superseded by the MSYS2. I say this with caution though: MSYS2 is inspired by the Cygwin. But it's just more authentic because you use real Windows applications doing Unix jobs.
- rbanffy 8y ago
  Looks cool. I'm, however, very happy no attempt to make me use Windows was made since 2008 or so and, therefore, I didn't have much use for either system.
- flukus 8y ago
  How does MYSYS2 supersede cygwin? From the wiki (https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-fr...) that's not really clear: > Cygwin tries to bring a POSIX-compatible environment to Windows so that most software that runs on unices will build and run on Cygwin without any significant modifications. Cygwin provides a large collection of packages containing such software, and libraries for their development. > MSYS2 tries to provide an environment for building native Windows software. MSYS2 provides a large collection of packages containing such software, and libraries for their development. As a large portion of the software uses GNU build tools which are tightly coupled to the unix world, this environment is also POSIX-compatible, and is in fact based on Cygwin. For someone that uses cygwin (still on windows 7) heavily everyday what benefit would I get from MYSYS2?
  - kazinator 8y ago
    > MSYS2 tries to provide an environment for building native Windows software. And that is pretty darn useless. People writing for Windows fall into two camps: FOSS people (and perhaps proprietary SW people also) who develop on Linux and Macs using POSIX API's. They need decent POSIX for porting the programs to Windows more easily. And then we have people who develop for Windows. They use Microsoft Visual Studio. Windows is proprietary; the idea that you need some free tools to write code that only works on a proprietary OS is absurd. Visual Studio with basic features can be obtained free-as-in-beer. The last time I developed a Windows-only program, I just used VS2008. Cygwin provides a decent POSIX porting experience to Windows. My "Cygnal" project, consiting of a small number of patches to Cygwin, allows programs ported to Windows via Cygwin to have more Windows-like personality. For path handling is Windows-style: drive letter names work, "currently logged directory" (per drive) works. The system() function in Cygnal uses cmd.exe, not /bin/sh, and even programs that try to fork and exec /bin/sh (reimplmeenting their own system, effectively) are redirected to cmd.exe. The PATH environment variable is semicolon-delimited; no conversion takes place on env vars. Various little things like this are fixed. And you don't have to rebuild anything; just compile a program for Cygwin, then deploy it with the patched cygwin1.dll. Programs can easily detect which one they are running with, in case it's useful to provide some alternative logic. The MinGW family provide a good solution for programs that are highly platform-independent, like certain kinds of "non-POSIX-heavy" utilities.

kazinator 8y ago

Not all programs need to fork, obviously. Programs that fork and immediately exec can be improved under Cygwin by using the spawn, family of system calls, like what I have here: http://www.kylheku.com/cgit/txr/tree/stream.c http://www.kylheku.com/cgit/txr/tree/stream.c in this source file there is a version of the run function that uses _wspawnvp, support for which is detected in my ./configure script. Well, _wspawnlp, but they're in the same family: printf "Checking for _wspawnlp ... " cat > conftest.c <<! #include "config.h" #include <process.h> #include <wchar.h> int main(int argc, char **argv) { wchar_t *wargv[] = { L"foo", L"bar", 0 }; int r = _wspawnlp(_P_WAIT, L"foo", wargv); return 0; } ! if conftest ; then printf "yes\n" printf "#define HAVE_WSPAWN 1\n" >> config.h else printf "no\n" fi The porting experience of Unix and Linux programs to Cygwin is pretty darn good. You can tell just from the large number of packages that are available under Cygwin. Even programs that use termios to put the TTY in raw mode and use ANSI escape sequences to control the screen work in Cygwin. Cygwin's I/O system contains a layer that translates ANSI codes to Win32 Console API calls. This works inside the Windows CMD.EXE console, not only the Cygwin terminall.

ygra 8y ago
> inside the Windows CMD.EXE console You have a typo in conhost.exe there. The Windows console has native support for those escape sequences by now too, though.

jijji 8y ago

I remember doing C development and noticing performance issues when using the posix functions versus the win32 api equivalent functions...

kazinator 8y ago
There is a layer there. The POSIX API's in Cygwin drive a framework of C++ objects, underneath which are ultimately Win32 functions. So that's not going to be faster than just those Win32 functions. The Win32 functions are available to Cygwin programs.

rurban 8y ago

When I had to work under Windows I maintained >200 cygwin packages. Only about 10% needed trivial fixes for linux'isms or BSD'isms. fork has its own implementation, cygwin is entirely unrelated to WSL (as before the Interix subsystem). It's extremely slow though. WSL or mingw are much faster. But mingw is a pain.

kazinator 8y ago
MinGW has a fork function? Maybe that newer MinGW-W64 project or whatever it is called. The original MinGW that just links programs to the system library called MSVCRT.DLL. It provides POSIX porting only the extent of the meagre support for a few POSIX functions in MSVCRT.DLL. That has things like open, read and dup2, and a half-baked stat and such.
- rurban 8y ago
  No, only cygwin (and WSL) can emulate fork, mingw needs the slower spawn, without COW. Or mingw programs emulate fork via threads.