All of what you're saying is true of modern Windows; apologies, but I last used Windows in the 98/ME/2000/XP era, and my arguments are based in that era.

Despite things having changed, though, I think "Windows in the before-times" is still a viable precedent to cite in its own right, for Apple's current behavior. IP case-law hasn't changed too much between then and now.

For example: when developing for Windows 98, you needed to ship DirectX, because otherwise there would be no pre-installed version of DirectX — and the average user's internet connection wasn't fast enough to download it in any reasonable amount of time!

And uCRT + WinSxS preloads both exist now, but obviously, neither did before Windows Vista. Before then, you couldn't predict if any MSVCRT was gonna be available, so if you were trying to publish e.g. Apache Server But Running In a Windows Tray Icon With A Little Management Context Menu (a common thing back then, for some reason), then you needed to package the particular MSVCRT your app was compiled with. Which is why you never saw FOSS binary releases for Windows back then; instead, there was the FOSS project, with compilation instructions that involved downloading the right MSVCRT yourself; and then there were random third-party downstream "freeware" releases published on CNet or whatever.

> and no, they're not protected IP (or at least Microsoft never made the claim to the contrary)

They haven't, because there's nothing to gain from them doing so, because they aren't trying to run an ecosystem that has a per-install fee, unlike Oracle ca 2010, Unity last year, or Apple right now. (And they never will, because they're all-in on service fees (Azure) instead.) Without that incentive, Microsoft has every reason to listen to the competing incentive — that of making Windows a platform that's friendly and open to developers, that doesn't force them through this kind of bullshit.

But if, in some hypothetical world, Microsoft were to be charging developers per app install... then Microsoft would likely tell MinGW to stop redistributing "their" headers, so as to force more developers onto the SDK and through that into being install-monitored. And they would have every right (according to current IP case-law) to do so.

They wouldn't have a mandate to do so, mind you — source files, including headers, are copyrighted, not trademarked, so they don't need to enforce their IP rights to keep them. They could simply choose to enforce their copyright against only the most egregious violators: those who are clearly making millions of dollars off the use of their platform, without paying them a dime. As Apple is trying to do now!

I did some basic C/C++ development back in the Windows 2000/XP era. I never needed to pay for a Visual Studio license, I didn't even use Visual Studio. I was hacking things together in notepad and gcc at the time.

I did years of development work against Windows machines before I got my first paid Visual Studio license, and it was still like a couple years until the first time I bothered actually installing the Windows SDK.

> And they would have every right (according to current IP case-law) to do so.

Actually, the result of the Google v Oracle case was ultimately that what Google was doing constitutes fair use - and what MinGW is doing is even more clearly in the fair use zone than what Google was doing. So, current IP case-law is firmly on the side of "copying APIs for interoperability is fair use".

MSVCRT.DLL has been an OS component since Win2000. But, as noted earlier, you never needed a CRT to write Win32 apps. Indeed, it was not uncommon especially in the 98/XP era for apps to be written directly against Win32 API (or with very thin wrappers like ATL and WTL; I did my share of that even as late as 00s). And even then pretty much all alternative toolchains, including C++ ones (notably, Borland C++), used their own runtimes anyway. The actual shared platform was always Win32, and there was never any sort of charge, direct or indirect, for using it.

The main reason why people shipped their own version of the CRT for VC++ was because they wanted to use a more modern version of VC++ itself (e.g. because of better support of new language features; C++ was just standardized then and all compilers were updating very rapidly to catch up), which then required a new version of the CRT that wouldn't be guaranteed by the lowest target OS version. But even VC++ did not require you to use the CRT; you could just #include <windows.h> and linker had a flag to drop stdlib.

And even when you wanted to use MSVCRT while targeting platforms where the desired version wasn't guaranteed, you still didn't have to ship it. All redistributable packages were (and are!) also published as standalone installers that users could just download and run themselves; indeed, it was not uncommon for open source Win32 software to require one to do exactly that. The bundling packages that MS also provided for integration with your own installer are a convenience, not a prerequisite.

The story with DirectX is very similar. DirectX did in fact ship as an OS component with every version of Windows starting with Win95 OSR2 and WinNT4. The reason why games pretty much always bundled it is because they wanted to use something newer, given how fast things changed back then. But, again, it was always available separately as a standalone installer, and any app that needed it could request it to be installed manually by the end user, and some apps did just that. I will also note that those standalone CRT and DirectX installers were also commonly redistributed, e.g. on large websites like Tucows.

With respect to Win32 APIs themselves being somehow protected through some form of IP, that wasn't the case, either. Again, Borland C++ / Builder used its own headers with no problem. And then of course pretty much every non-C toolchain that wanted to expose the dev to the OS API also had to provide their own equivalent of windows.h, which they all did - Delphi being probably the most prominent third party example, but there were numerous others - Ada, Eiffel etc; and even most scripting languages such as Perl. Again, back in that period, I myself wrote a bunch of Win32 header translations for then-nascent D. I don't recall anyone ever bringing up the notion that doing so was somehow legally risky; it was understood as an obvious and necessary step in development of any toolchain targeting the platform.

XP era also includes early .NET. The interesting thing about that one was that the .NET Framework redistributable (which, again, was provided as a standalone installer) also includes the C# and the VB command-line compilers, and since .NET metadata is embedded into the binaries, the result is that you effectively got a free build toolchain that let you do anything .NET could do. XP SP1 even included .NET 1.0 builtin, which I believe was the first time Windows came with dev tooling sufficient to write a full-fledged app for itself in the box.

The bit about "you never saw FOSS binary releases for Windows back then" is plainly not true. FOSS in general wasn't nearly as widespread then, and people who cared about it generally didn't care much for the DOS/Windows ecosystem, so mainline would often not even bother and just assume POSIX, and porting was a slow effort that required constant ongoing maintenance to keep up-to-date with upstream. But what did exist would normally be redistributed in binary form; examples include MinGW, Perl, and Python. Similarly, when using FOSS libraries like zlib, it was common to download and use redistributed prebuilt DLLs + import libs for your compiler.

So, to summarize: Microsoft never charged developers for access to the platform itself, and you could always write and distribute Windows apps without paying anything to MS. It charged the devs for tooling, but it also left the door wide open for alternative tooling, which did proliferate to the point where in some markets like Europe there was more Windows software written using Borland tools rather than Microsoft tools.