<div dir="ltr">Hello again,<div><br></div><div>I come bearing more problems :-).</div><div><br></div><div>I seem to have found another point in the ABI which prevents an easy port of swift to Windows without an emulation layer underneath.  This time it deals with the protocol conformance table.  The table is constructed with a direct reference to protocol.  However, because the protocol lies in an external module, this ends up being a problem as it must be indirectly addressed.</div><div><br></div><div>There is a workaround in place for generating a GOT equivalent entry, however, that still doesnt indirect through the pointer, which needs to be done to address the executable model on Windows.</div><div><br></div><div>This along with the DLL storage changes (<a href="https://github.com/apple/swift/pull/2080">https://github.com/apple/swift/pull/2080</a>) are the currently two known ABI issues preventing the port to windows (with cross-compiling!).  Im hopeful that the former can be merged soon.  If we can work out a way to address this last issue, I think that it should be possible to get a complete windows port of swift working (modulo API completeness) shortly thereafter without the need for any emulation layer (i.e. cygwin or MinGW)!</div><div><br></div><div>-- <br><div data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>