4 ms·

MSYS2 makes Windows be less of a special case for C/C++ software development. You can use all your favorite build tools from Linux, and there is a large and gr

MSYS2 makes Windows be less of a special case for C/C++ software development. You can use all your favorite build tools from Linux, and there is a large and growing library of software you can install with the package manager. It's easy to contribute your own packages or improve existing ones by making pull requests to here: https://github.com/Alexpux/MINGW-packages https://github.com/Alexpux/MINGW-packages

srean 11y ago
Yes it helps a whole lot. For me the big conceptual leap was about dynamic libraries (linking, loading and organizing it in the file system). Windows and Linux does them differently and organize them differently.
- RayDonnelly 11y ago
  We adopt that. We buck the "Program Files" silliness, and go all-in for FHS layout and shared libraries.
  - srean 11y ago
    If you don't mind, could you elaborate a little. Not that I could do more than thank and upvote in return. In fact consider those done already.
    - RayDonnelly 11y ago
      Ok, I don't know the level of elaboration you are asking for, so apologies if it I go too far. FHS is just the split up at the top level into bin, lib, include, etc, share as opposed to having a folder called, e.g. MyApplication. Some people hate it, but it allows sharing libraries easily. Apple go for something of a hybrid with Frameworks. MSYS2 goes full Linux-style, even for our mingw-w64 (native) softare. "C:\Program Files\MyApplication" is the complete opposite. No sharing. No good for anyone. Usually software is configured so that at `make install` time it will pull the DLLs of its dependencies beside its executables on Windows, so that, for example a Qt-based game would be packaged with the Qt DLLs in the same folder as the executable. On MSYS2 we disable this code-path (ok, build-system code-path) and adopt the Linux path instead, so that our final package contains only the executable and a record to say "I also need the Qt shared libraries package version 5.5-3". In fact, pacman doesn't allow us to make two packages with the same final files in it since it's a System Package Manager and it disallows such conflicts (unless the packages are marked as conflicting). The other common thing you'll see with Windows software is people compiling and linking to static libraries because it's safer than DLL hell. It might be safer in that regard, but it's a security nightmare for the user (though they often can't know it), so we don't do that either. Our library packages do tend to come with static libraries, but our executables link to shared libraries by default which are also provided. This way, when a security issue is found in a library, we don't need to update a load of packages containing executables that linked to that library statically, since none (or very few, some may slip through by mistake) do.
pjmlp 11y ago
You could say the same about any other OS that isn't GNU/Linux. Windows isn't the only one non POSIX and even POSIX ones do have substantial differences.
- yo-code-sucks 11y ago
  OSX is Posix, as is BSD, Minix, ReactOS, and many more. It's a fucking standard that has existed long before Linux.
- ikurei 11y ago
  I don't know why my sibling comment is dead, but windows is the only non POSIX and UNIX-like still relevant. May be there is a niche non-UNIX OS that I don't know about? OS X is POSIX certified, and Linux and BSD are obviously UNIX-like and mostly compliant. Apart from the precise meaning of POSIX, windows is the only OS in widespread use not part of the UNIX-like family.
  - pjmlp 11y ago
    There are the embedded and mainframe OSes, but I guess they might be considered niche. Not so niche are iOS and Android, which aren't fully POSIX compliant. Then being POSIX compliant is only half of the story, because each OS tends to be certified to specific versions and there is room for implementation specific behaviours. For example, Aix used to have Windows like model for dynamic libraries. OS X and its derivatives have Frameworks and so on. Finally POSIX only applications are constrained to CLI and daemons only, as everything else falls outside POSIX.
    - vetinari 11y ago
      > Finally POSIX only applications are constrained to CLI and daemons only, as everything else falls outside POSIX. That is not a small group, especially as it includes your build environment. In Windows, many times I had a problem that I cannot run ./configure (or worse: the package used a home grown build system that assumed unix-y environment; py2cairo, I'm looking at you), not only because of bash/sed/m4/awk/etc, but also not counting with cl.exe (VS compiler). Side note: OSX has not only frameworks, but also dylibs. You can treat existing framework as dylib, it will link fine.
_yy 11y ago
Does it support hardening flags by now? (ASLR etc.)
- rossy 11y ago
  It does. We build mpv with hardening flags (--dynamicbase, --nxcompat, etc.) and it can build in MSYS2.

srean 11y ago

Yes it helps a whole lot. For me the big conceptual leap was about dynamic libraries (linking, loading and organizing it in the file system). Windows and Linux does them differently and organize them differently.

RayDonnelly 11y ago
We adopt that. We buck the "Program Files" silliness, and go all-in for FHS layout and shared libraries.
- srean 11y ago
  If you don't mind, could you elaborate a little. Not that I could do more than thank and upvote in return. In fact consider those done already.
  - RayDonnelly 11y ago
    Ok, I don't know the level of elaboration you are asking for, so apologies if it I go too far. FHS is just the split up at the top level into bin, lib, include, etc, share as opposed to having a folder called, e.g. MyApplication. Some people hate it, but it allows sharing libraries easily. Apple go for something of a hybrid with Frameworks. MSYS2 goes full Linux-style, even for our mingw-w64 (native) softare. "C:\Program Files\MyApplication" is the complete opposite. No sharing. No good for anyone. Usually software is configured so that at `make install` time it will pull the DLLs of its dependencies beside its executables on Windows, so that, for example a Qt-based game would be packaged with the Qt DLLs in the same folder as the executable. On MSYS2 we disable this code-path (ok, build-system code-path) and adopt the Linux path instead, so that our final package contains only the executable and a record to say "I also need the Qt shared libraries package version 5.5-3". In fact, pacman doesn't allow us to make two packages with the same final files in it since it's a System Package Manager and it disallows such conflicts (unless the packages are marked as conflicting). The other common thing you'll see with Windows software is people compiling and linking to static libraries because it's safer than DLL hell. It might be safer in that regard, but it's a security nightmare for the user (though they often can't know it), so we don't do that either. Our library packages do tend to come with static libraries, but our executables link to shared libraries by default which are also provided. This way, when a security issue is found in a library, we don't need to update a load of packages containing executables that linked to that library statically, since none (or very few, some may slip through by mistake) do.

pjmlp 11y ago

You could say the same about any other OS that isn't GNU/Linux. Windows isn't the only one non POSIX and even POSIX ones do have substantial differences.

yo-code-sucks 11y ago
OSX is Posix, as is BSD, Minix, ReactOS, and many more. It's a fucking standard that has existed long before Linux.
ikurei 11y ago
I don't know why my sibling comment is dead, but windows is the only non POSIX and UNIX-like still relevant. May be there is a niche non-UNIX OS that I don't know about? OS X is POSIX certified, and Linux and BSD are obviously UNIX-like and mostly compliant. Apart from the precise meaning of POSIX, windows is the only OS in widespread use not part of the UNIX-like family.
- pjmlp 11y ago
  There are the embedded and mainframe OSes, but I guess they might be considered niche. Not so niche are iOS and Android, which aren't fully POSIX compliant. Then being POSIX compliant is only half of the story, because each OS tends to be certified to specific versions and there is room for implementation specific behaviours. For example, Aix used to have Windows like model for dynamic libraries. OS X and its derivatives have Frameworks and so on. Finally POSIX only applications are constrained to CLI and daemons only, as everything else falls outside POSIX.
  - vetinari 11y ago
    > Finally POSIX only applications are constrained to CLI and daemons only, as everything else falls outside POSIX. That is not a small group, especially as it includes your build environment. In Windows, many times I had a problem that I cannot run ./configure (or worse: the package used a home grown build system that assumed unix-y environment; py2cairo, I'm looking at you), not only because of bash/sed/m4/awk/etc, but also not counting with cl.exe (VS compiler). Side note: OSX has not only frameworks, but also dylibs. You can treat existing framework as dylib, it will link fine.

_yy 11y ago

Does it support hardening flags by now? (ASLR etc.)

rossy 11y ago
It does. We build mpv with hardening flags (--dynamicbase, --nxcompat, etc.) and it can build in MSYS2.