3 ms·

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-d

by 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.

by flukus 8y ago

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.