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]
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
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
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.
You have a typo in conhost.exe there. The Windows console has native support for those escape sequences by now too, though.
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.
https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob...
But nowadays cygwin lost it's dominant role from a decade ago.
> 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?
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.
The idea behin MSYS was to create a stripped down Cygwin that doesn't provide a complete Unix or Linux-like environment on Windows, but provides only a toolchain: compilers and some common tools for building programs. That toolchain cross-compiles programs to Windows, using the system library MSVCRT.DLL as their run-time. That toolchain, supported by the MSYS run-time, is called "MinGW". MinGW-copmiled programs are not MSYS programs. MSYS is not so easy to extend.
The MinGW toolchain (or rather just its compilers) are available under Cygwin as a package. If you want to build MinGW programs, Cygwin with the MinGW package is a way better way to go: you can easily use any build tool that you need. Adding new utilities to Cygwin is easier than extending MSYS. You have the host environment there with the host compiler. Does your MinGW program need Ninja or CMAKE? or AntLR? Just build them and use them.
MSYS2 is basically more of the same as MSYS, just forking from a newer Cygwin. The cross-toolchain is now called MinGW-Win64 or something. Programs built with this now don't just link to MSVCRT.DLL; there is now some run-time library material, like a package of POSIX threads and whatnot.
MinGW and MinGW64 are not very good systems if your software requires a significant POSIX layer. I couldn't port the TXR Language to Windows using either of these. The Cygnal project is much smarter for this requirement area: about twenty or so well-targeted patches to the Cygwin DLL to bring about more Windows-y behaviors where Cygwin goes overboard with the POSIX simulation.
For instance, one thing that my program needs from the environment is a working POSIX termios: #include <termios.h>, tcsettattr/tcgetattr and so on. Plus working ANSI/VT100 escape sequences.
All that stuff ports to Windows with Cygwin/Cygnal.
The fact that "termios" isn't a "native" component in Windows is a completely immaterial, emotional argument. A Python list comprehension isn't native Windows either, and neither is a C++ std::map.
If my program relies on "termios", then a run-time which provides a faithful rendition of it is more convenient than one where I have to port all that console handling code to use the Win32 Console API.
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.
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.
The Win32 functions are available to Cygwin programs.