Talk:Windows Services for UNIX

message: 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)
thread_title: SUA Username Mapping

message: 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)
thread_title: Versus Cygwin

message: 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)
thread_title:  Emulation 

message: 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)
thread_title:  SUA and Cygwin 

message: 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)
replies: text: I agree, and I've added much of that missing information to the article. FuFoFuEd (talk) 07:35, 30 May 2011 (UTC)

text: 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)
replies: text: Listed. // coldacid (talk|contrib) 01:28, 13 March 2015 (UTC)
thread_title:  Merging Interix to here 

message: 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)
replies: text: 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)
replies: text: Listed. // coldacid (talk|contrib) 01:28, 13 March 2015 (UTC)
thread_title: Merger proposal, 2015 discussion

message: 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)
replies: text: What? www.microsoft.com/downloads: "Download details: Windows Services for UNIX Version 3.5"   —Preceding unsigned comment added by 218.214.18.240 (talk) 08:25, 4 October 2009 (UTC)
replies: text:  It was renamed to SUA for Windows 2003 R2,  which included it on Disk 2. They also claim it was re-engineered at this point, e.g. to allow linking Win32 libraries.  The Vista download is called SUA , and so is the Windows 7 one . FuFoFuEd (talk) 07:42, 30 May 2011 (UTC)
thread_title:  Article Title Change 

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

message: Hello fellow Wikipedians,
I have just added archive links to  on Windows Services for UNIX. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  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.
Cheers.—cyberbot IITalk to my owner:Online 09:01, 10 January 2016 (UTC)
thread_title:  External links modified 

message: 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)
replies: text: "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)
thread_title:  Windows 8.1 and Sever 2012, onward