Advice to young devs: If you don't have a good professional reason why you absolutely need to use gnu tools on windows, and you have no technical reason not to use Visual Studio, use Visual Studio. It's good enough, and for me, even good.
Your advice would have more weight if you provided some arguments. GNU tools are also good enough, and this kit seems like a lot easier way to get started with your C lab exercise than installing Visual Studio and getting lost in it.
I dislike Visual Studio because to set things up you have to compare online screenshots to your settings and click around multiple tabs of configurations. In the end you (as beginner) don't know what libraries get included and if it will work on another computer. GNU tools are text-driven, so easier to replicate and to reason about.
The GNU tools are not fully compatible with the Windows ABI and they don't support some important Windows features. There are great reasons to use the GNU tools, like compiling unix programs that do not otherwise target Windows.
But you are swimming upstream if you use the GNU tools for general Windows development. Windows is a complex, integrated system that has evolved over a long period of time and is very different from unix-like operating systems. The peculiarities that exist in MSVC and associated tools are not just the whimsies of Microsoft devdiv engineers and product managers, but often tie in to operating system functionality. If you try to develop Windows applications with mingw, you will eventually hit weird problems and errors that simply would not exist if you used Microsoft's toolchain.
If you want an alternative to Microsoft's compiler, then consider llvm, which is aiming for full ABI compatibility and even produces PDBs (though I'm skeptical that they're as complete as the ones generated by Microsoft's tools). But the compatibility is incomplete, so ymmv.
Microsoft seems to aim for deep integration of Linux in Windows per WSL. They even showcased that they are working on Wayland support for WSL, which would enable using Linux GUI applications directly on Windows.
We may soon get at a point where Linux applications feel as native on Windows as native Windows applications (which use quite a variety of toolkits anyway), as the integration deepens.
Now WSL still uses larger distribution images. But very little holds them from supporting thin Linux images with just the necessary dependencies that launches in Windows as any other application.
WSL is more a solution for users that want to have Linux software on Windows. It's not a solution for developers that want to target Windows, which is what I take this thread to be about.
I don't know if it will ever come with a vanilla Windows Home edition install but somehow I doubt that.
Not yet, but I think it is very likely that in the future installing a Linux distribution from the store will automatically install/enable WSL. Micro-distributions with a specific applications are only a small step from there.
I don't see what they have to lose. Windows is still used widely in business. But their lock-in has drastically reduced with the rise of iOS, Android, and web apps. Making Windows more attractive as a platform for developers to deploy applications, even if it is through the WSL subsystem will make Windows as a platform more competitive to these other ecosystems.
I am currently writing scientific software. But we have stopped building Windows versions, since these programs work great with WSL and it is far less effort than building these applications separately with Visual C++.
I write software that's used by human beings in businesses and building for Windows is trivial compared to maintaining additional docs and training material for managing a WSL install on users machines.
I'm currently in a weird spot with the software I distribute because the majority of the users "know enough to be dangerous" but aren't software engineers/IT professionals. We want them running code and using Linux like a pro, but there's a lot of training/documentation overhead just for our *nix builds and the friction to getting that up and running for WSL is daunting.
Luckily MS understands B2B native more than anyone else so I'm hopeful they'll have a solution eventually, but I'm not holding my breath until then.
WSL is more a solution for users that want to have Linux software on Windows. It's not a solution for developers that want to target Windows,
I am not sure what the difference is, when WSL gets deeper and deeper integration with Windows. WSL2 does not use the personality mechanism anymore, but that's just to make it easier to fully support Linux. But once Linux becomes a personality of Windows in the informal sense, targeting Linux means targeting Windows at the same time.
Depends where one is coming from, when I was TA at my university Visual Studio was the official C++ lab exercise tooling for first year students, in Win 9x with student drivers mounted on login.
Sure, visual studio builds have been, and still are up to a point a bit miserable experience.
But not as miserable as trying to use gnu tools for building C++ on windows. I have over a decade of exprience in that and it's always equally painfull.
There were good reasons to use GNU tools when MSVC did not have thorough enough support for C++11 and GCC did. Now MSVC is pretty good with the latest C++ standard.
Besides, Windows now comes with a real posix virtualized environment - Windows subsystem for Linux - which works great - use that, not msys2 or cygwin if you must have a gnu build system on a windows...
You can use VS for C just fine on Windows, VS 2019 has full support for C89 and almost complete C99 support. Next iteration of VS 2019 will even add support for _Generic. But, if you want to write portable code to other operating systems, I suggest to build your code with both VS and GCC.
Install llvm. Clang can use all of MSVC headers without breaking compatibility with its ABI, like MinGW does (you can't mix up DLLs built with the MSVC ABI and the MinGW one)
The only real downside of using MSVC is the mind boggling amount of storage it hogs with libraries you'll never ever use not even once if your goal is to just build simple C++ programs. MinGW might be the only viable approach if you are storage constrained (LLVM/Clang also supports MinGW of course)
I've done my fair share of professionally maintaining portable programs and my preferred choice nowadays is to extract platform independent and platform dependent code to their own libraries and then just implement what is the most out-of-the box simple way to define a build per each platform.
It tries to embrace it, but this is not necessary (and limited for non-trivial cases - and what isn't non-trivial for serious projects). CMake itself has good VS support for a long time. I always try to create VS solutions in parallel with ninja, nmake, jom, whatever completely from it without hand-holding of some integration.
