Mach de Bagua    

It is just like yesterday while I was a graduate student writing Windows NT devices drivers for my dissertation project 10 years ago. I believe every kernel developer read Inside NT Programming and a famous diagram in that book shows NT kernel may have Windows/OS2/POSIX subsystem on top. It is said NT have to support POSIX to win government order. I downloaded the SDK and create two files on my NTFS disk with the same name, one in captial and one in lower. The POSIX is 1.0 at that time and do not have much usage. Just played and forget it.

I am working on a complex program, with VxWorks/ecos/Linux/Windows systems connected through ethernet. Those systems communicate with each other, thus it is natural to build a event/data exchange layer over TCP/IP. There are realtime communication inside those systems also, we would like to have a uniform platform. Quickly it comes POSIX and unix style socket library.

It is natural to get POSIX and unix style network sockets work on Linux. A blockpoint is the Windows. Everybody knows cygwin, however I do not want to jump to the conclusion and have a research. Here is possible solutions

1) Pthreads Win32 - source files which can be compiled to DLL or static lib, a wrapper for POSIX functions on Win32 APIs. No Unix sockets support.

2) uwin – AT&T provides Unix API support by POSIX.dll. Compiled with MS VC++/ Borland C++ compilers. No information on sockets.

3) Cygwin - Large user group, mature solution. Have POSIX emulation layer.

4) Interix - POSIX system of Windows SFU(Services for Unix, latest version 3.5 for Win2K and XP) or SUA(Subsystem for Unix-based Application, latest version 6.1, included in Win7, Win Server 2008, Win Vista ). It is a subsystem build on Windows kernel, that is, on the same layer with Win32 subsystem. It is a default subsystem of Windows.

5) emx (Eberhard Mattes eXtender), a.k.a. emx+gcc, support POSIX and OS/2 APIs on DOS. Last updated in 2001.

6) djgpp ANSI and POSIX compliance for DOS. Last updated 2001.

7) mingw Windows native GNU tools. MinGW does not provide POSIX emulation layer, nor Unix system calls. POSIX functions need to be re-write in Windows API (refer to the Unix/Windows Porting Dictionary).

8) GnuWin provide window-lized GNU tools bin and src, also GNU libs. Compiled with minGW. No POSIX.

The conclusion is SFU/Interix and Cygwin may fulfill our requirement. The story of Micorsoft POSIX is Microsoft did supply a POSIX API for NT, but soon expired on 2000. A company named Interix start to provide their POSIX solution for Windows 2000/XP, until acquired by Microsoft in 2009. Microsoft has made it a standard system component of Windows Vista and Win 7. Theoretically Interix/SFU is build directly on Windows kernel and should be 10+ times speedy than Cygwin. I got some try on.

SFU/Interix

1. Install Interix 3.5 from Microsoft for WinXP (Always use custom setup to select GNU SDK)., or enable SUA for Win7/Vista/Server in registry. The DEP(Data execution protection) must be turned off before GCC can run. Go to C:/boot.ini, change it to writeable, then modify /NoExecute=On to /NoExecute=AlwaysOff . You may need to use Interix chmod tool to enable writing to boot.ini, and, it might be invisible in explore.

2. Interix 3.5 is using old GNU codes, must update make utility. Download from GNU and compile.

3. Interix does not have stdint.h. Get one from GNU, put it to /usr/local/include/

4. Interix binary is not ELF compatible… the readelf can not recognize the format.  (In default Interix does not have the binutils. Download from GNU and compile)

5. Win does not have clock_gettime() in timer.h, need to use gettimeofday(), which is low precise

6. Interix stdlib does not have strtof(), use strtod() instead

7. Shared library should not use c89, that is, must use gcc instead ld, or export LDSHARED=”gcc –shared”. Interix support –fPIC poor, must directly link *.o files.

8. Python on Interix can NOT load dynamic modules(*.so)

9. The executable can be launched either from Interix shell or Win32 command line

10. No cmake utility on Interix. Need installation.

Conclusion: Interix may work for porting, but the version 3.5 on XP is kind of too old, and it is not easy to get the Python work. Better to have Win7.