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.
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.
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.
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.
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.
Sure, or older 32-bit versions of Windows for that matter, or for building software that hasn't been ported to UCRT.
I can certainly relate to this: I'm currently sitting on a request for an enhancement to a product (currently running on a 32-bit Windows 10 VM) with a build system that has never been updated to support any Microsoft platform other than MS-DOS, or toolchain newer than Microsoft C 5.1.
> lacks support for "new" features like C99 compatibility
This made me laugh. It reminded me of course work I did in university that was clearly written many years before I took the course as it recommended we manually enable the "new" c99 standard in our compiler, which I guess survived in the documentation up through when I took the course, at which point it was still relevant since GCC was otherwise defaulting to C11 by the time I was using it.
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.
Maybe they could find another way to market it, e.g. Windows is free but with ads, and there is a subscription which makes ads go away. Or something else. Some creativity is needed.
> We're all morons outside of some very narrow areas of expertise
speak for yourself, I guess? Some people know things in many areas. But even if they are not experts outside of their areas of expertise, they may recognize their limitations in other areas and thus avoid making costly mistakes. This may even be the rule for adults, rather than the exception.
Yes. You work 2 hours less, but what do you produce in those two extra hours? Can you say that your company now spends X dollars less or earns X dollars more? I don't think it can be that clear.
And what is your theory? That it’s better to not save those 2 hours since they will just go to waste anyway? Or that there is diminishing returns to saving work as people will tend to just spend longer on other things they were already doing? How can you be sure those 2 hours will not actually be used by most to do very productive things that in the end look like +4 hours in return??
There exists a relevant, even German, quote:
“Never believe anything in politics until it has been officially denied.”
― Otto von Bismarck (first chancellor of Germany from 1871 to 1890)
But isn't that the whole point, that foreign governments perhaps do not want Microsoft to host all their data, users, groups, software on Azure, because then the CIA also might obtain access?
Ah, the magic times when screen resolutions were large enough to display lots of information, in proper 4:3 aspect ratio, just before they got flattened and the industry started treating them as short view distance TVs.
Look at how conveniently you chose to ignore the fan's age, attributing his behaviour to unwilling or luddite! Or do you really have absolutely no idea, what it means to be 81 years old? Still, I would bet you have met at least some people of such an age.
reply