gridengine.info

In general Windows offers the same or similar functionality to UNIX. Even so, the system calls have different names, and there is often no exact equivalent for many system calls. For this reason, one can’t simply use #define or a simple adapter library to translate the UNIX function calls into Windows function calls.

To get around this problem, we use Interix for the Windows port. Interix is a POSIX subsystem and part of the "Microsoft Services for Unix" (SFU).

Windows consists of the actual Windows kernel and the various subsystems that enable the applications to talk to the kernel in a specific way. In Windows, the WIN32 subsystem is used most. Occasionally the WIN16 subsystem also turns up. WIN16 allows old Windows 3.11 applications to run on Windows NT/2000/XP.

Interix makes it possible for UNIX applications to run on Windows with relatively minimal adjustments. All of the standard Interix libraries were taken over from HP-UX – to the extent possible. Interix has therefore also inherited some peculiarities from HP-UX.

Interix cannot be 100% UNIX. For things that are managed by the Windows kernel and not by the subsystem, Interix can translate, but it can’t change the behavior. For example, Interix cannot translate the Windows superuser "Administrator" into the UNIX superuser "root" because that user is managed by the kernel.

The user UID and GID and "security identifiers" (SID) in Windows of the form "S-1-5-21-1844237615-1606980848-1060284298-500". These SIDs are translated by Interix into 6-digit numbers for local users and 7-digit numbers for Windows Domain Users. The user ids therefore cannot be specified, but are automatically generated by Windows, and in turn automatically translated into UIDs by Interix.

Network access – only fully authenticated users have network access rights, so the user password must be registered. One does that for "rlogin" with "regpwd". Our execution daemon has its own "sgepasswd" for that purpose. Regardless, it is not possible with Interix to use the setuid-root functionality (when a binary has the permissions, -r-s——) over a network filesystem. That functionality only works over local filesystems. "sgepasswd" is a setuid-root binary. When SGE is installed on a network filesystem, as is common practice, sgepasswd cannot be used from Interix. It can only be used from a UNIX machine.

In addition, Interix does not offer an API that one can use to talk directly to the kernel. WIN32, on the other hand, has such an API. For this reason, one must port everything that needs direct access to the kernel to WIN32. For us, that includes the load sensor "qloadsensor.exe" and the "N1 Grid Engine Helper Service" (whose executable is called SGE_Helper_Service.exe).

The helper service makes it possible to start Windows jobs that have to display their GUIs on a visible desktop to function. Actually, Windows applications don’t necessarily have to work that way. Windows also offers virtual desktops that can be run in the background. The problem is that many Windows applications display their error messages only in dialog windows, and the only way to determine, for example, that an environment variable is missing, is to be able to read the messages displayed in the dialog window.

One further limitation on Interix is the group permissions for Windows users. This has the greatest effect on the administrator. In Windows, one can have as many administrators as one pleases. Every user in the "Administrators" group is an administrator. Because Interix is a POSIX subsystem, and POSIX only allows exactly one superuser, Interix only allows the user "Administrator" as superuser, independent from group membership. (Don’t ask me how that can be done internally when Interix isn’t supposed to be able to have any influence over the users.)

In Windows one normally uses a domain to manage the computer. The users are managed from the domain and authenticated against the domain. There are very few special local users on the individual machines. In Interix these users can be explicitly referenced by their "fully qualified names," in the form <domain>+<user>. <domain> is included whether it’s the Window domain or the name of the local machine, as every machine has its own small, local domain. There is a default domain or principal domain that can be requested with "pdomain". If one enters the short form of the user name (only <user>), Interix automatically prepends the principal domain. The principal domain normally corresponds to the Windows domain.

So that one can access NFS filesystems, an NFS client with User Name Mapping is included in SFU. The User Name Mapping creates an association between the Windows user and the UNIX user on the NFS server. More specifically, it makes sure that a Windows user who has an SID that Interix would translate, for example, into "1001" can access data that the UNIX user with the UID, "1001", owns.

This NFS client is, however, not part of Interix and must not be used. One could, for example, use Samba, except that we’ve never tested it, but we’ve heard of customers trying it.