Windows Nightlies


(Joe Groff) #21

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.

(Saleem Abdulrasool) #22

@Joe_Groff - I think you are absolutely right ... works great locally, but I do have @Andrew_Trick's patch applied!

(Pedro José Pereira Vieito) #23

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! :slight_smile:

C:\Users\pvieito\Downloads>more main.swift
print("Hello World!")

func GetVersion() -> CUnsignedLong
print("Windows Version: \(GetVersion())")

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, visualc and winsdk modulemaps but I manually copied them from the Swift repo to usr\lib\swift\windows\x86_64 with no success.
  • I also tried @Torust sample code and it crashes on this map to tuple ({ ($0, self.viewForSubBoard($0)) })). Changing to an in-loop operation the process runs sucessfully.

(Saleem Abdulrasool) #24

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.

(Pedro José Pereira Vieito) #25

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

(Saleem Abdulrasool) #26

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.

(Pedro José Pereira Vieito) #27

Interesting, thanks! :+1:t2:

(Gogul Balakrishnan) #28

This is awesome! Thanks for driving this, @compnerd :)

(Dawei) #29

Fabulous news!

(Thomas Roughton) #30

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.

(Saleem Abdulrasool) #31

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?

(Thomas Roughton) #32

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.

(Saleem Abdulrasool) #33

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.

(Thomas Roughton) #34

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.

(Saleem Abdulrasool) #35

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

(Joe Groff) #36

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.

(Saleem Abdulrasool) #37

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.

(Joe Groff) #38

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.


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.

(Karl) #40

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.