Compiler? Swift is the compiler, not a thing from Visual Studio.
Linker? https://lld.llvm.org/
MSVCRT headers and import libraries? I am not an expert here, please someone with more knowledge help to determine where these belong. Visual Studio or Windows SDK?
You only need those from Visual Studio, not the compiler. (The compiler from Visual Studio was only mentioned for the understanding how things work in principle, the compiler of the Swift toolchain takes its place.)
For legal reasons, if you want to use those MSVCRT headers, you have to install Visual Studio. They are not part of the Windows SDK â the Windows SDK can be installed separately (and see my note about which DLLs from the Visual Studio installation are allowed to be distributed separately with your program, so you can make the distribution of a compiled program âportableâ i.e. not demanding any installation at all).
So one can see this as a legal issue, and as a result, Microsoft can make some money by selling Visual Studio licenses to larger companies. (Well, Apple sells hardware instead 
.)
Microsoft says otherwise:
The UCRT is now a Windows component, and ships as part of Windows 10 and later versions. The static library, DLL import library, and header files for the UCRT are now found in the Windows SDK.
CC @compnerd
@dima_kozhinov: It also says:
When you install Visual C++, Visual Studio setup installs the subset of the Windows SDK required to use the UCRT.
And to my understanding UCRT is the newer version of MSVCRT?
I also found:
Newer versions of mingw-w64 do support UCRT, using their own headers and LIB files, so UCRT works (with Clang or GCC) without either the Windows SDK or Visual Studio being installed. You can even compile apps to use the UCRT on other platforms such as Linux or macOS. Of course, this scenario is unlikely to ever be "officially supported" by Microsoft, but many projects now rely on it, and Microsoft employees have (unofficially) given the mingw-w64 project feedback validating their approach.
What then Windows SDK is good for? Why it even exist then?
Again, I'm not an expert here. @compnerd ?
1 Like
Sounds like an extreme approach. I think that Windows SDK is the official way for Windows apps development.
Swift is not the only compiler participating in the build process. For C/C++ interop one needs a working C/C++ compiler. I reckon Clang may not be sufficient in certain cases, similarly to the linker case below.
lld and link.exe are sufficiently different, esp. in the way they handle debug information, lld is ok when handling DWARF, but for PDB/CodeView you'll prefer link.exe.
Well, we have the following quote for SPM:
And:
Not for MSVCRT, but for UCRT @dima_kozhinov cited from the Microsoft documentation:
This poses several question:
- What suffices for ânormalâ SPM development, and what are the cases where the VS compiler/debugger will be needed (and then which one, as VS can be configured to use Clang)?
- Is VS not needed when UCRT is used and not MSVCRT, or is there no difference in this respect?
- If for UCRT, no VS is necessary, could Swift switch from MSVCRT to UCRT?
- If no VS is needed, is still an installation of the Windows SDK necessary? See the statement about the Windows SDK being now part of Windows, but what additional installations does VS then do?
So from a non-expert view on the MS documentation at least, I have to confess that @dima_kozhinov seems to be right, an installation of VS does not seem necessary, and things seem to have changed a few years ago.
Of course neither @dima_kozhinov nor me are experts here (I just explained to him how I understood the situation), and of course I assume that @compnerd is right, and the documentation by Microsoft might not be perfect, but nevertheless⌠Some explanations would be nice, thanks.
UCRT is not a complete C library but rather a small component of the larger system. The UCRT headers are in fact part of the Windows SDK, but cannot be used without VCRuntime which is provided only through Visual Studio.
-
WinSDK and VS headers and import libraries are sufficient for "normal" SPM development, assuming that you are only building "hello world" types of applications. Anything beyond that and you will need additional tools which are either part of WinSDK or Visual Studio (e.g.
mt,rc, etc; yes, LLVM has some attempt to implement these, they are nowhere near usable). -
The Microsoft compiler is not used during the compilation of the code. However, the debugger is often needed to actually debug the program. In the case of UI applications, Visual Studio is going to be needed (e.g. for debugging the view tree).
-
As stated above, UCRT still is not completely standalone, and so you must have an installation of Visual Studio. It is provides VCRuntime which is a dependency for the UCRT.
-
The Windows SDK is absolutely required, but the instructions use Visual Studio to install it to simplify them (and the management too). You can install the SDK separately and then install Visual Studio to provide the remaining headers and import libraries.
The whole library dependency thing here is a mess. If you note, the Swift overlay is now also called CRT (which was original MSVCRT). The renaming was done due to the UCRT shuffle, which introduces the AppCRT, DesktopCRT, UCRT on top, and all of them built a top of VCRuntime. However, all of these still have a dependency on VCRuntime.
The general thought that "UCRT" is there, why do I need "VCRuntime" is like saying, I have UIKit, why do I need Foundation?
3 Likes
Everyone cites technical reasons: A depends on B, which depends on C, we have dependency hell, and the ultimate dependency is a proprietary commercial product from Microsoft, that is not a part of operating system.
My question was not about technical details. Let's return to the subject: Licensing questions.
The legal consequences of your technical decisions are as follows:
You should stop touting Swift for Windows as Free and Open Source Software, because it's not anymore. Anyone can go to court and force you to do so. Nobody wants that, including me, and this is why I raise these questions.
I think there may be a legitimate point here that users may not remember that some of the things listed as prerequisites to use of Swift are under more restrictive licenses than Swift itself, but I feel like youâre focusing in on wording and branding that isnât even there. Hereâs whatâs on <swift.org>, right now:
Open source Swift can be used on Windows to build Swift libraries and applications. The open source binary builds provide C/C++/Swift toolchains, the standard library, and debugger (LLDB), as well as the core libraries, so one can jump right in to Swift development.
It doesnât say âFree and Openâ. It doesnât even capitalize âOpen Sourceâ, because itâs using the common-adjective-phrase meaning of âthe source has been published and is not restrictively licensed itselfâ.
6 Likes
Explanation accepted, thank you.
You can put it that way. Indeed, there are no words "Free" or "FOSS" at the swift.org, and I implied the FOSS definition to Swift, while such definition itself may be vague.
I would explain my concerns slightly differently. I have a rather "product"-oriented mindset, and when someone says "software", I see it as a self-sufficient "product". And if it cannot work without a certain component, then that component should be an integral part of the "product", or else the "product" is broken.
From your explanation I now see that Swift is not a "product", alas. It is rather a "component" of a larger ecosystem. It is a piece of software, free and open source, but nobody said "product", and nobody said it is self-sufficient. I was mistaken.
I get where you're coming from (and orthogonally the concerns about licensing issues on Windows are valid) but you can perhaps see that your line is still drawn at an arbitrary point. As in, you can't use the software without the hardware to run it, either, so is the computer itself also part of your software product? What about the electricity to run the computer, and the power station that generates it? Etc.
1 Like
Let me draw (just my personal) line:
Operating system and hardware do not count as dependencies, as it is a "platform", on which "products" run.
This discussion has braught up some interesting technical details but now seems to be getting nowhereâŚ
There are good reasons for realizing Swift on Windows in a way so it is independent from Visual Studio, but given the technical (and legal) situation for develoment on Windows, there are also good reasons to demand Visual Studio as a prerequisite or even embrace it (cf. the remark about debugging of a GUI).
The people running the show decided to go with Visual Studio, so this is where we are.
As already noted, using Visual Studio for native development on Windows is not really a big exception, and also note that only larger companies have to buy a commercial Visual Studio license.
I also suppose that @dima_kozhinov as a proponent of free and open is not a friend of Windows anyway, and @wadetregaskis is indeed right that the line drawn here is kind of artificial.
Then better use Linux and let other people enjoy how well Swift now works on Windows
2 Likes