What Would It Take to Make Windows a Posix Compliant Operating System Out of The Box

What would it take to make Windows a POSIX compliant operating system out of the box?

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.

What is a POSIX function according to Microsoft

In this context, POSIX is the "Portable Operating System Interface" which is a family of standards that initially tried to make all the different UNIX systems compatible. Thus, you could write against the POSIX APIs, and provided you didn't use non-POSIX APIs, you would likely have a program that would run on a variety of UNIX variants, and later, other POSIX supporting operating systems.

As far as I can tell, filelength was a C call that was platform specific. It was probably a popular call supported by a particular compiler, but may have been a popular call supported by a particular platform or set of platforms.

The POSIX specification dealing with files is "POSIX.1: Core Services" and it seems to have never contained a filelength function. It could be that Microsoft tried to get it added to POSIX and failed, or it could be that Microsoft just mis-documented it was POSIX and fixed their documentation with the removal you mention above. It may also be an ancient inclusion of POSIX.1, later removed (this is the least likely option).

The current version of POSIX.1 is Issue 7. It was released in 2008, and is also known as "IEEE Std 1003.1" as the two standards committees decided to align the standards to have fewer standards in the wild. You may browse the api bits of POSIX.1 here.

To find the file size using POSIX compliant APIs, you use the stat(char* filename, (struct stat*) s), call and then read the st.st_size field, or you can use the old-fashioned way of opening it, seeking to the end (fseek) and then getting the file pointer offset with ftell.

Is Git's reliance on POSIX features still an issue on Windows?

Yes, Git does rely on a POSIX system, but be advised that POSIX specifies a lot of things: a shell environment (i.e. command line environment), operating system interfaces (i.e. libraries that implement file I/O, threading, etc.), regular expressions, directory structure (i.e. /dev/null, /tmp), and utilities.

Given how I've defined POSIX, it should follow that Git relies on practically all of POSIX. However, if you read the Git developers' CodingGuidelines, you'll see that Git uses POSIX as a means of implementing wide portability.

msysGit gets around the compatibility problems because it is a POSIX environment.

Running Git on Windows generally means running on top of a POSIX run-time environment. This is the basis for Git for Windows. You first start Git BASH, and in that environment you run Git commands.

I can assure you that Git works fine in this manner!

If POSIX and the command line make you hesitant, you may want to explore Git UIs like Atlassian SourceTree or GitHub for Windows.

Unix subsystem for windows

It's probably best not to try to use the Posix subsystem for Windows. It was never really complete and is just a useless marketing tick box.

If you're truly interested in programming stuff for Unix, download one of the many Linux distributions (ie. Ubuntu) and VirtualBox. Install and start playing.

How to identify which OS Python is running on?

>>> import os
>>> os.name
'posix'
>>> import platform
>>> platform.system()
'Linux'
>>> platform.release()
'2.6.22-15-generic'

The output of platform.system() is as follows:

• Linux: Linux
• Mac: Darwin
• Windows: Windows

See: platform — Access to underlying platform’s identifying data

What part (specifically) of a native executable makes it non-portable?

There are a number of reasons. The main ones, ordered in "distance from the metal" are:

1. The operating systems may have different binary formats for executable files. In this case you will not be able to load the binary in the first place.
2. The program may use another method to indicate they wish to place a system call (e.g. INT21 vs INT80).
3. The program may rely on system calls that are not present in the other OS (e.g. dlopen())
4. The program may rely on the standard library not present on the other OS.
5. The program may rely on other libraries that are not available on the other OS.

Of course there are many more ways a program running in an unexpected environment can fail spectacularly.

---

Related Topics