Talk:Microsoft Windows Services for UNIX

From Wikipedia, the free encyclopedia

	This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
???	This article has not yet received a rating on the quality scale.
???	This article has not yet received an rating on the importance scale.

Contents 1 Versus Cygwin 2 Emulation 3 SUA and Cygwin 4 Next version 5 From OpenBSD? 6 Merging Interix to here

[edit] Versus Cygwin

When I arrived the article contained the claim, "It is an implementation of an environment subsystem running within the Windows kernel. This significantly improves performance, stability and security compared with the emulation used by Cygwin."

This may well be the case, but no sources are cited. The claim thus lacks verifiability, and the security claim in particular may be considered POV. As a temporary measure I've reworded the second sentence to meet Wikipedia's basic standards for claims for which no evidence is available. Can anyone help out by providing verifiable sources for any or all of these claims? Haeleth 14:25, 3 October 2005 (UTC)

Cygwin is definitely not an "emulation layer", it's a DLL that provides various low-level library calls that unix/linux applications need when talking to the kernel. All programs running with cygwin must be recompiled, in most cases this requires not insignificant porting efforts. Please see http://www.cygwin.com for full details.

It is true that what Cygwin does should not be referred to as emulation. It does, however, sit in application space above the Win32 subsystem, whereas Interix is a subsystem like Win32 and sits alongside it atop the NT kernel. (At least, it has been referred to as the NT kernel prior to Vista; I'm not sure if that is still the right term.) When I read the previous paragraph, I went to the two authoritative sites for corroboration - microsoft.com and interopsystems.com. Interop Systems developed Interix originally (the original name being OpenNT). Subsequently, Microsoft bought the technology from them and hired their lead architect and made Interix a part of their Services for Unix (SFU) offering. Since then, they have relegated it to the role of a migration tool set to Windows for obvious reasons. Because of this, I could not find documentation of what I say above at interopsystems.com nor in the MSDN. The closest I found was the following two sentences from an obsolete TechNet article at http://www.microsoft.com/technet/interopmigration/unix/sfu/runwin32.mspx: "The Interix subsystem replaces the original Microsoft® POSIX subsystem. Interix provides a complete, native UNIX environment than can run concurrently with the Windows subsystem." (1) Microsoft's original POSIX subsystem also ran alongside Win32 over the NT kernel. It was not that great, and Microsoft didn't want to spend a lot of money on what they saw as a migration tool, which is why they bought the Interix technology. (2) The sentence has inaccurate wording; the reference to "Windows" is actually a reference to Win32. UnConnoisseur

Since writing the above paragraph, I have noticed that Microsoft does not refer in SUA to the OS (subsystem) as Interix, as it did in SFU. My guess is that it is still the same code base, but I don't know that, and it appears the name is being retired. UnConnoisseur

[edit] Emulation

In my view, there's nothing wrong with calling Cygwin an emulation layer, given that it emulates a Unix-like API on top of Win32 API. Similarly, SUA (Interix) emulates the Unix API on top of the native NT API. In some official documentation, Microsoft even refer to the current and former subsystems for NT/Windows (Win32, POSIX, Interix and OS/2) as 'emulation subsystems'.

Given that some people have a rather strong (but in my view irrational) objection the word 'emulation', I'll refrain from adding it to this article for the time being, but there really isn't anything wrong with emulation. It doesn't imply poor performance, a poor design or anything else that could be construed as negative. Indeed, a system designed to efficiently emulate several others (e.g. by implementing the combined set of features offered by those systems) is arguably at least as good a design as a system that doesn't use emulation. Shalineth 09:57, 3 April 2007 (UTC)

[edit] SUA and Cygwin

An important distinction between SUA and Cygwin is that the former runs on top of the NT API, whereas the latter runs on top of Win32. This means that Cygwin can only make use of the subset of NT kernel functionality used by Win32, whereas SUA has access to the full feature set offered by the kernel, including Unix-specific features.

The most obvious example where the above would lead to performance (and security) differences is fork(). The NT memory manager includes the capability of forking processes (with copy-on-write for the child address space, etc.), but this was included specifically to allow Unix to be implemented on top of NT, and has never been used by Win32.

Win32 has no notion of forking processes, so the Win32 subsystem neither calls nor offers a way to call into NT's fork functionality. This means there is no way to fork a Win32 process, and hence that Cygwin has to simulate the procedure by creating a new Win32 process and manually setting up its address space from another user-mode process (by copying data, etc.). This is extremely inefficient, and far less secure than leaving the kernel do it, as is the case with a typical Unix system (including SUA).

Another example where Win32 presents a problem for Cygwin is in case-sensitivity. Win32 is case-preserving, but not case-sensitive, which means you can't have two file names which differ only in terms of case. The underlying file system (NTFS), however, does support case-sensitive operation, but as with the NT's fork() functionality, this was included to allow POSIX/Unix to be implemented on NT. Once again, Interix or SUA can call into the NT kernel to create file names that differ only by case, but Win32 cannot (and hence Cygwin cannot).

Historically, the major disadvantage of a subsystem running on top of the NT kernel was that NT itself does not provide any graphics capabilities: the graphical components of NT-based OSes have always been part of Win32 (part of which, since NT 4.0, has run in kernel mode, in the win32k.sys module). This meant that code running in a non-Win32 process (e.g. an Interix one) had no way to display graphics directly, so had to use IPC to communicate with a Win32 process (e.g. an X server) for that purpose.

With the SUA release in Server 2003 and Vista, there is now support for 'mixed mode' binaries, which are created and managed by the Unix subsystem, but can also call into the Win32 API (which Cygwin processes, as Win32 processes themselves, have always been able to do). Presumably this means an X server could be ported directly to the Unix subsystem, and still call into the kernel-mode portion of Win32 to access graphics devices.

As far as I know, no X server has been ported to the Unix subsystem on Windows, but there is no longer a technical barrier to it, it's simply a matter of nobody having done it.

Summing up, with the addition of 'mixed mode' binaries, there are no technical disadvantages to using a native subsystem to implement Unix on top of the NT kernel, as compared to the Unix-on-Win32 approach of Cygwin. On the other hand, Microsoft have never published documentation explaining how to develop a subsystem for NT (although I believe they have supported some academic projects in this area), so the only supported way for someone other than Microsoft to implement a Unix-like system on top of the NT kernel is to implement it on top of Win32 (like Cygwin), with all of the disadvantages that entails.

I haven't time to find official documentation for the above at the moment, but I've read about it in authoritative sources on the NT kernel design, so I'll try and find a source, and add it to the article, when I have got time. Shalineth 09:57, 3 April 2007 (UTC)

[edit] Next version

Next scheduled release is version 5.2 on December, 2005 (for Windows 2003 Server Release 2, aka W2K3/R2, only - no mention of this on the SFU page [1] - in fact it's been EOL'd by Microsoft. Can anyone confirm/deny the new version? Disregard this question. Found answer myself, at [2].

Can someone fix RaviC's Image (resize it to appropriate size?), as it is the only image I can find. TheGuest

[edit] From OpenBSD?

I recall that a lot of the userland programs are from OpenBSD (as compared to MKS Toolkit, which uses independent reimplementations), but don't recall a source for that. Anyone got one? - David Gerard 12:04, 3 July 2006 (UTC)

I'm far from an expert on this subject, but the USENIX paper linked from the article under the name History of the Interix subsystem contains the following:

Much of the original utility base for the early INTERIX commands and utilities came straight off the 4.4BSD-Lite distribution. The general flow was to copy the source distribution over to a working directory, use a simple template makefile, and begin simple compile-edit cycles until the utility built. (6.14.4, p.10)

Might that be what you were thinking of? — Haeleth Talk 12:44, 3 July 2006 (UTC)

http://undeadly.org/cgi?action=article&sid=20030927090008 Running strings on it, see what the sources are. Janizary 23:10, 24 August 2006 (UTC)

My understanding (second-hand) is that SUA was originally based on code from the NT POSIX subsystem (licensed from Microsoft by Softway Systems), together with 4.4BSD-Lite code, but that many of the BSD userland tools have subsequently been updated by importing code from OpenBSD.

Starting with SUA for Server 2003 R2, however, Microsoft also added System V tools alongside the BSD ones, the former of which I believe are derived from the original UNIX SVR5 (UnixWare) code base, licensed through the SCO Group (formerly known as Caldera, which bought the Unix System V code, and the 'SCO' name, from the former Santa Cruz Operation, which had acquired the first of these from Novell, which in turn had acquired it from AT&T's UNIX System Laboratories in the early 90s). This would make SUA a 'genetic Unix', although I'm not sure if it's an official 'UNIX' (i.e. licensed by The Open Group (TOG) to use the name), although I do know Interix was at one time certified by TOG as an official 'UNIX'. Shalineth 10:13, 3 April 2007 (UTC)

[edit] Merging Interix to here

Someone has suggested merging the Interix entry with SFU. That's wrong. Don't do it. SFU is now EOL, though it will be used for many years still. Interix (one of the components of SFU) continues to evolve as it is now bundled with the base OS release starting with Windows 2003/R2 (Interix version 5.2) and continuing with Vista (Interix version 6.0).

Like SFU, SUA is a migration package containing tools, Interix among them. Interix should be independently referenceable with crosslinks between them.