WIP/Foundation: port to Windows #1812

compnerd · 2018-12-19T18:06:27Z

Unformalised changes to port Foundation to Windows

CMakeLists.txt

Foundation/Thread.swift

jakepetroules · 2018-12-19T19:30:21Z

Foundation/URLSession/libcurl/EasyHandle.swift

@@ -374,9 +374,13 @@ internal extension _EasyHandle {
    /// errno number from last connect failure
    /// - SeeAlso: https://curl.haxx.se/libcurl/c/CURLINFO_OS_ERRNO.html
    var connectFailureErrno: Int {
+    #if os(Windows) && arch(x86_64)


Is ARM64 also LLP64? Probably a good idea to audit anywhere Windows+x86_64 is mentioned and see if it applies to ARM64 as well.

Yeah, that's a good point. Windows AArch64 is LLP64 as well, and we should account for that. I believe that I did that properly in the swift side and even the CoreFoundation side. This is still just a bunch of changes to make sure build/fill in the holes. It's going to require a second pass to actually formalise this into a patch set.

compnerd · 2019-01-09T01:54:53Z

Okay, so, at this point, NSFileManager, NSHost, and NSProcess are the remaining holes in Foundation for Windows. NSFileManager has a pretty large API set that needs to be adjusted for Windows and is the one that I am currently working on. The API surface being large and the API differences makes this slightly more challenging, but, hopefully I can work through that. I imagine that NSHost might be similarly challenging as it has a fair number of interfaces for querying information network information which will need to be completely redone.

parkera · 2019-01-09T02:24:29Z

What do you have in mind for adjustments to the NSFileManager API?

compnerd · 2019-01-09T17:09:22Z

@parkera - NSFileManager, NSHost, NSProcess, and NSTask need some fairly heavy changes unfortunately as the API is pretty different. I've pushed my local state to this branch, which is by no means ready. But, you can see the extent of the changes. As a particular example, symlink, readlink, link are not available on Windows under those names or semantics. There are equivalences now with CreateSymLink (which requires a RS3 or newer distribution of Windows, but I think that won't be too big of a deal, otherwise, you get a UAC prompt) etc, but they require a different implementation.

parkera · 2019-01-09T17:35:20Z

Different implementations are totally fine, and even making certain API unavailable on Windows, although unfortunate, does make sense if the concept is totally unportable. What I want to make sure of is that you don't feel like you need to change the outward facing API, so that clients can remain source compatible when porting.

Glancing at what you've got here so far seems like we're ok on that front.

phausler

There are a number of places that use some unsafe inner pointer usages for strings that need to be corrected. For the code base we like to keep it 4 space indents (not indented extra when in #ifdefs) and no line wrapping unless it is truly absurd. (The formatting is not a full blocker but would be nice).

Foundation/FileManager.swift

phausler · 2019-01-09T17:46:29Z

Foundation/Data.swift

 #endif

 import CoreFoundation

 internal func __NSDataInvokeDeallocatorUnmap(_ mem: UnsafeMutableRawPointer, _ length: Int) {
+#if os(Windows)
+	UnmapViewOfFile(mem)


nit: can we make sure to keep the indentation consistent? this seems like it has an extra depth past the 4 space.

This patch is absolutely atrocious in terms of indentation. I was playing around with Visual Studio and doing most of this in vim, so, its just an absolute disaster. This is going to require me to go through and fix that, which I don't think is worth it until I think that I have enough of this covered to break this into something more digestible. This should definitely not go in as is.

Foundation/FileHandle.swift

Foundation/FileManager.swift

Foundation/NSData.swift

Foundation/Thread.swift

compnerd · 2019-01-09T21:24:03Z

@parkera I think that most of the interfaces can be preserved, and that is something that I really would like to keep. I think that it really is important that as much of the API surface be the same as possible so that there is some possibility of portability of code.

Foundation/FileManager.swift

Foundation/NSData.swift

Foundation/CGFloat.swift

Foundation/NSData.swift

compnerd · 2019-02-14T22:15:05Z

Foundation/FileManager.swift

@@ -82,6 +96,8 @@ open class FileManager : NSObject {
            }
            urls = mountPoints(statBuf, Int(fsCount))
        }
+#elseif os(Windows)
+        return nil


Bleh, this seems wrong. This should be changed to throw NSUnimplemented at the very least

Foundation/FileManager.swift

Unformalised changes to port Foundation to Windows

compnerd · 2019-02-23T03:12:19Z

Time to say goodbye to this PR. The only thing of use left is the -DLIBCURL_STATIC which has a whole different conversation to be had. The remaining FileManager interfaces need to be implemented, but that requires recreating the FTS semantics, so they are stubbed out for now. I've fixed the blocks issue in clang, so we have the foriegn class import (need to runtime generate it as it may be cross-module) and the root protocol conformance handling (need to runtime generate as the chained protocol witness table may be module external) to look into preventing this single line change from being useful just yet.

jakepetroules reviewed Dec 19, 2018

View reviewed changes

compnerd force-pushed the windows-foundation branch 2 times, most recently from e0e512c to 27d6f2f Compare December 20, 2018 05:16

compnerd force-pushed the windows-foundation branch from 27d6f2f to cde8f3c Compare January 8, 2019 06:53

compnerd force-pushed the windows-foundation branch 2 times, most recently from 5a28a40 to 78a599e Compare January 9, 2019 15:43

phausler requested changes Jan 9, 2019

View reviewed changes

compnerd force-pushed the windows-foundation branch 2 times, most recently from fee503e to e267ca9 Compare January 14, 2019 04:59