GCC — or even something like Mono — doesn't come with the headers et al for the GUI parts of Windows. And those headers are protected IP, even if you re-derive them from scratch — just ask Google about the JDK!

Certainly, you can compile Hello World with GCC — or maybe even a POSIX network server — to run under WSL. And maybe redistribute the resulting hello_world.exe to other WSL users.

But what happens when you want to compile that same program to run "on Windows" directly, to be redistributable to people who don't have WSL installed?

Well, even if you're using GCC, you'll probably end up linking your program against the Visual C Runtime. (Because otherwise you'll need to ship — or statically link — glibc.dll. Which is a bit ridiculous.) And the Visual C Runtime is... part of Visual Studio! A part that's freely redistributable, yes... for those developers with a valid Visual Studio license. Otherwise, Microsoft can sue you for packaging MSVCRT.DLL with your app.

And as your app gets more complex, that just keeps being truer. While Microsoft Store apps can just list their package deps and get the store to install them, if you're a standalone Windows UI app, you might have to redistribute, say... DirectX. Or SQL Server Embedded. Or even — and this is a very clever trap on Microsoft's part that many FOSS devs don't notice — some "sample library code" from MSDN. All of which are offered under that same redistribution licensing clause.

---

Note that there are high-level "app platforms" that attempt to work around all this — mostly by not having you compile anything to target the Windows native ABI at all — but rather, just providing a higher-level platform abstraction, that you write code against, where that code ships with the executable but not within the executable (so as to keep the executable's Microsoft-stamped code signature intact.) This is how Electron's Windows support works, for example. Also, most game engines, e.g. Unity, Love2d, RenPy, etc.

I believe that there are also a few "app platforms" that go another route, trying to avoid the Windows runtime altogether — using funky low-level static-compiled languages to directly address the NT syscall ABI, and then building up from there to doing multimedia and networking. I think Haxe is like this?

But while Haxe has some level of windows-and-menus UI toolkit (http://haxeui.org/), it's not one that supports OS accessibility APIs (e.g. screen-reader support), or DPI scalability, or high-contrast mode. (In other words, it's just not suitable for writing B2B software where your users are under a bunch of business requirements on what the software they give their employees to use, needs to be able to offer them.)

Also, you're not getting integration with OS file-picker dialogs, or multi-format drag-and-drop / copy-and-paste, or embedding of arbitrary graphical COM components within the view, or — especially — being embedded as a graphical COM component within some other app. (This last one is pretty important for boring line-of-business apps like tax-filing software; you want your app to be able to render its document filetype to the viewport when documents of that type are opened in a browser!)

In short: for making anything that you charge for... you're still gonna just pay Microsoft for Visual Studio.