But on Windows platform some Visual Studio components are required (see installation instructions here and here).
Does this mean that developers using Swift for software development under Windows are bound by Visual Studio license terms from Microsoft?
Does this mean that commercial development in Swift under Windows is limited when using Community Edition of Visual Studio? And that to overcome that limits one should purchase VS Professional or VS Enterprise?
I feel that a commercial product (Microsoft Visual Studio) being a part of the Swift compiler is wrong. Shouldn't it be just Windows SDK that is required, and not a commercial product from Microsoft?
First one should understand why Visual Studio is necessary for Swift on Windows: Swift on Windows fits in seamlessly within the Windows environment (many other languages on Windows are less native so to speak). Part of this is that a portion of the Visual Studio installation is necessary for development in Swift, but Microsoft forbids using this portion of Visual Studio independently. (When you distribute your compiled program, you only need the C++ redistributable packages or the according DLLs from the Microsoft installation which are allowed to be distributed together with your program.)
Technically either the community version of Visual Studio or the commercial version will suffice. But Microsoft demands using the commercial version if you are part of a company with more than 250 PCs or users or one million U.S. dollars in annual revenue. There are some exceptions, e.g. for open source software. (Please look up those conditions yourself, no guarantee from me, my citations might be erroneous.)
So if you are not in a "big" company according to the conditions above, the community version suffices, whether you are developing commercial software or open source software.
Of course, one would prefer to be able to develop without a Visual Studio installation and not having to buy a commercial license even inside a large company, but there are also other cases where you might want or have to use Visual Studio, so the situation is not really different from some other situations for development on Windows.
FWIW, one would have to develop an alternative SDK for Windows based on MinGW, which may not be suitable for many users either, as it is not permissively licensed.
Not that it should be the reason not to do it, just no one came up with such SDK yet, as far as I'm aware.
I am not a laywer, but as I understanding it, for the pieces of Visual Studio (VCRuntime) you are bound by Microsoft's licensing terms.
The WIndows SDK is under licensing terms from Microsoft as well. It actually has a dependency on Visual Studio for the MSVCRT headers and import libraries that cannot really be overcome as far as I can tell. If you know of a way to break WinSDK of a dependency on the MSVCRT headers, I'd be interested in learning more about that.
Thank you for the prompt reply, and for the all hard work that made Swift available on Windows.
I am not a laywer, but as I understanding it, for the pieces of Visual Studio (VCRuntime) you are bound by Microsoft's licensing terms.
I am not a lawyer too, but my opinion is the same. However I am talking not about runtime libraries (which are usually free redistributables), but about the two Visual Studio components that are required for the Swift compiler to work, before I distribute or even run the compiled app:
Microsoft.VisualStudio.Component.VC.Tools.x86.x64
Microsoft.VisualStudio.Component.Windows10SDK
Both are part of a Microsoft's commercial product.
Not sure about the first (build tools), but the second (Windows SDK) is definitely available as a separate installer from Microsoft, outside of Visual Studio.
The WIndows SDK is under licensing terms from Microsoft as well
Sure, but not as a part of commercial product.
If you know of a way to break WinSDK of a dependency on the MSVCRT headers, I'd be interested in learning more about that.
Unfortunately I'm not that advanced in Windows API.
Are MSVCRT headers part of Visual Studio? Or they are part of Windows SDK? Maybe the required build tools are also a part of Windows SDK, outside of Visual Studio?
As I see it, Microsoft is the gatekeeper to this kind of native development for Windows, and if Microsoft chooses to collect some money from larger companies who like to develop closed software using this “gate”, it is up to them.
@compnerd as an expert in this field does not see a solution that keeps the “true native” approach but does not use the mentioned gate, and no other person came up with an idea.
There are other languages that do not use this “gate” (to keep the picture) but they are not a replacement for native C++ development on Windows as Swift potentially (I would even say by now: actually) is.
So the vision for Swift on Windows is greater than just “let’s somehow make it possible to run Swift program on Windows”, somehow even independent from that goal. The Visual Studio issue is the price to pay for it.
Thank you, I'm glad that you have found it to be useful!
Correct. The Windows10SDK is available as a standalone SDK from Microsoft. However, it cannot be used on its own. The piece that it needs is the first bit: the VC.Tools. This has the compiler and linker, but more critically, the MSVCRT headers and import libraries. When you actually build with SPM, the only piece that actually is needed from it are the headers and import libraries. However, I do not see any way to get those headers otherwise.
Why not? Swift may be mostly open source, but it largely comes out of a commercial setting, where you cannot compile for iOS without the commercial product of Xcode. Obviously when possible like linux, it is fully OSS, but Windows is a commercial, closed-source OS and they have their own licensing requirements. Even the Android NDK, which is fully OSS, has weird licensing requirements: try clicking one of those linked NDK downloads to see them.
Swift has to integrate with the licensing requirements of commercial platforms, there's no way around that. We should try to lessen them as much as possible, but sometimes, such as on the gaming consoles like the PS5, there's not much you can do.
Good point actually. Sorry for my previous overly emotional reaction. I still believe though that Windows SDK should be enough, like it actually is for at least some other programming languages implemented on Windows platform.
No. Windows is quite different from the other host systems, so some work had to be done. There is no “hostility” especially to Swift on Windows of any kind. And I am talking about the result, how Swift works in principle on Windows, you did not understand what this means.
The idea is simple: FOSS should stay FOSS and not be intertwined with any commercial product. Unfortunately as I see it, for Swift this is impossible at the moment. Clang has the same problem, and this is a pity.
… Might be a good occasion to bring up the following two links (again) to give more background information on how Swift can operate on a host system and especially on Windows (by people who know a lot more about it than me):
@dima_kozhinov: I did not want to be too rude in my response, but when something has been first developed for *nix systems only and then ported to Windows, it is very often a lot of work. And yes, some properties of Windows make this hard in some cases, e.g. the stack unwinder of Windows is not “as good” as those on Darwin and Linux platforms, which made the support of async/await harder on Windows (I am not an expert here, so this might be a bit imprecise). I just think the formulation “hostile environment” is a misleading formulation and also a bit unfair considering how well Swift works and integrates on Windows now that some of the harder issues have been resolved.
I agree. I just wanted to shorten the explanation of difficulties of porting the *nix project to Windows.
Thank you for the links. I have read the suggested text (but hot have seen the video, sorry - it's too time-comsuming). What I found there is multiple mentions of Windows SDK and not any mention of Visual Studio.
Traditionally when two languages need to interoperate, the function calls at the boundary between the two languages, also known as the Foreign Function Interface (FFI), will go through C using a library like libffi. This approach has some drawbacks such as incurred runtime performance costs and possibly extra boilerplate code. Instead, Swift embeds a copy of clang, the C and C++ compiler, which is able to directly translate between the languages avoiding penalties in code size and runtime performance.
And this goes this way (citing from above):
Those header modules are also mentioned in the article.
And this is what I meant about Microsoft being the gatekeeper to this kind of native development.