14

The motivation for this question is a far-fetched dream I have where a lot of the excellent software available on *nix platforms could be trivially ported to Windows. Microsoft has taken a different approach to open source and openness in general recently, so I'd really like to know how viable such a thing would be if Microsoft were so inclined. Some of the more specific things I'm curious about is if it could be done without breaking backwards compatibility, and perhaps some sort of gauge on the amount of effort that would be involved. If there were any specific technical examples that would highlight particular difficulties in doing such a thing, that would also be greatly appreciated.

w.brian
  • 16,296
  • 14
  • 69
  • 118
  • You can guess "what would it take" if you were the developer implementing it - by combining answer [Do professional software developers write an average of 10 lines of code per day?](http://skeptics.stackexchange.com/questions/17224/do-professional-software-developers-write-an-average-of-10-lines-of-code-per-day) and the fact that [ReactOS® is a free open source operating system based on the best design principles found in the Windows NT® architecture](https://reactos.org/development) – xmojmr Dec 09 '14 at 10:42
  • 1
    Microsoft Windows is a closed-source system. This question can not be answered without knowledge from a Microsoft insider and thus it is off-topic. – xmojmr Dec 09 '14 at 10:43
  • The fact that it's closed-source means nothing as far as this question is concerned. POSIX is an interface -- implementation details are irrelevant. – w.brian Dec 09 '14 at 15:20
  • 2
    @w-brian I can not agree. In order to "make..compliant" you have to implement changes. To make it happen someone would have to invest software development efforts. Analysis of the changes needed is one part but again this can not be done without seeing inside the current codebase – xmojmr Dec 10 '14 at 05:54

1 Answers1

21

Windows has already been such. The NT kernel itself has supported the concept of "personalities" (API layers over the NT layer) since the beginning, to support by design at the very least the Win32 API, the POSIX API and the OS/2 API.

The POSIX layer circulated for a long time in higher end SKUs (typically server-related) with different names (Microsoft POSIX subsystem/SFU/SUA), but it never really caught on for non-specialized use, both because it was not universally available (Microsoft never really pushed it, probably for commercial reasons) and because other solutions became widespread (think Cygwin/MSYS/MinGW).

Notice that, although the "personality API" is an interesting concept (and probably one of the cleanest way to implement a multi-API OS) it suffers a bit from a "deep segregation" problem - i.e., it's true that you can access kernel objects through a POSIX interface, but all services that have been built over the Win32 interface (like Windows, GDI & co.) aren't easily available; besides, however good the interface may be, there are some details (like the format of paths) that cannot be ironed over, so a POSIX application will always look a bit out of place.

Matteo Italia
  • 123,740
  • 17
  • 206
  • 299
  • Until they [dropped it with Windows 8.1](https://social.technet.microsoft.com/wiki/contents/articles/10224.posix-and-unix-support-in-windows.aspx) – Thomas Weller Oct 04 '22 at 15:23