Talk:Windows Services for UNIX

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by WikiProject Software.

Microsoft Windows: Computing Mid‑importance

	This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

SUA Username Mapping

One thing always missing on every piece of information about SUA is that it lacks an username mapping tool like MSSFU3.5. It seems it relies on Active Directory to map windows usernames to UIDs. — Preceding unsigned comment added by 187.57.147.35 (talk) 02:25, 14 September 2011 (UTC)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

Merging Interix to here

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result of this discussion was no merge. Closed per suggestion at WP:AN [3]

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.

The articles Windows Services for UNIX and Interix both have overlapping content, e.g. each article states a feature list identical with respect to the other article ("over 350 Unix utilities such as vi, ksh, csh, ls, cat, awk, grep, kill, etc." etc...). Therefore I added the merge template again.

Either the articles should be merged or both articles may remain separate. In the latter case, they must be differentiated from each other. --Abdull (talk) 20:51, 13 September 2010 (UTC)[reply]

Agree that the two should remain separate, mainly to to WSFU is obsoleted by Microsoft and will have a different path than interix. WebSurfinMurf —Preceding undated comment added 12:16, 12 April 2011 (UTC).[reply]

I too agree these should not be merged. Although Interix was included in SFU 3.0 and 3.5 (the last version) it was not included in SFU 1.0 nor 2.0. Merging the articles would make them unwieldy as they would not be about any one single topic. 67.210.196.5 (talk) 17:07, 19 May 2011 (UTC)[reply]

I agree, and I've added much of that missing information to the article. FuFoFuEd (talk) 07:35, 30 May 2011 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Merger proposal, 2015 discussion

CLOSED

Reject merging of Interix article(s) here as per Consensus on stale proposal. Non-Administrative closure-- GenQuest ^{"Talk to Me"} 07:02, 27 December 2015 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

As the last objection comment here was almost 4 years ago, and we're a couple of Windows versions on, can this now be merged? Seems sensible to me. --Adamfield (Adamfield) 09:49, 17 February 2015 (UTC)[reply]

What happened here it it appears that there was consensus against merging, but nobody actually bothered to close the conversation. However, since you commented recently about merging the articles in opposition to the consensus from then, and my own opinion is to keep them separate (on grounds of "why merge Interix but not MKS Toolkit?"), I'm going to go ahead and list this at WP:AN for them to decide whether to close with merge, close with current status, or determine new consensus. // coldacid (talk|contrib) 01:16, 13 March 2015 (UTC)[reply]

Listed. // coldacid (talk|contrib) 01:28, 13 March 2015 (UTC)[reply]

Oppose. Interix formed the core of the 3.x versions of Windows Services for UNIX, but both systems existed prior to that, and therefore they should not be considered one and the same. // coldacid (talk|contrib) 17:28, 14 March 2015 (UTC)[reply]

Oppose. Interix is a part of some releases of Windows Services for UNIX (but not all). Interix versions were released separately (both before and after Windows Services for UNIX). Merging the two would make for serious convolution. It would be analogous to merging MS-DOS and Microsoft Windows because DOS is a part of some releases of Windows (but DOS existed by itself first and Windows went on to exist without it). 50.126.125.240 (talk) 10:48, 23 May 2015 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Article Title Change

The current version of this is called "Subsystem for UNIX-based Applications". There's no reason this article should stick to the old name. It should be moved to reflect the changes of circa-2003. 99.253.232.40 (talk) 03:18, 8 August 2009 (UTC)[reply]

What? www.microsoft.com/downloads: "Download details: Windows Services for UNIX Version 3.5" [4] —Preceding unsigned comment added by 218.214.18.240 (talk) 08:25, 4 October 2009 (UTC)[reply]

It was renamed to SUA for Windows 2003 R2, [5] which included it on Disk 2. They also claim it was re-engineered at this point, e.g. to allow linking Win32 libraries. [6] The Vista download is called SUA [7], and so is the Windows 7 one [8]. FuFoFuEd (talk) 07:42, 30 May 2011 (UTC)[reply]

Posix subsystem is no longer a kernel mode process

As Microsoft removed the OS2 subsystem, the Posix subsystem has been removed from kernel mode in Vista and Windows 7.

http://download.microsoft.com/download/3/C/4/3C4C7C9C-AAA0-4BD4-9C14-5BA29BDD7D4C/sua.pdf "Interix is Win32 process"

Shjacks45 (talk) 01:42, 22 April 2010 (UTC)[reply]

That claim is not in the source you provided. It just says Interix ran atop Win32 when it was first developed and that SUA is a replacement for the old POSIX subsystem.

I love this part of the document:

"To further reach out to the UNIX and open source programmers and system administrators who use the technology, the SUA team provided users the source code of the GCC and GNU changes and the binaries."

Like they had a choice.

169.231.16.35 (talk) 04:26, 6 May 2010 (UTC)[reply]

"The Interix subsystem provides a fully POSIX-compliant environment that runs as a native subsystem in the Windows kernel. " http://support.microsoft.com/kb/324539/EN-US —Preceding unsigned comment added by 203.206.162.148 (talk) 01:12, 8 March 2011 (UTC)[reply]

The Windows kernel does not run subsystems, that page is wrong. It has always been a "native" application, and became a Win32 application Vista and later to support cross-subsystem calls. In both cases a driver (psxdrv.sys) IS used to provide add-on functionality, but it's not the subsystem proper. — Preceding unsigned comment added by 80.194.88.34 (talk) 11:47, 11 October 2012 (UTC)[reply]

NFS in 2012 R2

It looks like they fired or reassigned the whole team (2-3 persons), for they all have stopped blogging in late 2012 [9]. Someone not using his real name (talk) 07:51, 10 January 2014 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Windows Services for UNIX. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

Added archive https://web.archive.org/20050510025015/http://www.microsoft.com:80/windowsserver2003/R2/unixcomponents/default.mspx to http://www.microsoft.com/windowsserver2003/R2/unixcomponents/default.mspx

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 09:01, 10 January 2016 (UTC)[reply]

Windows 8.1 and Sever 2012, onward

It's unclear in the article whether the removal of [most of] these features in Windows 8.1 and Windows Server 2012 R2 was replaced with something else (either in those releases or in Windows 10 and Windows Server 2016). Should probably clarify for readers what Unix-like tools are available in these OSes (now, and including the forthcoming bash and Ubuntu on Windows, in Windows 10 at least, which is already operational in developer builds). — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 08:40, 13 June 2016 (UTC)[reply]

"and including the forthcoming bash and Ubuntu on Windows, in Windows 10 at least, which is already operational in developer builds" I.e., mention the Windows Subsystem for Linux somewhere other than in the hatnote and the "See also" section. Guy Harris (talk) 16:56, 13 June 2016 (UTC)[reply]