55

Traditionally MSYS bash has been considered inferior to Cygwin bash. The former was an ancillary tool inside MinGW intended for running autoconf scripts. But now there is MinGW-w64 and MSYS2. The latter ships with a sweet pacman like package manager and elegant shells like zsh, so I wonder if there is still a gap in the emulation layer.

While MinGW* applications are Windows native executables, MSYS2 software requires a POSIX-emulation layer, just like Cygwin does. At least to a casual user, it is hard to spot the differences between the two.

  • Which are the functional differences between the two emulation layers (if any)?
  • Which emulation is faster (more efficient)?
antonio
  • 9,285
  • 10
  • 59
  • 113
  • 1
    What kind of benefits are you looking for if not opinions? – Scimonster Sep 10 '14 at 07:37
  • @Scimonster I am looking for technical and implementation details which can make one of the two projects more POSIX compliant and not for personal usage experiences: e.g. project x is based on a `cygwin.dll` or not and not project x uses the cosy pacman installer. I think the latter is just an opinion on what you like. – antonio Sep 10 '14 at 09:45
  • 1
    Curious, I thought that asking how three forks are different from the forked project was too broad: [stackoverflow.com/q/25019057](http://stackoverflow.com/q/25019057/1851270) Since here the asker itself says: "I'm open to any suggestions on improving this question. I feel like it could be better.", I focused only on the latest fork (MSYS2) giving more context. Instead the three-forks questions is legit and mine seems not. – antonio Sep 10 '14 at 10:17
  • 3
    Why is this topic considered too broad when the following question is accepted? http://stackoverflow.com/questions/771756/what-is-the-difference-between-cygwin-and-mingw?rq=1 – David Scott Kirby Mar 09 '16 at 01:28

2 Answers2

67

Traditionally MSYS bash has been inferior, but mostly because Cygwin remained under active development whereas MSYS didn't. MSYS forked from Cygwin version 1.3.3 and never re-synced, whereas MSYS2 resyncs with the Cygwin project regularly.

We don't have a "sweet pacman like package manager", we have as direct a re-compilation of Arch Linux's pacman package manager as we could achieve.

MSYS2 doesn't have cygwin.dll but it does have msys-2.0.dll which does the same thing (and some more besides). Specifically, arguments that look like paths and the PATH env. var are converted to Windows form when running Windows-native software.

As for whether it's slower, I expect there'd be very little difference but MSYS2 would be a tiny amount slower due to the extra conversion work. Then again, chances are you'll run more Windows-native software from within MSYS2 (such as MinGW-w64 compilers) than you would from Cygwin so that'll shift things back in MSYS2's favour.

Ray Donnelly
  • 3,650
  • 1
  • 15
  • 18
  • 24
    It bears mentioning that Ray Donnelly is a MSYS2 developer. So his answer should be considered very reliable. Hopefully in the near future similar information will be added to [msys2.github.io](http://msys2.github.io) or [github.com/msys2](https://github.com/msys2) – antonio Feb 20 '15 at 23:45
  • 3
    There is this on SF: https://sourceforge.net/p/msys2/wiki/How%20does%20MSYS2%20differ%20from%20Cygwin/ – Nick Westgate Mar 30 '16 at 22:42
  • 1
    https://github.com/msys2/msys2/wiki/How-does-MSYS2-differ-from-Cygwin is the updated location of Nick's link. – anishpatel May 15 '17 at 22:22
10

As well as I understand, MSYS2 is a fork of Cygwin with main goal to provide possibility to use MinGW-w64 packages. That goal is achieved at expense of total number of available software. Compare list of that of MSYS2 and Cygwin.

Essentially, that’s all. So while you did not need to compile something under MinGW-w64, you would hardly have any reason to use MSYS2 rather than original Cygwin.

Dmitry Alexandrov
  • 1,586
  • 11
  • 13
  • +1 I see that MSYS2 does not contain `cygwin.dll`. Does this means that its tools are more efficient? If I have source code, targeting Linux (but assume not using X), is Cygwin more likely to build it than MSYS2? – antonio Sep 09 '14 at 22:40
  • 6
    MSYS2 just calls `cygwin.dll` something else. It works the same Cygwin does. Your code is more likely to work with Cygwin than MSYS2. MSYS2 is really isn't meant to create MSYS2 programs other than those that are part of MSYS2. MSYS2 mainly meant to create Windows "native" programs using Unix-like tools. In particular its designed to run GNU autoconf `configure` scripts. – Ross Ridge Sep 10 '14 at 01:04
  • 6
    "while you did not need to compile something under MinGW-w64, you would hardly have any reason to use MSYS2 rather than original Cygwin." - I think you put the cart before the horse! We don't use MSYS2 to use MinGW-w64 or its packages _specifically_. We use MSYS2 to compile native Windows programs via GNU style tools. MinGW-w64 being the compiler is, in a lot of ways, just an implementation detail in this. The reason to use MSYS2 is for its native build system, not its compiler specifically... although, sure, that compiler makes it all possible :-) – underscore_d Apr 23 '16 at 14:10
  • 3
    MSYS2 can compile Windows Python extensions from C++. Cygwin cannot. – Contango Feb 02 '18 at 22:50