Windows Nightlies

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

Also, to be clear, the OSS version of Foundation is written in Swift and it is intended to be source-compatible with the Darwin Objective-C based version while not requiring the Objective-C runtime.

Have been trying Dispatch and it seems to work great, thanks!

I don't know if it is the same error, but when I try to import WinSDK after installing the modulemap swiftc always throws a lot of import errors referencing that some type is unknown (eg. error: "No Target Architecture" or error: unknown type name 'PSLIST_HEADER'). On the other hand, the MSVCRT module (and the underlying ucrt and visualc) works great.

That’s the same error, although I’m a little surprised you’re not seeing it with MSVCRT; I also ran into it with importing uint64_t from stdint.h. If you manually edit the WinSDK header files to change the #pragma once guards to #ifndef/#define pairs it should work.

39206 – [Modules TS] #pragma once leaks out of module files in a way that macros do not is the (preexisting) Clang bug that seems to reference the same issue.

Great to hear that libdispatch is working great for you!

Oh, right, thats under-documented, I'm sorry. I don't know where to put such a document. You need to specify the architecture that you are targeting when you compile unfortunately (cl requires that too). Adding -Xcc -D_AMD64_ or -Xcc -D_X86_ should resolve the issue with import WinSDK.

@jrose, what do you think of adding this in the frontend based on the triple?

1 Like

That definitely seems reasonable to me. Clang predefines a whole bunch of macros like that on its own, so adding these few more (on Windows only) doesn't seem harmful. I suppose there's a chance someone wants to compile for Windows without using WinSDK, and might be using these names for something else, but that seems very unlikely.

The macros are in the reserved namespace, so, if they collide I'm not too worried.

Thanks for all the efforts in getting Swift to build & run on Windows @compnerd!

Would it be possible to include SwiftPM in your nightlies?

You're welcome :-). Unfortunately, I don't think that it is possible to include s-p-m just yet. I am still working on porting swift-corelibs-foundation to Windows. However, if I am mistaken and there is no dependency on Foundation for s-p-m, then assuming that the building s-p-m is as easy as libdispatch or Foundation (e.g. running CMake) then I can certainly include it.

1 Like

Hi @compnerd, what do you think are the chances we're getting a CI here: GitHub - apple/swift-community-hosted-continuous-integration: Swift Community-Hosted Continuous Integration so that your great work on Windows doesn't break again?

SwiftPM does indeed require Foundation.