I dunno, other code contained within my executable that executes before and transfers control to the WinMain I wrote counts as a hidden entry point to me 
Yes, I think so. Thanks for setting me straight.
I was more focused on the fact that using two different implementations of the SDK does not seem as a sensible thing to me, and that there does not seem to be a “clean” way to work with the current SDK (which seems to be implemented in a sensible way) and dispense with the installation of Visual Studio.
Yeah, that is sadly the current world that we have. I don't see a way away from this, but if there is a clever thing that does not end up looking like MinGW, I'd be interested in exploring that. At the very least, we can commiserate on this together.
There are people that are interested in a bare metal environment, and the SDK mechanism is the key to enabling that nicely for them even on Windows. I believe that @frzi upthread was interested in something like that.
3 Likes
Is the video/talk available elsewhere? It's showing up as "unavailable" for me on YouTube.
I'm surprised it could be unavailable, the video is public on the LLVM YouTube channel, the title is "2019 LLVM Developers' Meeting: S. Abdulrasool "Porting by a 1000 Patches: Bringing Swift to Windows"
Thanks Max, that worked and now it's also showing up under the original link. I believe this was the "Vinegar" extension interfering, and I always forget to double check without it active.
1 Like
Just as a cross link, see my comment in another topic about updates from The Browser Company that Saleem Abdulrasool joined recently.
For what it's worth, I have a cross platform windows gui app written completely in swift (with some c/c++ code interopted with). The code base is also used to compile on macOS / Linux and android.
When setting up a windows environment, I thought it was pretty painless and felt like setting up a c++ environment. I just installed visual studio 2022, the swift 5.8 tool chain, and built the project from visual studio code (all inside windows)
I was pleasantly surprised how easy it was to setup.
3 Likes
This is great to hear. Actually, I believe that there are further improvements that are forthcoming that will make the process even better
This includes things like dropping the ordering requirement (VS must be installed prior to Swift), improvements for dealing with VS upgrades, and there is hope that we can get to the point where we can even remove the requirement for administrator access (with per-user installs instead). Recent changes should also allow building without the VS Developer Command Prompt for SPM based packages.
There are already in flight improvements to SPM and LSP that should make the rest of the process nicer as well.
5 Likes
Well I'm extremely grateful to your efforts to making this a reality. Not only that, but thanks to your public examples, I had more than enough direction to implement dedicated windows CI (outside of GHA) so my entire cross platform swift workload is covered.
I can literally use swift as a c++ replacement. Not only for dedicated applications with the same feature set and coverage that the equivalent application has on darwin systems, but for other fun things like spinning up IMGUI backed libraries for video game mods on windows.
10 Likes
I always thought that porting Swift by using MSVC requiring Visual Studio was bad fit.
The natural fit would have been using the Clang toolchain as it is completely free, free from GNU stuff (what I know about) and also LLVM very much an Apple supported project.
The Microsoft compiler support should be optional instead for those who wants to import those libraries.
The LLVM based Swift toolchain is indeed used, albeit the situation is more complex, see this comment and this comment.
2 Likes
After convos with Microsoft, I submitted a formal request asking that they distribute the VCRuntime files we need outside of Visual Studio. Help the cause by upvoting it!
https://developercommunity.visualstudio.com/t/Provide-the-MSVC-native-toolset-as-a-sta/10815661
4 Likes
Unfortunately I always find myself in nirvana when trying to log into those Microsoft sites… 
Might a license notice as the one for the Visual C++ runtime files be enough?
In theory, it should be possible to build a standard library for Windows that has no external dependencies other than Kernel32.dll and User32.dll. On Linux, the same was achieved using musl. The lack of a musl-like library for Windows means it's more work, but that's it.
The problem is that there are no easily located guides for building and/or deploying alternative standard libraries on Windows. Any attempt to search for one leads to a Mac-only experimental feature (SE-0387).
A good tutorial for making a partial, minimal example, could become the corner stone for a long term 3rd-party/community project to create an alternative standard library for Windows.
The problem with this is the exponential explosion. There are too many variants and not enough compute to do this. It is already possible to do, it just requires you to roll your own SDK.
{static,dynamic} x {debug,release} x {ARM64,X64,X86} x {{debug,release} x {static,dynamic}}
So for just Windows, you would need 48 builds to cover the full gamut. At about 20m a build, that is 1000 minutes of build time for just the SDKs. This is just impractical. Building a custom SDK is not a bad thing, but that doesn't mean that the default distribution should bundle every variant. Having the most common/best supported/recommended configuration of the SDKs is really rather reasonable.
{static,dyanmic}- this is the build variant of the standard library (and while the static variant of the standard library does not function today, that is a limitation caused by engineering resources).{debug,release}- this is required since for debugging issues caused by the standard library, this is useful.{ARM64,X64,X86}- these are the currently supported architectures - I'm not sure if there is value in adding the ARMv7 standard library currently{{debug,release} x {static,dynamic}}- Microsoft does not do ABI compatibility across debug and release builds, so we need to have both forms to be able to work with with the system libraries, and again you can have statically or dynamically linked C runtimes and C++ runtimes. I'm assuming that you don't want to do static C and dynamic C++, but that is technically a valid combination as well, at which point you have ~100 combinations, with ~2000 minutes of build time per release for just the Windows SDK.
As you start adding additional SDKs with the myriad of configurations, it becomes intractable (Android has {ARMv7, ARM64, X64, X86} x {Debug,Release} x {static,dynamic} x {static, dynamic} - 32 combinations, which ends up around 500m of build time for the Android SDKs) as you would need ~2500 minutes for the SDKs and another ~3 hours for the compiler, ~2 hour to package giving you ~50 hours for a single build. The current Windows configurations are designed to be the most useful ones and the recommended method of shipping. If you want a different configuration, the Windows toolchain is setup to allow you to build and release your own SDK that be swapped out and used instead of the recommended ones.
Again, the issue is that there are no guides for that.
I wasn't suggesting all variants should be released (And I honestly don't think that would be useful). (In fact, unless encountering bugs or working on the standard library, debug variants are not useful)
Also, the part you quoted clearly says "no external dependencies other than Kernel32.dll and User32.dll" (using the musl runtime for comparison, which only depends on syscall), so C/C++ runtimes would be irrelevant if such an SDK existed.
But yeah, back to the main topic: It's a documentation issue more than anything. If it is documented somewhere, it's, at the very least, difficult to find.
P.S. Since you mentioned Android, I'll note that I'm somewhat ambivalent on Android as a target, so long as LLVM does not have a JVM backend. JNI was intended for low-level hardware interactions, not as a workaround for compilers that don't appreciate the value of forward compatibility. It's "compile once, run everywhere", not "compile 32 times and hope no new chip architectures are ever invented".
There are examples of this already: the Windows SDK for distribution is an example of doing this. The process itself is implemented in build.ps1. If you want, there is a more broken down version of it as to how to build it in GHA.
Sure, this is not in prose, but the problem is that the build system keeps changing at a rapid pace and as the options change, the prose becomes out of date quickly. However, all the pieces are publicly available.
For the understanding: If you do not want to rely on a VS installation, then you have to build all variants of the libraries you need (which might give you different toolchains), and with a VS installation you can get all variants of your program without needing to have those different library versions available, right?
As I see it:
- Not needing a VS installation would be a good thing. (This would lower the threshold for the use of Swift, and note that you even need a commercial VS license in companies with more than 150 employees as far as I know, but even without needing a commercial license there is much hickhack involved in many companies before you can install such a program).
- You might indeed get the number of variants down at least for the official distribution (no debug versions of the libraries?).
- If building the variants takes more time, isn‘t this a question of resources, and couldn't this be solved?
- Building the toolchain yourself is not really an option for many people.
Sorry, I am just a user here and no expert, I just have a wishlist and cannot really weigh up the pros and cons.
I'm honestly not sure about this whole "variants" thing. From what I can tell, each Swift installer only come with a single variant of the standard library. There are different installers for different architectures (x64, Windows on ARM), but that's about it. I'm not entirely sure what the variants bit was about, but maybe @compnerd can explain it better.
The real issue you're facing with building a VS-free standard library, is that the build script itself looks for VS, like in this line. You would need to adjust the build script itself to look for and use a different build tool, e.g. MinGW. Some changes to the code may be necessary as well, to bridge the gap between the environments.
It's not a simple task. It would be an undertaking.