5 ms·

> Visual Studio Professional Enterprise — essentially (if you think about it) the SDK for the Windows platform — costs $250 per month per seat! Or you can use

> Visual Studio Professional Enterprise — essentially (if you think about it) the SDK for the Windows platform — costs $250 per month per seat! Or you can use GCC and compile “Hello world” for windows, no Microsoft IP involved? What am I missing

derefr 3y ago
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/ 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.
- EMIRELADERO 3y ago
  So what happens when a FOSS SDK for iOS pops up, which only calls the APIs on the OS itself and doesn't include any Apple-copyrighted stuff in it? What would you pay Apple for, then?
- int_19h 3y ago
  WSL has nothing to do with all this - we're talking about gcc building directly for Win32. That aside, you make several claims that are outright wrong. First of all, MinGW does come with all Win32 headers of their own included, and no, they're not protected IP (or at least Microsoft never made the claim to the contrary). With respect to C runtime, Windows itself ships with a bunch of them, packaged as system DLLs. MinGW used msvcrt.dll historically, which is the one that originally shipped with VC++ 6.0 before getting included into Windows. Since Win10, Windows ships an ABI stable C runtime called uCRT, precisely so that different toolchains have a single shared library for better interop. Modern versions of MinGW link against uCRT. Visual Studio still ships the C++ runtime, which MinGW doesn't need because it has its own. On top of that, unlike Unix, in Windows, CRT is not the basic OS API, but mostly a relatively thin wrapper around rich native Win32 APIs, so there are far more around than just different versions of VC++ runtime and glibc. For example, C++ Builder has its own. If you're a standalone Windows app, you don't have to redistribute DirectX. You can just target the minimum version supported for your matrix. If you're targeting supported versions of Windows (i.e. 10+), that'd be DirectX 12. And then of course you don't have to ship SQL Server Embedded because you don't need to use it; there are plenty of alternatives such as SQLite and Firebird. Just about the only situation I can think of where you have to pay Microsoft for the privilege of developing for Windows is when writing drivers.
  - derefr 3y ago
    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!

derefr 3y ago

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/ 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.

EMIRELADERO 3y ago
So what happens when a FOSS SDK for iOS pops up, which only calls the APIs on the OS itself and doesn't include any Apple-copyrighted stuff in it? What would you pay Apple for, then?
int_19h 3y ago
WSL has nothing to do with all this - we're talking about gcc building directly for Win32. That aside, you make several claims that are outright wrong. First of all, MinGW does come with all Win32 headers of their own included, and no, they're not protected IP (or at least Microsoft never made the claim to the contrary). With respect to C runtime, Windows itself ships with a bunch of them, packaged as system DLLs. MinGW used msvcrt.dll historically, which is the one that originally shipped with VC++ 6.0 before getting included into Windows. Since Win10, Windows ships an ABI stable C runtime called uCRT, precisely so that different toolchains have a single shared library for better interop. Modern versions of MinGW link against uCRT. Visual Studio still ships the C++ runtime, which MinGW doesn't need because it has its own. On top of that, unlike Unix, in Windows, CRT is not the basic OS API, but mostly a relatively thin wrapper around rich native Win32 APIs, so there are far more around than just different versions of VC++ runtime and glibc. For example, C++ Builder has its own. If you're a standalone Windows app, you don't have to redistribute DirectX. You can just target the minimum version supported for your matrix. If you're targeting supported versions of Windows (i.e. 10+), that'd be DirectX 12. And then of course you don't have to ship SQL Server Embedded because you don't need to use it; there are plenty of alternatives such as SQLite and Firebird. Just about the only situation I can think of where you have to pay Microsoft for the privilege of developing for Windows is when writing drivers.
- derefr 3y ago
  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!