Microsoft is transitioning the product line again, integrating it directly into Windows, with the Posix component being renamed to Subsystem for Unix Applications (SUA). This transition actually started with Windows Server R2, but it's also the strategy going forward with Vista. The new labeling also signifies the fact that SUA is essentially a ground-up rewrite of the Posix environment--including 64-bit platform support, Open Database Connectivity (ODBC) interfaces, and better integration with Microsoft Visual Studio. But to user-space applications it's all still Interix.
The Posix subsystem essentially maps Windows resources to the Unix environment, providing an alternative "personality" for the Windows kernel through a Unix-like set of APIs and representations. For example, user accounts are not stored in a traditional /etc/passwd file, but instead are accessed through library calls like getpwnam and getpwuid, which the Posix subsystem then maps to the Windows authentication system via the legacy SAM database API.
This model allows the Windows authentication store to work somewhat seamlessly, regardless of whether the store itself is a local users and groups database, a legacy NT domain, or an Active Directory domain. The downside is that user account data is limited to what can be stored in the SAM database, which isn't much. Worse, the NIS server component of SFU provides Posix extensions for Active Directory, but those attributes cannot be used because the Posix subsystem can speak only to the SAM database API.
Likewise, the Posix file system is simply a representation of the underlying Windows file system, and can use only what Windows can provide. The root of the Unix file system is mapped to C:\SFU by default, although other parts of the Windows file system can be accessed through device aliases. (For instance, the root of the C: drive can be accessed via /dev/fs/C.)
Since there are no mount services to speak of, the only way to access remote file systems from the Posix subsystem is to set up a connection in Windows. For example, if you need to use a remote SMB share for a user's home directory, then you need to make sure the resource is mapped to a drive letter by Windows during the login process, either by the user's profile settings, or by using a login script. (This can be seen in the first screenshot above, which shows the user's home directory being mapped to Z:, or /dev/fs/Z in the Posix space.) This can be another point of weak integration in some cases. Because the user's home directory attribute gets used for the user's Posix home directory as well, you are stuck with UNC and drive letter paths for the SFU home directory, while remote systems can use NFS mount points and paths.
Windows and the Posix subsystem also share a common command environment, so you can call Windows executables from within a Unix shell simply by calling the executable like you would from any command prompt. The opposite works too--such as using "ls" to get a Unix-style directory listing from within the CMD command shell. But if you need the whole Posix subsystem--including file system mapping and the like—then you need to use the POSIX.EXE command as a front-end loader for the Unix-style command to create the full environment.
One area of disconnect here is in the background services: the Posix subsystem includes its own /etc/init.d startup scripts and cron scheduler, which are completely independent of the Windows service engine and Task Scheduler. Experimentation shows that it is possible to launch some of the Unix services as fake Windows services by using the "instsrv" utility from the Windows Resource Kit and "psxrun" (POSIX.EXE with the terminal I/O functions removed), although this is a crude hack at best. It would be nice if Microsoft could find a way to improve some of these mappings.
