I may be fundamentally misunderstanding the Windows Subsystem for Linux, but I believe it just provides binary compatibility for Linux x86_64 command-line tools, but doesn't quite implement enough of the Linux syscalls to run a Linux window manager in order to run GUI programs. So it's certainly something you could compile your server code for if you wanted to host on a Windows server, but it's not something you could use to distribute client software.
On Tue, May 3, 2016 at 9:11 AM, David Owens II <[email protected]> wrote: > Historically, that's been true. However, I wonder if the new Linux > subsystem work for Windows changes this. > > > https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/ > > And further, will we need a check for this on Windows? > > -David > > Sent from my iPhone > > On May 3, 2016, at 9:07 AM, Michael Buckley via swift-evolution < > [email protected]> wrote: > > I wouldn't personally use a Cygwin or MinGW target these days, but I can > see why a Cygwin target would be useful in a Swift context. I suspect most > Swift code is either going to be written for iOS/Mac, or Linux server code, > including third-party libraries. Lots of Swift code will probably have some > POSIX calls that wouldn't otherwise be available on Windows. > > On Tue, May 3, 2016 at 2:44 AM, hitstergtd+swiftevo--- via swift-evolution > <[email protected]> wrote: > >> Why is there a need to support Cygwin/MingW and their variants as a >> build target for Windows? MSVC is practically free these days. >> >> Doesn't supporting multiple different ABI targets on Windows just >> complicate matters unnecessarily? Isn't MSVC enough as a build target? >> >> I am not dejecting; rather, just wondering the actual need. >> >> On 3 May 2016 at 06:00, Sangjin Han via swift-evolution >> <[email protected]> wrote: >> > Hello swift-evolution, >> > >> > This is continued from PR #2351( >> https://github.com/apple/swift/pull/2351). >> > >> > Here is the brief history. (To avoid confusion, I used MSVC refer to >> > *-*-windows-msvc and Cygwin refer to *-*-windows-cygnus in LLVM.) >> > >> > I needed the #if method to distinct MSVC from Cygwin, for mapping the >> Int to >> > CLongLong not CLong on MSVC. >> > In PR #2351, I simply added 'os(Cygwin)' and restrict 'os(Windows)' to >> > *-*-windows-msvc from *-*-windows-*, this solved my problem. >> > >> > Jake(@jakepetroules) pointed out that Cygwin is not an OS and it will >> never >> > fixed to avoid breaking user applications. >> > There is more participants and opinions, briefly, >> > - introduce another new one such as 'env(cygnus)' or 'triple(Cygwin)' >> > - the usability of the common condition 'os(Windows)' for *-*-windows-* >> > - fundamentally, what do we gain from asking which os() is in use? >> > - 'env()' is too vague >> > - what the right questions? >> > >> > Forgive me the poor quotations of valuable opinions. >> > >> > >> > I hope we find out the solution or method everybody satisfied. >> > >> > >> > -Han Sangjin >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
