![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||
|
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)
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
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)
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)
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
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)
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.
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).
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)
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)
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)
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)
"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."
"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)
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)
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)
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:
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— cyberbot II Talk to my owner:Online 09:01, 10 January 2016 (UTC)
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)
![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||
|
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)
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
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)
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)
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
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)
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.
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).
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)
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)
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)
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)
"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."
"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)
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)
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)
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:
When you have finished reviewing my changes, please set the checked parameter below to true to let others know.
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— cyberbot II Talk to my owner:Online 09:01, 10 January 2016 (UTC)
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)