Could it be a memory alignment issue? @Andrew_Trick has a patch in the works to make the Swift runtime use _aligned_alloc/_aligned_free when necessary on Windows.
@Joe_Groff - I think you are absolutely right ... works great locally, but I do have @Andrew_Trick's patch applied!
1 Like
Yes, but in any case shouldn't they be in the architecture directory (as in Windows there aren't fat binaries)? This would also apply to the Linux toolchain.
I have retried the procedure on a Windows 10 machine and it works! 
C:\Users\pvieito\Downloads>more main.swift
print("Hello World!")
print()
@_silgen_name("GetVersion")
func GetVersion() -> CUnsignedLong
print("Windows Version: \(GetVersion())")
print()
let a = 2
for x in 0...a {
print("Iteration: \(x)")
}
print("Random Int: \(Int.random(in: 0...a))")
print("Random Bool: \(Bool.random())")
C:\Users\pvieito\Downloads>swiftc .\main.swift -o main.exe -O && main.exe
Hello World!
Windows Version: 602931718
Iteration: 0
Iteration: 1
Iteration: 2
Random Int: 2
Random Bool: false
I suppose the BCryptGenRandom call from the Standard Library is not working properly on Windows 7 and is hanging the process.
Also, some extra notes:
- The WinSDK / MSVCRT modules fail to import. I thought it was due to the missing
ucrt,visualcandwinsdkmodulemaps but I manually copied them from the Swift repo tousr\lib\swift\windows\x86_64with no success. - I also tried @Torust sample code and it crashes on this map to tuple (
SubBoard.allSubBoards.map({ ($0, self.viewForSubBoard($0)) })). Changing to an in-loop operation the process runs sucessfully.
No, they shouldn't be copied into the architecture directory, as the point is that they should not be distributed with the compiler at all. In fact, I would like to see the Linux ones removed as well in favour of ifso (interface libraries) which do not contain the text segment (separate project with someone actually working on that in LLVM). Eventually, even for Darwin, the dylibs should be replaced with TBDs instead. The runtime components themselves can be packaged and distributed separately.
Oh, interesting! Yes, this has only been tested on Windows 10, not Windows 7. I suppose that if someone is interested, that would be good to enable, but I think that Windows 10 as a baseline is reasonable.
The module maps need to be copied into C:\Program Files (x86)..., not the resource dir. Please see the instructions for Windows Build.
Yes, however, his unmodified sources will work once PR21593 is merged.
Ok, gotcha. Once ABI stability arrives Apple will start to distribute the runtime libraries with the OS and on Linux/Windows there should be two separated installations for the runtime components and the development toolchain.
I suppose you are referencing this paragraph. I don't get why it is required to be in that location. I have the toolchain in other location, and swiftc is already importing all the .swiftmodule from usr\lib\swift\windows\x86_64 so the .modulemap files should be there also (as glibc.modulemap is in the Linux toolchain).
Correct on the first point.
No, I was referring to the last paragraph here. The module map need to be next to the headers, which are provided by the Windows SDK. There is no way to overlay that, and the path where the SDK is installed can be different, so we cannot use absolute paths. This is a limitation of the explicit modules, so, for now, you need to do this manually if you wish to use the toolchain on Windows.
Interesting, thanks! 
This is awesome! Thanks for driving this, @compnerd :)
2 Likes
Fabulous news!
That sample program does work with the latest nightly, which is great. I also tried copying the lib/swift/windows folder to a macOS toolchain and was able to cross-compile without issue (usual caveats being the LIBPATH needs to be correctly set to point to all of the Windows libraries and lld needs to be on the PATH).
@compnerd, are you planning to include libdispatch in the nightly builds, or would that run the risk of overrunning the time limit? I also noticed that you're building against the debug versions of the Visual C++ libraries; that's probably ideal for the short-term, but long-term I think it'd be better to build against the release versions so that exes built with the toolchain can be easily distributed.
1 Like
I can attempt to add it and see if it makes it in time. The nightlies are built against the release runtime. Is there something in the logs that indicates otherwise?
I built an executable and needed to copy vcruntime140d.dll and other -d (e.g. ucrtd) libraries for it to run – the release VC++ redistributables were already on the PATH.
Yes, that is the correct, desired behaviour :-). That is the same behaviour that clang and cl have. You need to pass /MD to get the release libraries (or /MDd for the debug). Passing -Xcc -D_MT -Xcc -D_DLL -Xcc -Xclang -Xcc --dependent-lib=msvcrt -Xcc -Xclang -Xcc --dependent-lib=oldnames during the compilation should switch to /MD mode.
1 Like
Thanks; that fixes that issue!
The other problem I'm running into is that module imports don't seem to interact properly with #pragma once. Windows headers that transitively pull in other headers don't have the definitions from those headers when they're referenced from module maps if those transitive headers have #pragma once guards; #ifndef guards work fine, so I've been working around it by manually altering the Windows headers. The SDK version I’m using is 10.0.17134.0.
I think this is mainly an issue for C code, where the C code is trying to import through the modules defined for the purposes of the Swift code.
I've added libdispatch with Swift support as well as SourceKit to the toolchain. As to the behavior with the modules, I would recommend filing a bug (sounds like a clang issue).
3 Likes
This is exciting to see. I don't know what your exact ambitions are, but if the goal is to eventually do Windows application development, there are a number of runtime customizations that could be done to make Swift a good platform citizen and interoperate with the platform. For instance, one could make class metadata and/or protocol witness tables COM compatible by sticking an IUnknown implementation at the address point, so that Swift objects and existentials can be passed as COM objects. It should be possible to provide some amount of IInspectable support based on Swift's metadata too.
7 Likes
That's an interesting idea @Joe_Groff! Certainly something to consider in the future, possibly under a flag, as it would be nice to have the same behaviour across all the platforms. I wonder if we could also make that work with XPCOM and XPC on the other targets.
I don't think we necessarily need the exact same object layouts on every target platform. For instance, the space taken up in class metadata for ObjC interop fields is wasted on non-Darwin platforms, and ObjC reification makes certain operations require one-time initialization that wouldn't otherwise, and all that code should just be disabled on non-Darwin platforms.
1 Like
Apple has AppKit and ObjC runtime on Windows for iTunes (and Safari in the past).
If it is published, AppKit application can run on Windows.
I interested in this.
1 Like
It's been years; I guess the chance of Apple's AppKit/ObjC on Windows becoming public is basically zero at this point.
On the mac, the basic system libraries are broadly split in to AppKit and Foundation (+ other stuff). Foundation is cross-platform, the source is already available, and @compnerd has done a lot of work porting it to Windows. AppKit, on the other hand, is generally not portable; it contains a lot of things specific to macOS, which might not even have equivalents on other platforms, or if they do they might look/behave differently. The thing that iTunes uses is probably only a subset of AppKit. Trying to squish one platform's concepts on to another is one of the reasons bringing UIKit to the mac has proven so controversial. Besides, it's not even clear what the future of AppKit is on the mac; it might all just be UIKit in the future. What I'm saying is: don't hold your breath. (just to make clear, because there are a lot of employees on these forums: I don't work at Apple).
Even though it's not an ideal solution, Microsoft did try and bring these libraries to Windows anyway as part of Objective-C for Windows, using the GNUStep runtime. We've talked about bridging with that runtime before, and I think the consensus was that the project maintainers aren't opposed to it, but also aren't interested in implementing/maintaining it themselves.
1 Like