Interix (known as Microsoft SFU)

Introduction edit

SFU (Services for Unix, currently version 3.5) is an UNIX environment running as a Windows subsytem. (who knows more about how a subsystem works?) A subsystem is something like an embedded OS running on a Windows host. DOS, another well known OS, is a subsystem as well. (this is wrong) The SFU sub-system runs on top of the Windows kernel at the same level as the native Win32 sub-system, so it's not a virtual machine or an emulation. A subsystem uses the resources of the host and add specific features to the resources provided by the host. SFU is a POSIX implementation providing all the well known interfaces mostly used in SW development on UNIX. Portions of SFU do not use the POSIX subsystem. For example, the top command is win32 and not POSIX. The socks API passes through to winsock, therefore is missing parts of BSD socks.

• POSIX in general: http://standards.ieee.org/regauth/posix/
• Microsoft: http://technet.microsoft.com/en-us/interopmigration/bb380242.aspx
• Interop Systems: http://www.interopsystems.com

---

EDIT

Someone asked "Who knows more about how a subsystem works?"... and then there is a mistake about DOS.

I know a little more than previous authors, but don't want to destroy what is here. I'll try to explain below.

DOS, is a primitive 16-bit OS in it's own right, based on Digital Research CP/M. (another early OS) Windows was a Microsoft off-shoot from Microsoft/IBM OS/2, which IBM wanted to replace IBM DOS (written by Microsoft) with. IBM and Microsoft fell out over "ownership" of OS/2, and settled the matter by each taking the v1 source and developing from it separately. IBM kept the rights to the name OS/2 for OS/2 v2.x, and Microsoft initially built Windows v2.x on top of their DOS OS. Only once they had a true 32-bit Kernel did they introduce Windows 3.x build on it as "Windows NT". They had to differentiate between "Windows NT" and "Windows" as many users needed more DOS compatibility than NT 3.x could offer. So non-NT versions of Windows where build along-side Windows NT right up until Windows ME (Windows on DOS) and Windows 2000. (Windows on NT) At this point, Windows 2000 finally proved it was sufficiently compatible with DOS software (via NTVDM, The NT Virtual DOS Machine) for the 16-bit DOS OS to no longer be needed hosting Windows. (rather, NTVDM is hosed by Windows)

The NT kernel is something like GNU Hurd or the MACH micro-kernel. None of which really meet the original design criteria of a true "micro-kernel" but all of which have some of the basic advantages over a truly "monolithic" kernel. The idea of a "micro-kernel" should have been that it managed the barest essentials of the hardware, CPU and Memory, but did not provide any OS API, and should allow multiple operating systems to run simultaneously on the same CPU, without contention. NT probably does this, and proves that it can do it most successfully of all of them with it's SFU and OS/2 subsystems. The NTVDM is reliant on Win32 however, not just NT.

If you turn your computer on, it starts executing from the firmware. In most PCs, that's still what we call the BIOS (Basic Input Output System) which performs a POST (Power On Self Test) and searches for devices to read "bootstrap" code from. But in some cases this could be Open Firmware, as in a "new world" Apple Mac. (the role is the same, it's just a different form of abstraction)

NT loads after that, and then pulls the system from 16-bit comparability mode into 32 / 64 bit operation, securing it's self and setting up multi-tasking and memory management, as well as loading all the Ring-0 (supervisor mode) drivers for drives, basic keyboard input and so on. On top of NT, the Win32 or Win64 OS (Kernel32) is loaded. All Windows applications rely on Win32... though some may use "Native Mode" NT APIs as well. (Microsoft only provide "Native Mode" SDK as part of the DDK, Driver Developer Kit, not as part of the normal SDK, so regular applications should not call NT APIs, but a few low level recovery, interrogation, debug or disk de-fragmentation tools do)

SFU and OS/2 Subsystem for NT are loaded on top of NT, but not on top of Windows. (Win32 / Win64) They run in parallel, along side Windows. The NTVDM is loaded on top of Win32 (does not work on Win64) and WOW (Windows on Windows) is loaded on top of NTVDM to provide a backwards compatibility for 16-bit Windows executables under 32-bit Windows OS.

The purpose of OS/2 Subsystem for NT was to allow Windows NT users the ability to run IBM or Microsoft OS/2 applications on the NT kernel. Just as with SFU, OS/2 applications running on OS/2 Subsystem for NT behave more or less just like Windows applications, but have complete access to all the OS/2 APIs to achieve what-ever they need to do. (OS/2 Subsystem for NT was dropped after Windows XP / Server 2003)

In 64-bit Windows versions, support for 16-bit DOS and Windows applications is dropped. In their place is WOW6432, which provides a virtual 32-bit Windows environment. This also runs on Windows, not NT.

By comparison, Cygwin runs on Windows, just as NTVDM does. Therefore, if Windows fails below NTVDM, or Cygwin, it will pull them down with it... however, the Win32 system can fail completely and SFU or OS/2 Subsystem for NT can continue to run, while NT tries to restart the failed Win32 / Win64 subsystem.

I hope that clarifies things... but someone may like to cite, and condense this.

Why use SFU? edit

• SFU is POSIX, SFU is UNIX
• you can compile, edit and run your source code like on every other UNIX OS
• use your Unix know-how to write Windows software
• use !!!one!!! source tree (proven by my own projects) to create Unix, Mac OS X and now Windows software
• you can login with telnet or openssh, using your bash (and now tcl) to get your work done and finally use the already known Microsoft applications on your desk (even remote with "rdesktop")
• save space and money for one additional workstation (on your table)
• SFU fits very well into the Windows environment (no path-name-horror-trip with cygwin)
• Admin a Windows system with Unix utilities

Why not use SFU? edit

(already known Windows limitations still exist)

• no root user available (chosen restriction to link SFU into the windows user-management)
• you can not create files like "odd\\\[\]*?\{\}name" (NTFS limitation)
• a user started server can listen on low ports (security hole)
• multiple servers can listen on the same port. The first one wins, but the second one does get !!no!! error-msg
• FIFO speed is slow (~10 times slower than Linux)
• application speed is high, filesystem access speed is medium
• AEC 2005-09-09 I recently read Microsoft is going to stop developing SFU as an environment, but continue using it as a library for use with some of their server products. LV Actually, the code previously known as Interix or SFU has become bundled into the latest service pack for Windows 2003, and will also be included in the next generation of Windows. Read the various technical web sites from last August and September regarding Microsoft's plans. Note that the new abbreviation for this component is SUA.

---

LV - 2012-04-12 17:17:36

According to [1], the current release info is SFU's last release was 3.5. SUA has 5.2 for Windows 2003 R2, 6.0 for Vista and Windows 2008, and 6.1 for Windows 7 and Windows 2008 R2.

---