← Back to context

Comment by radiator

11 hours ago

Nowadays MSYS2, which does depend on cygwin under the hood, offers such a package manager (pacman of Arch Linux) and it is quite a user friendly to run native POSIX binaries on Windows without a linux VM.

7 comments

radiator

Reply
ethin  10 hours ago

In my personal experience, Msys 2 would work great until it didn't. Unless this has changed, from what I remember, Msys2 compiled everything without PIC/PIE, and Windows does allow you to configure, system-wide, whether ASLR is used, and whether it's used "if supported" or always. If that setting is set to anything but off, Msys2 binaries will randomly crash with heap allocation errors, or they do on my system. It happened so much to me when I had actual coreutils installed that I switched to uutils-coreutils even though I knew that uutils-coreutils has some discrepancies/issues. Idk if they've fixed that bug or not; I did ask them once why they didn't just allow full ASLR and get on with things and they claimed that they needed to do non-ASLR compilations for docker.

Dwedit  3 hours ago

MSYS2 is very confusing. When you pick "MSYS2", you are building exclusively for the MSYS2 target environment, and might not have proper compatible windows headers. When you pick "MINGW32/64", you are instead building for the normal windows environment, and get proper windows headers. But if you didn't know that, you would end up confused about why your program is not building.

It doesn't help that the package simply named "gcc" is for the MSYS2 target.

  • jasomill  2 hours ago

    And just to add insult to injury, you probably don't want MINGW64 either, as it relies on the ancient MSVCRT.DLL C runtime library that lacks support for "new" features like C99 compatibility and the UTF-8 locale, and that Microsoft never supported for use by third-party applications in the first place.

    Instead, you either want UCRT64 or CLANG64, depending on whether you want to build with the GNU or LLVM toolchains, as it uses the newer, fully-supported Universal C Runtime instead.

    • Dwedit  1 hour ago

      It's still useful to use MSVCRT in certain circumstances, such as targeting the earliest 64-bit versions of Windows.

      As for UTF-8 support, it's the manifest file that determines whether Windows sets the ANSI code page to UTF-8. (There's also an undocumented API function that resets the code page for GetACP and the Rtl functions that convert ANSI into Unicode. But this would run after all the other DLLs have finished loading.) Having the code page correct is enough to support Unicode filenames and Unicode text in the GUI.

      It just won't provide UTF-8 locale support for the standard C library.

kevin_thibedeau  1 hour ago

It's annoying to wade through six different versions of the same package for different runtimes and word sizes. Heaven forbid you accidentally install the wrong one.

ktm5j  8 hours ago

MSYS2 is my favorite in this area. Super lightweight and easy to use, highly recommend.