Chapter 1: Introduction to Windows Services for UNIX 3.5
On This Page
Overview of Windows Services for UNIX 3.5
Windows Services for UNIX 3.5 components provide interoperability between Microsoft® Windows® and UNIX platforms. Accordingly, you can use Windows Services for UNIX to manage and conduct activities and tasks on both platforms and to share information between the two. This includes sharing files, centralizing and managing passwords and groups, and conducting character-based terminal sessions.
Windows Services for UNIX includes Interix, a complete, high-performance UNIX environment that provides two command shells (C and Korn) and more than 350 shell scripts, commands, and tools (such as the vi editor and Perl). Windows Services for UNIX also includes a complete set of development tools and libraries that you can use to port your UNIX-based applications to the Interix subsystem.
Figure 1.1 illustrates Windows, Windows Services for UNIX 3.5, and Interix.
This section and the subsequent sections explain the features of Windows Services for UNIX 3.5 and discuss the architectural differences between Windows Services for UNIX 3.5 and UNIX. You can use this information to understand the architectural differences between the two and analyze your application components accordingly.
Interix is a multiuser UNIX environment that operates on Windows. The Interix subsystem and its accompanying tools provide an environment that resembles any other UNIX system. It also includes case-sensitive file names, job control, and compilation tools. The Interix subsystem offers true UNIX functionality without any emulation because it is layered on top of the Windows kernel.
A computer running Windows Services for UNIX provides two different command-line environments—the UNIX environment and the Windows environment. The applications run on specific subsystems and in specific environments. When you run applications on the Interix subsystem, you get a UNIX environment; when you run applications on the Windows subsystem, you get a Windows environment.
The Interix subsystem provides both the tools and the API libraries for porting applications to run on Windows-based computers.
When installing Windows Services for UNIX 3.5, select the Custom installation choice. As a general user (not as a developer), install Active State Perl with the Custom installation. As a developer, choose Active State Perl plus both the Interix Software Development Kit (SDK) and the GNU SDK during installation. In addition, select Case Sensitive Pathnames and setuid Binaries to get the best UNIX behavior. With the SDK, which provides a front end for Microsoft Visual C++®, you can have a UNIX environment for development, but still have the benefits of the native compiler for Windows.
Architectural Differences Between UNIX and Interix
This section compares UNIX and Interix architectures, emphasizing the areas that directly affect software development. It explains architectural differences between the UNIX and Interix environments at a high level. You can use this information to become familiar with the high-level architecture of the Interix and Windows subsystems. UNIX architecture can be divided into the following three levels of functionality (as shown in Figure 1.2):
Kernel. Schedules tasks, manages resources, and controls security.
Shell. Acts as the user interface, interpreting user commands and starting applications.
Utilities. Supplement the basic capabilities of the operating system by providing useful utility functions.
Interix is a full application execution subsystem running beside the Microsoft Win32® subsystem that allows you to compile and run UNIX programs and scripts on Windows operating systems. The structure of Windows can be divided into the following four parts:
Environment subsystems. A set of programming environments that provide services to applications through an API, such as Win32 and Interix.
Functional subsystems. A set of protected subsystems that provides key operating system services to the environment subsystems, such as security, memory management, and input/output (I/O).
Windows NT® kernel. This contains the Windows NT Executive. This exports generic services that protected subsystems call to obtain basic operating system services.
Hardware abstraction layer (HAL). This allows kernel and device drivers to interact with hardware devices at a general level.
Figure 1.3 shows the Windows architecture and how Interix is placed in it.
Features in Interix
This section discusses the implementation mechanism of several features in the Interix subsystem. Because of the implementation differences between major features in UNIX and Interix, UNIX code must be modified for it to work in the Windows environment using Windows Services for UNIX 3.5. The implementation differences between the two are described in the following sections of this chapter:
Development and Debugging Tools
This section describes the implementation of the process management-related mechanisms in the Interix subsystem. Multitasking operating systems such as Windows and UNIX must manage and control many processes simultaneously. Each process has its own code, data, system resources, and state. These resources include virtual address space, files, and synchronization objects. The following sections provide more information on the manner in which UNIX and Windows manage these processes. This section will help you understand the implementation of these mechanisms in the Interix environment.
Using Windows Services for UNIX 3.5, jobs can be run in the foreground or background, or they can be suspended and resumed. From within an Interix shell, it is even possible to control Windows jobs. The priority value of the process can be adjusted using the nice command. However, Interix maps nice values to Windows process scheduling priorities according to a set of rules, which are discussed in Chapter 2, “Developing Phase: Process Milestones and Technology Considerations” of this volume.
The Interix system uses the UNIX multiuser model for hosting multiple users on a server running Windows. As a result, Windows can host a similar number of users running UNIX applications as expected on a stand-alone system running UNIX.
With the release of Windows Services for UNIX 3.5, the Interix subsystem has extended its POSIX support to include much of the Pthread model and Pthread interfaces necessary for conformance to the IEEE Std1003.1 2001 standard. Interix supports many pthread functions associated with Portable Operating System Interface (POSIX) options, but the corresponding symbolic constants are not defined in the unistd.h file because Interix does not implement the complete set of functions associated with that option.
Although POSIX_THREAD_PRIORITY_SCHEDULING is defined, Interix only supports the SCHED_OTHER scheduling policy and does not support the SCHED_RR or SCHED_FIFO policy. PTHREAD_SCOPE_SYSTEM is the only scheduling contention scope that Interix provides. This means that all threads on the system are scheduled with respect to each other, regardless of the process that owns the thread.
Note More information on Pthread APIs implementation in Interix is available in the “Appendix A–Pthread APIs Implemented in Interix” section at http://www.microsoft.com/technet/interopmigration/unix/sfu/pthreads0.mspx.
Interix maintains a process hierarchy, and even tracks the parent-child relationship of Win32 processes on the same system. The Interix command ps -efi displays processes and their relationship to each other. The -i option is specific to Interix and its output is indented to display the process hierarchy. The indentation represents the process tree. Each process is followed by its child processes recursively.
In some versions of UNIX, an application can provide for automatic cleanup of child processes by calling the signal() function as follows:
Signal (SIGCHLD, SIG_IGN)
However, in the POSIX standard, the result of setting SIG_IGN as the signal handler for SIGCHLD is undefined. Therefore, you cannot use this method to automatically clean up child processes in portable applications in Interix.
The Interix subsystem supports only one set of signal semantics—the POSIX.1 set. However, it supports several different sets of signal-handling APIs. Table 1.1 lists these signal sets.
Table 1.1. Signal Sets Supported by Interix
Signals are supported with the function signal(). Built on POSIX.1 sigaction().
It might not behave in the same way.
Signals are supported with the functions: sigaction() sigpending() sigprocmask() sigsuspend() sigemptyset() sigfillset() sigaddset() sigdelset() sigismember()
Signals are supported with the functions: killpg()
The signal mask for these functions is an int, not a sigset_t. Although sigpause() is provided, it is a System V call, which does not behave in the same way as the Berkeley Software Distribution (BSD) call.
Signals are supported with the functions: sighold()
The following important information applies when you are using signals with Interix:
Signals on a POSIX.1 system are neither BSD nor System V Interface Definition (SVID). POSIX defined a new signal mechanism based on the sigaction() API. However, modern BSD and SV systems support the POSIX.1 signal model. Therefore, source will become more portable using the POSIX.1 model.
The set of signals available is the set described in POSIX.1 and the single UNIX specification. The code of the user should use symbolic names instead of the actual values because some numbers might differ from traditional implementations.
Because an Interix process has a signal mask, it can block certain signals from arriving, except for SIGKILL or SIGSTOP. A process starts with a signal mask inherited from its parent. If any signals are generated and then blocked by the signal mask, they go into the set of pending signals.
If you are using the signal() API, the signal is still masked and remains masked until the mask is cleared. This can be a significant problem if your code does a longjmp() from the handler. Using the sigaction() API directly and the siglongjmp() API will correct some of those unexpected behaviors.
Note More information on process management in Interix is available in “Process Management” in Chapter 3, “Process and Thread Management” of this volume.
Interix supports POSIX-compliant threads, a mechanism for providing concurrent code execution through multiple flows of control in a single program. In addition to its own thread ID, each thread has its own scheduling priority and policy, as well as a thread-specific value for error number. You can use this information to identify the thread-specific implementations in the Interix subsystem.
Writing code that executes properly in multithreaded applications requires special care. For example, some functions use global or static data, and therefore calling these functions from separate threads might cause a function call in one thread to corrupt the data relied upon by a call to the same function in another thread. The individual reference entries in the Interix subsystem interface reference and the SDK man pages indicate whether each routine is multithread-safe (MT-safe). If you want to call functions that are not MT-safe in a multithreaded application, you should ensure that the functions cannot be called concurrently in more than one thread.
In a multithreaded application, problems can occur when routines are called between a call to the fork() function and a call to a member of the exit() or exec() function families. A prototype of the functions fork, exit, and exec family is defined as follows.
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
pid_t fork (void) void exit (int status) int execl (const char *path, const char *arg ...) int execle (const char *path, const char *arg ... char *const envp) int execlp (const char *file, const char *arg ...) int execv (const char *path, char *const argv) int execve (const char *path, char *const argv, char *const envp) int execvp (const char *file, char *const argv)
If a routine is async-signal safe, that is, can be safely called in this situation, the reference topic in the Interix subsystem interface reference and man page for that function states that it is async-signal safe. Do not call routines that are not explicitly stated to be async-signal safe between calls to the fork() and exit() or exec() function.
Note More information on thread support in Windows Services for UNIX 3.5 is available at
More details on thread management in the Interix subsystem is also available in “Thread Management” in Chapter 3, “Process and Thread Management” of this volume.
The Interix subsystem supports the following memory management-related features:
Most memory functions available in UNIX.
Memory-mapped files by using the mmap function.
All of the System V IPC mechanisms, including the shared memory routines shmat, shmctl, shmdt, and shmget.
POSIX V IPC.
The command-line interfaces ipcs and ipcrm are also provided for the management of shared memory segments. The ipcs interface reports the status of interprocess communication objects. The ipcrm interface removes an interprocess communication identifier, such as a shared memory segment.
Interix supports all of the System V semaphores, including the shared memory routines semctl, semget, and semop.
Note More details on memory management in the Interix subsystem is available in “Memory Management” in Chapter 4, “Memory and File Management” of this volume.
Interix supports the UNIX file management system. Interix has a single-rooted, case-sensitive file system that supports both hard and symbolic links. The single-rooted system is mapped to a multidrive Windows file system.
The Interix root directory (/) is mapped to the Windows Services for UNIX installation directory, which is typically C:\SFU. Under the root directory are typical UNIX directories, such as /usr, /bin, /dev, and /etc. In addition, there are also other, less familiar Interix-specific directories, such as /net, as well as directories that are a part of the Windows Services for UNIX installation, such as /admin.
You can access the drive letters mounted on your Windows system through the special /dev/fs/A through /dev/fs/Z directories. For example, to change the current directory to the root of the C drive, type cd /dev/fs/C. Case-sensitivity of the directory and file names is an optional choice and can be selected by the user during the installation of Windows Services for UNIX 3.5. You can access the folder only as /dev/fs/C if case-sensitivity is enabled. If case sensitivity is enabled, two files can be created on Interix that have the same name, but differ only in case. In such a case, only one file will be visible on Windows, and it is not possible to predict which one will be visible.
File Names and Path Names
Although Windows and UNIX file systems do not allow certain characters in file names, the characters that are prohibited by each operating system are not the same. For example, a valid Windows file name cannot contain a colon (:), but a valid UNIX file name can. If a UNIX user attempts to create a file in a network file system (NFS) share on Server for NFS and if that file contains an illegal character in its name, the attempt will fail. To prevent this problem, Interix allows file-name character mapping to replace characters that are not allowed in a file system.
The following points compare the UNIX and Interix file systems and also discuss how Interix helps overcome these differences:
UNIX systems have a file system with a single, top-level directory called the root directory. The root directory, which is referred to with a forward slash (/), contains both files and subdirectories. All files in the file system are located below the root directory (/).
Interix has a single-rooted file system that supports both hard and symbolic links. The single-rooted system is mapped to a multidrive Windows file system. The Interix root directory (/) is mapped to the Windows Services for UNIX installation directory, which is typically C:\SFU. While viewing the contents of the root directory, Interix also displays certain virtual file systems such as /dev, /net, and /proc apart from the usual /etc and /usr that are displayed in UNIX.
The Interix shell interprets the back slash (\) as an escape character; this causes Windows path names to work incorrectly in this environment. You can use the winpath2unix and unixpath2win tools to convert the format of a specified path name between the Interix format (such as /dev/fs/C/Cat/dog) and the Windows format (such as C:\Cat\dog).
Path names in the Interix subsystem are case-sensitive. If Windows Services for UNIX is installed on a computer running Windows XP, the path names are case-sensitive only if you click the option of changing the default behavior of the computer to support case-sensitive file names during installation. There are instances of open source applications where multiple files differ only by case, hence turning this option on is recommended as a practice to avoid such conflicts and possible errors.
A path name that begins with more than one forward slash (/) is treated as though it begins with just one.
Interix does not support the Universal Naming Convention (UNC) syntax. However, Windows Services for Unix 3.5 provides a new virtual directory, /net, to access remote file systems by using names that are similar to UNC names. The standard UNC syntax of \\hostname\sharename must be changed to the Interix syntax–/net/hostname/sharename.
The mount command-line tool mounts the file system identified by sharename exported by the network file system (NFS) server identified by ComputerName and associates it with the drive letter specified by DeviceName. When mapping a drive to a NFS share, you can choose to perform either a hard or soft mount. In both hard mount and soft mount options, the application makes a remote procedure call (RPC) to access a file on the mapped drive. In case of a hard mount, if the call times out, the client for NFS will retry the call indefinitely until it succeeds. But in case of a soft mount option (the default), if the call times out, the client for NFS will retry the call a fixed number of times. Then, if the NFS server still does not return successfully from the call, it returns an error to the calling application.
Interix defines a line as ending with the \n character. But Windows defines a line as ending with the \r\n sequence. Some applications on Windows and Interix are sensitive to the precise line termination sequence. Windows-based programs may expect any text files to be in the Windows format (end-of-line marked by CR-LF) instead of the POSIX format (end-of-line marked by LF). You can use the flip tool, which is a file interchange program that converts text-file formats between POSIX and other formats (such as MS-DOS® and Apple Macintosh).
Note More details on file management in the Interix subsystem are also available in “File Management” in Chapter 4, “Memory and File Management” of this volume.
This section discusses the major features related to infrastructure services available in the Interix subsystem, such as security and daemons/services, and provides detailed information about their implementations in the Interix subsystem.
The security model for Interix on Windows differs from that of UNIX in the following ways:
In Windows, either a user or a group can own an object; whereas in UNIX, only a user owns an object.
In classical UNIX systems, a user with UID = 0 is termed as a superuser to whom all privileges are granted. Typically only the user called “root” is given this uid.
Because the Interix subsystem is built on the POSIX specification, it does not recognize a root user. Instead of a root user, the POSIX standard defines appropriate privileges for some operations. All supported privileges on a given system are granted to all users who are members of the Administrators group on that system. Not all privileges defined in POSIX or UNIX are available under Interix, which means that there are certain privileges that are granted to no user at all and certain privileges are granted only to the super user.
Interix does not recognize a single super user. In Interix, the Administrator account is closest in power and privileges to the root user in UNIX. Because the Security Accounts Manager database stores user and group accounts in the same database, group and user names must be unique. No group can have a name that is same as that of a user and vice versa. This is different from the single UNIX specification, in which users and groups are separate. Users can belong to many groups.
Windows Services for UNIX 3.5 enables a Windows-based server to function as a Network Information Service (NIS) server, integrating NIS domains with Microsoft Active Directory® directory service and giving Windows Active Directory administrators the capability to manage Windows and NIS domains together.
The client for NFS uses user name mapping to associate Windows users with user identifiers (UIDs) and group identifiers (GIDs). Mapping allows the actual user and group names to appear as the file owner and file group when a long directory listing is requested. This mapping is done solely for the purpose of communicating with NFS servers.
Daemons and Services
On traditional UNIX systems, a daemon is a process that runs for an extended period of time but does not have a controlling terminal. A Windows service is a background process that is similar to a daemon process. A daemon can run directly on the Interix subsystem, or it can be ported to run as a Windows service.
Unlike a daemon, a Windows service logs on to the computer with a user account. This allows the administrator to have greater control over the privileges granted to the service. When the service logs on with a domain account, Windows even allows the service to access network resources.
Interix lets you take advantage of both of these mechanisms to provide services such as inetd, which is a "super-server" for Internet services.
The Interix programs designed to run as daemons can be controlled using the usual UNIX mechanisms, such as by sending signals using the kill tool.
To support running Interix programs as Windows services, Interix has a program called service that administers Interix services. The service program registers, installs, starts, and stops an Interix program that is running as a service. This tool can also be used for some administration activities of Win32 services such as listing the Win32 services.
Services use the program psxrun.exe, which is installed by the Windows Services for UNIX 3.5 setup into the Windows system32 directory. Two daemons that can also run as services, inetd and syslogd, are also provided. These two tools have specific command-line options that should be specified while invoking them. The details of the command-line options can be found in the manual pages of the tools. The manual pages can be opened from a Windows Services for UNIX 3.5 shell session. The same information is also available in the Help manual of Windows Services for UNIX 3.5.
Windows includes the Service Control Manager, which starts with Windows and runs in the background, handling services on behalf of the operating system. Services are either automatic (which means they are started on system startup) or manual (which means the user starts them). Services are controlled through the Windows Services for UNIX administration tool. You can use this tool to add, remove, view, start, and stop services.
To run a service, your account must be assigned the service logon right. This privilege is automatically given to your account the first time you start or install a service using the Interix service tool. However, it is possible for the administrator to remove this right from your account to prevent it from running services.
A service has no console display. You can stop it in Windows by opening Services or by using the service tool in Interix.
A service runs in a minimal environment, which consists of the TZ environment variable and the environment assigned to the default user of the system. Its standard input, output, and error are all redirected to /dev/null.
Note More details on infrastructure services in the Interix subsystem are available in Chapter 5, “Infrastructure Services” of this volume.
Development and Debugging Tools
The Interix SDK provides a front end for Microsoft Visual Studio® to compile C programs. This provides a native UNIX environment for development based on a native Windows compiler. If Interix GNU SDK is also installed in the development environment, then the standard UNIX development tools, such as the GNU gcc, g++, g77 compilers and the gdb debugger, are also available. The Interix SDK supports using Visual C++ in the compilation of C programs, but not C++ programs. The make tool is based on the OpenBSD version of make. The lex and yacc tools are based on the flex and BSD yacc.
The Interix SDK supports shared libraries. Dynamic linking is supported through standard calls—dlopen(), dlsym(), dlclose(), and dlerror(). Dynamically linked applications and shared libraries can only be created using gcc and the other GNU compiler tools. However, cc and c89 will still produce statically linked binaries. The Interix GNU SDK should be installed in order to use the gcc compiler to create the shared libraries.
Developers can use the Interix GNU SDK to create real, UNIX-style .so libraries. Although similar to Windows dynamic-link libraries (DLLs), they are not the same in implementation or semantics.
For efficient debugging, the Interix GNU SDK provides the GNU debugger, gdb. The base installation also contains debugging tools such as pstat and truss.