Chapter 1: Introduction to Win32/Win64

This chapter describes how you can modify the source code of your UNIX applications so that the code compiles on the Microsoft® Windows® operating system using the Microsoft Win32® and Win64 application programming interfaces (APIs). This chapter also describes the improvements that Win64 offers over Win32. It discusses the differences in the Win64 design and the 64-bit UNIX design in terms of Windows and UNIX data models—namely, the P64 of Windows (also called LLP64) and the LP64 of UNIX. This chapter also includes a brief overview of the differences in the way the various resources are managed in UNIX and Windows.

On This Page

Overview of Win32/Win64 Overview of Win32/Win64
Architectural Differences Between UNIX and Windows Architectural Differences Between UNIX and Windows

Overview of Win32/Win64

This section gives an overview of the 32-bit and 64-bit APIs, their implementation mechanism on UNIX and Windows, and the differences between them. With this knowledge, you can identify key sections of the application to be modified for compatibility in the Win32/Win64 environment. You can also obtain information on the critical points to consider when porting the UNIX application to the Windows environment using the Win32/Win64 APIs.

UNIX applications are mostly written in C or C++ languages or are based on shell scripts. In both cases, Microsoft provides good support for porting the applications to Windows.

When porting UNIX applications to Windows, the UNIX system calls in the UNIX applications must be mapped to the corresponding Windows API calls. There are also differences in the UNIX architecture and 64-bit Windows (Windows Server™ 2003) architecture, which affect the performance of the UNIX application on Windows.

The following sections discuss the improvements that Win64 offers over Win32 and also compares the 64-bit architecture of Windows to that of UNIX.

Note The Windows API was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows. The name Windows API is used in this volume except when comparing 32-bit Windows programming with 64-bit Windows programming. They are then referred to as Win32 and Win64 APIs, respectively.

Overview of 64-Bit Windows

The 64-bit versions of Windows operating systems support up to 16 terabytes of random access memory (RAM) whereas 32-bit versions can only support up to 4 gigabytes. Increased RAM support is a major benefit of using a 64-bit operating system because of the following reasons:

  • All or part of each application must be replicated for each user, which requires additional memory. Therefore, by having more memory, each application can support more users.

  • Increased memory allows more applications to run simultaneously and remain completely resident in the main memory of the system. Applications resident in the main memory provide better performance.

  • Data-intensive applications, such as databases and graphics modeling, also benefit from the larger amount of memory because they can store and manipulate large amounts of data more easily and reliably.

  • Scientific and high-performance computing applications also benefit from the large amount of memory available in the 64-bit version as they require relatively larger memory for high precision computations.

Overview of the Windows API

The Windows API allows applications to take full advantage of the power of the Windows family of operating systems. Using the Windows API, you can develop applications that run successfully on all versions of Windows, thereby taking advantage of the features and capabilities unique to each version.

The Windows API consists of the following functional categories:

  • Base Services

  • Common Control Library

  • Graphics Device Interface

  • Network Services

  • User Interface

  • Windows Shell

The standard Windows API provides a uniform development environment. The Windows API provides a good interface to access and use kernel or system objects using handles. The Windows API also provides many synchronization and communication mechanisms.

The Windows API also supports programming on 64-bit versions of Windows operating systems. The Win64 API takes advantage of the benefits of the 64-bit Windows architecture. The programming model and API functions are almost the same as in Win32; the main difference between them is the size of the pointers and, consequently, the parameters holding the pointers. In Win64, the size of the pointers is 64 bits; and in Win32, it is 32 bits.

A new set of data types is also defined in Win64 to write cleaner code. In the Win32 API, data types long and pointers were of the same size, so data types such as DWORD and pointers could be used interchangeably and could also be used to typecast from one to another. The same code in Win64 would lead to errors because in the Win64 API, long is 32 bits while pointer is 64 bits.

64-Bit Programming in UNIX and Windows

The key difference between 64-bit programming in UNIX and Windows is the programming model. UNIX uses the LP64 model and Windows uses the LLP64 model.

The LLP64 data model is sometimes described as a 32-bit model with 64-bit addresses. In this model, int and long are 32-bit types and pointers are 64 bits. Data objects such as structures, which do not contain pointers, are of the same size as on a 32-bit system. A 64-bit data type longlong (or int64) is introduced to substitute for a 64-bit type of int and long.

In the LP64 data model, long is a 64-bit type, pointers are 64 bit, and no new data types are introduced. The difference in data types between the two models are listed in Table 1.1.

Table 1.1. Differences Between LLP64 and LP64 Data Types

Data Type

LLP64 (size in bits)

LP64 (size in bits)

char

8

8

short

16

16

int

32

32

long

32

64

longlong (int64)

64

 

pointer

64

64

Following are some additional facts about the LLP64 and LP64 models:

  • In the data models of both UNIX/64 and 64-bit versions of Windows Server 2003 operating systems, abstract types are defined in terms of basic types. This means that when you use abstract types, you ensure that parameters and structure fields always contain the correctly sized data for 32-bit or 64-bit compilation.

  • In the UNIX/64 data model:

    • The size of int is 32 bits and the size of long and pointers is 64 bits.

    • There are some new explicitly sized types.

    • There are a few new functions.

    • The most scalable and biggest architecture data type is long.

  • In the Win64 model:

    • The Windows API follows the Uniform Data Model (UDM). UDM proposes to use identically named data types for both the Win32 and Win64 environments. Using this model, you can maintain a single source code development environment for both Win32 and Win64, provided no architecture-specific design features are implemented.

    • The size of int and long is 32 bits; the size of int64 (new type) and pointers is 64 bits.

      Abstract types are identical for 32-bit and 64-bit environments, thus simplifying cross-compilation for both of them.

    • There are explicitly sized and scalable data types.

  • Some types are "upgraded" and can also be used in Win32 sources.

    • The scalable and biggest architecture integral type depends upon the platform. Microsoft recommends using conditional compilation of either long or int64; a preprocessor macro can be defined to simplify this complication.

    • Some functions are revised because of polymorphism. Most of the other APIs remain the same.

For more information on data type differences, refer to the “64-bit Programming in UNIX and Windows” section in Chapter 2, “Developing Phase: Process Milestones and Technology Considerations” of this volume.

Comparison of Win32 and Win64

This section compares the major differences between the Win32 and Win64 APIs:

  • Data model. The Win64 data model is almost the same as that of Win32. However, new data types and pointers have been added. In the ILP32 data model (of Win32), integer, long, and pointer data types are 32 bits, whereas in the LLP64 (or P64) data model, the pointer data type is 64 bits.

Note You need to look at the sections of code where integer, long, and pointer are used interchangeably. Such code would work in Win32 but cause major issues in Win64, and you might face issues when migrating a UNIX 32-bit application to a Windows 64-bit environment.

  • Environment. The Win64 API environment is almost the same as the Win32 API environment—unlike the major shift from Win16 to Win32. The Win32 and Win64 APIs are now combined and called the Windows API. Using the Windows API, you can compile the same source code to run natively on either 32-bit Windows or 64-bit Windows. To port the application to 64-bit Windows, just recompile the code.

    The Windows header files are modified so that you can use them for both 32-bit and 64-bit code. The new 64-bit types and macros are defined in a new header file, Basetsd.h, which is present in the set of header files included by Windows.h.

    The Basetsd.h file includes the following:

    • New data-type definitions that you can use to make your application word-size independent.

    • Many helper functions for conversion such as:

      unsigned long HandleToUlong (const void *h)
      

long HandleToLong (const void *h) void *LongToHandle (const long h) unsigned long PtrToUlong (const void *p) unsigned int PtrToUint (const void *p)

  • Data types. There are three categories of new data types that are supported on 64-bit Windows: fixed-precision data types, pointer-precision types, and specific-precision pointers.

    These new data types are available in the latest 64-bit SDK. There is also a set of functions available to perform conversions in a safe manner so that the same code would run on both the 32-bit and 64-bit platforms.

    When compiling, use the Win64 compiler to display warnings regarding truncation of pointers, invalid type casts, and any other 64-bit–specific issues. After the code is fixed and the compiler no longer shows these warnings, you can use the code safely on both 32-bit and 64-bit platforms.

    For example, the following code can generate the C4311 warning:

    C4311 warning message is 'variable': pointer truncation from 'type' to 'type'. A 64-bit pointer was truncated to a 32-bit int or 32-bit long.

buffer = (PUCHAR)srbControl; (ULONG)buffer += srbControl->HeaderLength;

To correct the code, make the following changes:

<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">buffer = (PUCHAR)srbControl;

(ULONG_PTR)buffer += srbControl->HeaderLength;

Additional information about the Win64 compiler is available at  
<https://msdn.microsoft.com/>.
  • Process interoperability. Windows-32-On-Windows-64 (WOW64) is the x86 emulator that enables Win32 applications to be run on 64-bit Windows operating systems.

    Processes can load dynamic-link libraries (DLLs) of the same type. For example, a 64-bit application can load a 64-bit DLL but not a 32-bit DLL, whereas out-of-process Component Object Model (COM) servers can interact with both 32-bit and 64-bit clients. Therefore, the DLLs can be wrapped in an out-of-process COM server to allow communication with any kind of application.

Porting from Win32 to Win64

Programming in the Win64 API is the same as in the Win32 API. Apart from a few new data types, a few data types that have changed, and a few new APIs, the rest of the Win32 APIs remain the same. This is because the required functions have been modified internally to gain maximum benefit from the platform, but the interface stays the same.

The data types that have changed from 32-bit to 64-bit need to be handled carefully in order to make the code compatible with Win64. Details of the same are covered in the "Rules for Making Win32 Code 64-bit Compatible" section in Chapter 2, “Developing Phase: Process Milestones and Technology Considerations” of this volume.

Data Types

Following are the three classes of data types available in Win64:

  • Fixed-precision. Fixed-precision data types are of the same length in both 32-bit and 64-bit Windows operating systems.

  • Pointer-precision. As the pointer-precision changes (that is, as it becomes 32 bits on 32-bit Windows and 64 bits with 64-bit Windows), these data types reflect the precision accordingly. Therefore, it is safe to cast a pointer to one of these types when you perform pointer arithmetic; if the pointer-precision is 64 bits, then the type is 64 bits. The count types also reflect the maximum size to which a pointer can refer.

  • Specific-precision pointer types. There are also new pointer types that explicitly size the pointer. Be cautious when using pointers in 64-bit code. If you declare the pointer using a 32-bit type, the operating system creates the pointer by truncating a 64-bit pointer. (All pointers are 64 bits on 64-bit Windows.)

Note Additional information on data types in Win64 is available at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/win64/win64/the_new_data_types.asp.

Architectural Differences Between UNIX and Windows

This section discusses the architectural differences between UNIX and Windows relating to process and thread management, memory management, and file management. You can use this information to understand the existing implementation mechanism of the preceding aspects in the UNIX application and to identify the best approach to migrate them into the Windows environment using the Win32/Win64 APIs.

Note   These topics are discussed in more detail in subsequent chapters of this volume.

Process and Thread Management

Multitasking operating systems, such as Windows and UNIX, must manage and control multiple processes at once. Each process has its own code, data, system resources, and state. Resources include virtual address space, files, and synchronization objects. Threads are a part of a process; each process has one or more threads running on its behalf. Like a process, a thread has resources and a state associated with it. The Windows and UNIX operating systems both provide processes and threads.

The following sections provide more information on how UNIX and Windows manage processes and threads.

Multitasking

UNIX was designed to be a multiprocessing, multiuser system that enables users to create and run many processes at the same time.

Windows has evolved from the MS-DOS® operating system, which does not support preemptive multitasking. Preemptive multitasking is one of the major features of real-time applications. To port the UNIX real-time application to the Windows XP environment, Real-Time Extensions (RTX) for Windows XP can be used. Additional information on Real-Time Extensions for Windows XP is available at
https://msdn.microsoft.com/embedded/getstart/testimonial/xp/xpqa/jaokeefe/default.aspx.

Windows relies heavily on threads for multitasking instead of processes. A thread is a construct that enables parallel processing within a single process. A user can implement multitasking by using multithreading. Creating a new process in Windows is a relatively more resource-consuming operation.

Multiple Users

One key difference between the UNIX and Windows operating systems is the way in which multiple users log on simultaneously to the same computer.

On UNIX, when a user logs on, a shell process is started to service the user’s commands. The UNIX operating system keeps track of users and their processes and prevents processes from interfering with one another.

On Windows, when a user logs on interactively, the Win32 subsystem’s Graphical Identification and Authentication (GINA) dynamic-link library creates the initial process for that user. This process is known as the user desktop. This desktop is where all user interaction or activity takes place. Only the logged-on user can control the computing environment (sometimes known as the shell). Other users are not able to log on to that computer at the same time. However, if a user uses Terminal Services or Citrix, Windows can operate in a server-centric mode, much as UNIX does. For more information, refer to the “Windows Terminal Services and Citrix” section later in this chapter.

Multithreading

UNIX threads are built upon the Portable Operating System Interface (POSIX) standard—Pthreads. Implementing Pthreads can be user-based or kernel-based depending on the implementation used by the vendor. Most new UNIX kernels are multithreaded to take advantage of Symmetric Multiprocessing (SMP) computers.

Initially, UNIX did not expose threads to programmers. However, POSIX does have user-programmable threads. In fact, POSIX has two different implementations of threads, depending on the POSIX version. Windows applications use threads to take advantage of SMP computers and to maintain interactive capabilities when some threads take a long time to execute. Windows Server 2003 supports preemptive multitasking, which creates the effect of simultaneously executing multiple threads from multiple processes.

In UNIX, in the case of multiple processes running at the same time, small intervals of central processing unit (CPU) cycles are assigned to each process so that, in actuality, only one process runs at any given point of time. Each process is also assigned a priority, and the process with the highest priority gets the CPU first. To prevent high-priority processes from starving other processes, the scheduler may decrease the priority of the currently running process at each clock tick. This enables preemption of the next process with the highest priority to start.

Windows XP uses a quantum-based, preemptive priority scheduling algorithm. The major difference is that threads are scheduled instead of processes. The currently running thread always has the highest priority. Preemption of any thread can happen when a higher priority thread becomes ready, the current thread terminates, or the time quantum for the current thread is exhausted.

Process Hierarchy

When a UNIX-based application creates a new process, the new process becomes a child of the creating process. This process hierarchy is important, and there are system calls for manipulating child processes.

Unlike UNIX, Windows processes do not share a hierarchical relationship. The creating process receives the process handle and the ID of the process created by it so that a hierarchical relationship can be maintained or simulated if the application requires it to do so. However, the operating system treats all processes as belonging to the same generation.

Note Both Windows and UNIX processes inherit the security settings of the creating process by default.

Daemons and Services

In UNIX, a daemon is a process that the system starts to provide a service to other applications. Typically, the daemon does not interact with users. UNIX daemons are started at boot time from init or rc scripts.

A Windows service is the equivalent of a UNIX daemon. It is a process that provides one or more facilities to client processes. Typically, a service is a long-running, Windows-based application that does not interact with users and consequently does not include a user interface. Services may start when the system boots and they continue running across logon sessions. Services are controlled by the Service Control Manager (SCM). One of the requirements for writing a service is that it must communicate with the SCM to handle starting, stopping, and installing applications. A service runs in user mode with a specific user identity because it runs in a separate process. The security context of that user determines the capabilities of the service. Most services run as the local system account. This account has elevated access rights on the local computer, but it has no privileges on the network domain. If a service needs to access network resources, it must run as a domain user with enough privileges to perform the required tasks. On UNIX, a daemon runs with an appropriate user name for the service that it provides or as the special user who is anonymous.

Summary of Processes and Threads

Table 1.2 lists the differences between Windows and UNIX in terms of processes and threads.

Table 1.2. Windows and UNIX Processes and Threads

Feature

Windows

UNIX

Primary mechanism

Threads

Processes

Processes

Yes

Yes

Threads

Yes

Yes, but different implementations.

Performance

Very good at creating threads.

Very good at creating processes.

Process hierarchy

No, but the information can be collected and acted on by the application itself.

Yes

Security inherited

Yes

Yes (except setuid)

Memory Management

Both UNIX and Windows use virtual memory to extend the memory available to an application beyond the actual physical memory installed on the computer. In UNIX, virtual memory is handled by the kernel; while in Windows, it is handled by an executive service. Virtual memory uses a number of techniques to perform the following tasks:

  • Inform the application that additional memory is available.

  • Transparently enhance system performance (and therefore application performance) by reading for disk space as efficiently as possible.

Virtual memory uses areas on the disk to extend real memory. In addition, the virtual memory manager moves program and data files from the hard disk into physical memory only when the files are needed. There is no need to consider virtual memory during the migration process because the virtual memory is managed by the operating system and is transparent to applications.

File Management

This section describes the file system characteristics of UNIX and Windows. Table 1.3 lists the basic features of modern file systems.

Table 1.3. File System Features

Feature

Description

File names

User-defined name associated with the physical file, typically 255 characters or more.

Directories

Named folders to store files, usually arranged in a hierarchical, tree-like structure.

Path names

Way of referring to a specific file or directory at a particular place.

Aliases, links, and shortcuts

Methods for pointing one file at another or for giving a file multiple names.

Security

Method of protecting and controlling access to files and directories.

File information

Method of storing the properties of a file, such as creation date, modification time, size, and location on disk.

Both UNIX and Windows support many different types of file system implementations. Some UNIX implementations support Windows file system types, and some products can be used to provide Windows support for some UNIX file system types.

File Names and Path Names

Everything in the file system is either a file or a directory. UNIX and Windows file systems are both hierarchical, and both operating systems support long file names of up to 255 characters. Almost any character is valid in a file name, except for the following:

  • Forward slash mark (/) in UNIX.

  • Question mark (?), straight quotation mark ("), forward slash mark and backslash (/ and \), greater than and less than (> and <), asterisk (*), vertical bar (|), and colon (:) in Windows.

  • Names that conflict with device names.

In UNIX, a single directory, known as the root, is at the top of the hierarchy. You locate all files by specifying a path from the root. The UNIX notation for file paths is a series of directory names separated by a single forward slash mark, followed by the file or directory name. The root directory is named /, so a path begins with /, for example, /etc/passwd. Paths can also be specified as relative to the current working directory (represented as “.”) or the parent of the current working directory (represented as “..”).

UNIX makes no distinction between files on a local hard drive partition, CD-ROM, floppy disk, or networked file system. All the files appear in one tree under the same root. To accomplish this, UNIX uses a process called mounting. New file systems (for example, a hard drive partition) are mounted on an empty directory and then appear as part of the file system directory tree. Hence, UNIX treats any external device as another directory by the process of mounting and places it under the root directory.

The Windows file system uses a drive letter abstraction at the user level to distinguish one disk or partition from another. For example, it may assign a drive letter for each partition and for each network drive. As in UNIX, a path in Windows is defined by a series of directories and a file name, but the separator is a backslash. The drive name (for example, C or D) or the Universal Naming Convention (UNC) name (for example, \\SERVER\\SHARE) may also need to be specified. However, Windows can use “.” and “..” just as UNIX does.

UNIX File System Features

UNIX treats all files as streams of data with no boundaries or structure. In UNIX, each file in the file system is described by an inode. An inode is not the same as a file name. Instead, it refers to the following information about the file:

  • Permissions

  • Owner

  • Type

  • Date and time of creation, last access, and modification

  • Size

  • Pointers to the data blocks allocated to the file

The inode does not contain the name of the file. A directory contains the file names and associated inodes. UNIX can also create hard links and symbolic links, which allow a file to appear in more than one directory with more than one name. In the UNIX file system, devices are also represented by files. Device files are usually found in the /dev directory. For example, you can run a program and ignore all of its output by redirecting the output to the null device, /dev/null. It is also possible to send data directly to a serial port or terminal by using this technique. Some versions of UNIX even expose memory and running processes in this manner (/dev/mem and /dev/proc, respectively).

Applications, not the operating system, handle file structures. This design imparts a simplicity and uniformity to input/output (I/O), but it can cause performance issues for large files or busy systems if not handled carefully.

Windows File System Features

Windows supports three major file systems: FAT16, FAT32, and NTFS.

  • FAT16. This file system is supported by all Windows operating systems. It is allocated in clusters, the sizes of which are determined by the size of the partition. The larger the partition, the larger the cluster size. This file system is efficient in speed and storage on volumes smaller than 256 MB.

  • FAT32. This file system is supported by Windows, as well as a number of newer Microsoft operating systems. The major difference between FAT16 and FAT32 is the volume and cluster sizes. This file system can support drives up to 2 terabytes in size. It also uses smaller clusters, resulting in more efficient usage of disk space relative to the larger FAT16 drives.

  • NTFS. This is the preferred file system for all computers running Windows. It can support drives up to 16 exabytes and also manages disk space efficiently by using smaller clusters. It provides some other advantages, such as automatic data recovery techniques and compression capability on volumes, folders, files, and disk quotas to set the amount of usage allowed by end users.

The file allocation table (FAT) is a list of entries that map to each cluster on the partition. Each version of the FAT file system uses a different size for FAT entries. The FAT16 file system uses 16 bits for each entry while the FAT32 file system uses 32 bits. It also uses a single linked list data structure to index and store file system data. In NTFS, all file attributes are stored as metadata, and it uses B+ trees to index file system data.

Networked File Systems

File systems do not have to be stored on a local drive (for example, a hard disk or CD-ROM). Users and applications can access them over the network from a server or peer computer. To do this, the operating system uses special file systems that work over the network and are called networked file systems.

The standard UNIX network file system is the network file system (NFS). Developed by Sun Microsystems, this technology is licensed to most UNIX vendors and is designed to integrate into the UNIX file system model. An NFS server exports a directory, and an NFS client mounts the exported directory just as it would mount a local file system. To the user, the networked file system appears to be just another part of the directory tree.

UNIX also has an automount mechanism. Automount directories are automatically made available when an application attempts to access them. They are then dismounted after a period of inactivity. The automount mechanism reduces the number of network file systems mounted, thereby simplifying administration.

NFS is a client/server implementation. The actions that are executed on the server are minimal. The server does not keep any state associated with the client and all the state data is kept on the client. This method of retaining state ensures that the server can perform quickly and efficiently but places many requirements on the client.

Server Message Block and Common Internet File System

One of the earliest implementations of network resource sharing for the MS-DOS platform was network basic input/output system (NetBIOS). Features in NetBIOS allowed it to accept disk I/O requests and direct them to file shares on other computers.

The protocol used for this was named server message block (SMB). Additions were made to SMB to apply it to the Internet, and now the protocol is known as Common Internet File System (CIFS).

In Windows, the server shares a directory and the client connects to the UNC of that share. Each network drive usually appears with its own drive letter, such as X.

Windows and UNIX Network File System Interoperability

Windows and UNIX can interoperate by using NFS on Windows or CIFS on UNIX. A number of commercial NFS products are available for Windows. For UNIX, in addition to commercial implementations of CIFS, a software option called Samba is widely used. Samba is an alternative to installing NFS client software on Windows-based computers for interoperability with UNIX-based computers. Samba is an open-source, freeware, server-side implementation of a UNIX CIFS server. To provide file and print services, it implements security in the form of authentication and authorization. It also implements NetBIOS-style name resolution and browsing. On Windows, NFS support can be obtained by installing the Windows Services for UNIX product.

Note Additional information on using Windows Services for UNIX NFS gateway to Windows clients is available at https://support.microsoft.com/kb/324085.

Summary of File System Differences

The preceding sections discussed the architectures of the UNIX and Windows file systems, both of which are hierarchical but differ in many details. Table 1.4 lists the differences between the Windows and UNIX file systems.

Table 1.4. Summary of File Systems Differences

Feature

Windows

UNIX

Overall structure

Hierarchal, multiple trees

Hierarchal, single tree

Drive names

Yes (for example C, D)

No

Mounting partitions

Yes

Yes

Path separator

\

/

Case-sensitive names

No

Yes

Hard links

No

Yes

Symbolic links

No

Yes

Shortcuts

Yes

No

Network file system

SMB

NFS

Device files

No

Yes

Set user ID

No

Yes

Security

Access control lists (ACLs)

Simple bit permissions

Infrastructure Services

This section discusses the differences in the architecture of UNIX and Windows in the following topics:

  • Security

  • Handles

  • Signals, exceptions, and events

  • Interprocess communication

  • Networking

Security

UNIX and Windows architectures differ in many ways, including security implementation. This section describes some of these security implementation details and differences.

User Authentication

A user can log on to a computer running UNIX by entering a valid user name and password. Some UNIX implementations require optional extra credentials, such as smart cards (for example, with pluggable authentication modules on Solaris and Linux). A UNIX user can be local to the computer or known to a Network Information System (NIS) domain (a group of cooperating computers). In most cases, the NIS database contains little more than the user name, password, and group.

A user can log on to a computer running Windows by entering a valid user name and password. In addition, Windows requires optional credentials such as certificates and smart cards. A Windows user can be local to the computer, be known on a Microsoft Windows NT® domain, or be known in the Active Directory® directory service. The Windows NT domain contains only a user name, password, and user groups. Although Active Directory contains the same information as the Windows NT domain, it may also contain additional information for the user, such as contact information, organizational data, and certificates.

UNIX Security

UNIX uses a simple security model. The operating system applies security by assigning permissions to files. This model works because UNIX uses files to represent devices, memory, and even processes. Security permissions are applied to users or to groups.

In most cases, users are people who log on to the system, but users can be special users such as system services (daemons). In UNIX, each user has a user identifier (UID), which (unlike Windows) does not have to be unique. A user is logged on to the system when a shell process is running that has the UID of that user. Groups are sets of users. A UNIX group has a group identifier (GID). Every process has a UID and a GID associated with it.

Note The credentials that a user supplies when logging on are usually a user name and a password. Some implementations of UNIX support the use of smart cards for interactive logon. Smart cards support cryptography and help secure storage of private keys and certificates, enabling the strong authentication of users.

Security Permissions

When a user logs on to the system by entering a user name and a password, UNIX starts a shell with the UID and GID of that user. From then on, all access to files and other resources is controlled by the permissions assigned to the UID and GID or the process. The UIDs and GIDs are configured in two files: /etc/passwd and /etc/group, respectively.

Each file in the file system has a bitmap that defines its permissions. Read, write, and execute are the permissions that can be granted. These permissions are grouped in three sets: the owner of the file, the group of the owner, and everybody else (world). A full (long) listing for a file shows the file permissions as a group of nine characters that indicate the permissions for owner, group, and world. The characters r, w, x, and - are used to indicate read, write, execute, and no permission, respectively. For example, if the owner of a file has all permissions but the group and world have only read permission, the string is as follows:

rwxr--r--

Note Some UNIX implementations have extended the basic security model to include ACLs similar to those used in Windows. However, ACLs are not implemented consistently across all versions of UNIX.

Effective UID and Effective GID

There are occasions when a process started by a particular user must access resources for which the user does not have permissions. UNIX has a mechanism to handle this situation. Processes can have effective UIDs and GIDs that are different from the UID and GID of the user or the parent process. An effective UID or GID is one that the operating system uses for the duration of the process.

Network Information System

The UNIX operating system was originally designed to run on a server by itself and not on a network, in a manner similar to stand-alone Windows-based computers. When computers can access resources on other computers on a network, synchronization of users (UIDs) and groups (GIDs) across computers becomes a problem. If the numeric identifiers are not properly synchronized, access requests across the network could incorrectly identify the user or group, which would result in security breaches.

The Network Information System (NIS) solves this problem by using a client/server model for processing requests. One computer on a domain is designated the master computer. Computers that serve as backups to the master are known as subordinate computers. All other computers on the domain are clients. When a client application needs to check credentials, the call is forwarded to the master computer instead of being processed locally as it would be on a computer not running NIS. The master looks up the user information in a database file, called a map, and returns the results.

Windows Security

Windows uses a unified security model that protects all objects from unauthorized access. The system maintains security information for the following:

  • Users. The people who log on to the system, either interactively by entering a set of credentials (typically user name and password) or remotely through the network. The security context of every user is represented by a logon session. Each process that the user starts is associated with the logon session of the user.

  • Objects. The secured resources that a user can access. For example, files, synchronization objects, and named pipes represent kernel objects.

Figure 1.1 illustrates the Windows security model and the relationship between the process-level access token, the security descriptor of the object, and the discretionary access control list (DACL) for the security descriptor.

Figure 1.1. The Windows security model

Figure 1.1. The Windows security model

Access Tokens

An access token is a data structure associated with every process that is started by a particular user and is associated with the logon session of that user. The access token identifies the user and identifies security groups that the user is a member of. Although users and groups have human-readable names to ease administration, for performance reasons they are uniquely identified internally by security identifiers (SIDs).

Security Descriptors

A security descriptor describes the security attributes of each object. The information in the security descriptor includes the owner of the object, a system access control list (SACL), and a DACL. The DACL contains a list of access control entries (ACEs) that define the access rights for particular users or groups of users. The owner of the object controls the DACL and uses it to determine who should and should not be allowed access to the object and what rights should be granted to them.

The security descriptor also includes a system access control list (SACL), which is controlled by system administrators. Administrators use SACLs to specify auditing requirements for object access. For example, an administrator can establish a SACL that specifies the generation of an audit log entry whenever a user attempts to delete a particular file.

The sequence of events from the time a user logs on, to the time the user attempts to access a secure object, is as follows:

  1. The user logs on by entering a set of credentials. The system validates these credentials by comparing them against the information maintained in a security database (or Active Directory).

  2. If the user is authenticated, the system creates a logon session that represents the security context for the user. Every process created on behalf of the user (starting with the Windows shell process) contains an access token that describes the security context of the user.

  3. Every process subsequently started by the user is passed a copy of the access token. If one process results in additional processes, all child processes obtain a copy of the access token and are associated with the single logon session of the user.

  4. When a process (acting on behalf of the user) attempts to open a secure object, such as a file, the process must initially obtain a handle to the object. For example, when attempting to open a file, the process calls the CreateFile function. The process specifies a set of access rights on the call to CreateFile.

  5. The security system accesses the security descriptor of the object and uses the list of ACEs contained in the DACL to find a group or user SID that matches the one contained in the access token of the process. When this task is complete, the user is either granted a specific set of access rights to the object or denied access to the object (if a deny ACE is located). The granted rights may be the same as the rights initially requested or they may be a subset of the rights initially requested. For example, the CreateFile call can request read and write access to a file, but the DACL may allow only read access.

Impersonation

When a thread within a process attempts to access a secured object, the security context that represents the user making the access attempt is normally obtained from the process-level access token.

However, you can associate a temporary access token with a specific thread. For example, within a server process, you can impersonate the security context of a client. The act of impersonation associates a temporary access token with the current thread. The temporary impersonation access token represents the security context of the client. As a result, the server thread uses the security context of the client when it attempts to access any secured object. When the temporary access token is removed from the thread, impersonation ceases and subsequent resource access reverts to using the process-level access token.

Active Directory

Windows Server 2003 introduced the Active Directory directory service, which is used to store information about objects. The objects can include users, computers, printers, and every domain on one or more wide area networks (WANs). Active Directory can scale from a single computer to many large computer networks. Active Directory provides the store for all domain security policy and account information. It replaces the flat account namespace in earlier versions of Windows with a hierarchical namespace for user, group, and computer account information.

Windows Server 2003 includes new authentication protocols based on Internet standards, including Kerberos 5 and Transport Layer Security (TLS). For backward compatibility, Windows Server 2003 supports existing Windows NT LAN Manager Challenge/Response (NTLM) authentication protocols.

The Windows implementation of secure channel security protocols, such as Secure Sockets Layer (SSL) 3.0/TLS, supports strong client authentication by mapping user credentials in the form of public-key certificates to existing Windows NT accounts. Administrators use common administration tools to manage account information and access control, whether the administrators are using password authentication or certificates. External users who do not have Windows Server 2003 accounts can be authenticated through public-key certificates and mapped to an existing Windows account. This allows businesses to give trading partners limited or full access to their internal networks.

Handles

The major differences in implementing system handles in UNIX versus Windows are described in the following sections.

Socket Handles

In UNIX, socket handles are small, non-negative integers. Socket handles can be passed to most of the low-level Portable Operating System Interface (POSIX) input/output (I/O) functions. Windows defines a new unsigned data type SOCKET that may take any value in the range 0 to INVALID_SOCKET–1, where INVALID_SOCKET is a predefined value for a nonexistent socket. Because the SOCKET type is unsigned, compiling existing source code from a UNIX environment may lead to compiler warnings about signed/unsigned data type mismatches.

File Handles

In UNIX, a file handle is an opaque number that is used to uniquely identify a file or other file system object. The only operations that can be carried out with the file handle in UNIX are to copy and compare it for equality with another file handle.

In Windows, the file handle is used to identify a file. When a file is opened by a process using the CreateFile function, a file handle is associated with it until either the process terminates or the handle is closed by using the CloseHandle function.

Signals, Exceptions, and Events

UNIX and Windows have mechanisms by which processes can indicate an event or error. In both operating systems, these events are signaled by a form of software interrupts. In UNIX, these mechanisms are called signals and are used for ordinary events, such as simple interprocess communication (IPC), and abnormal conditions, such as floating point exceptions. Windows has the following two separate mechanisms:

  • An events mechanism handles expected events, such as communication between two processes.

  • An exception mechanism handles nonstandard events, such as the termination of a process by the user. Computer hardware may generate exceptions such as invalid memory access and math errors. Windows uses a facility named Structured Exception Handling (SEH) to handle these exceptions.

Interprocess Communication

An operating system designed for multitasking or multiprocessing must provide mechanisms for communicating and sharing data between applications. Such a mechanism is called interprocess communication (IPC). Some forms of IPC are designed for communication among processes running on the same computer, whereas other forms are for communicating across the network between different computers.

UNIX Interprocess Communication

UNIX has several IPC mechanisms that possess different characteristics and are appropriate for different situations. Shared memory, pipes, and message queues are all suitable for processes running on a single computer. Shared memory and message queues are suitable for communicating among unrelated processes. Pipes are the mechanism usually chosen for communicating with a child process through standard input and output. For more information about message queues, refer to the “Message Queues”* *section later in this chapter.

For communication across the network, sockets are usually the chosen technique. Migration from UNIX sockets to Windows sockets is usually a straightforward process involving few changes to the code.

Windows Interprocess Communication

Windows has many IPC mechanisms, some of which have no counterpart in UNIX. As with UNIX, Windows has shared memory, pipes, and events (equivalent to signals). These are appropriate for processes local to a computer. The shared memory implementation is based on file mapping because certain forms of shared memory can be used across the network. Named pipes can also be used for network communications. Other IPC mechanisms supported by Windows are the Clipboard/Dynamic Data Exchange (DDE), Component Object Model (COM), Distributed Component Object Model (DCOM), and send message. These are mostly used for local communications, but DDE and COM both have network capabilities. Winsock and Message Queuing (also known as MSMQ) are good choices for cross-network tasks.

Windows provides two additional IPC mechanisms: remote procedure call (RPC) and mailslots. RPC is designed for use by client/server applications and is most appropriate for C and C++ programs. Mailslots are memory-based files that a program can access using standard file functions. The maximum size of mailslots is fairly small and their usage is often similar to named pipes except that mailslots are effective for broadcasting small messages.

Synchronization

Both UNIX and Windows have an extensive set of process and thread synchronization techniques. Both operating systems use semaphores, which are synchronization primitives used to control access to a resource that can support a limited number of users. Both UNIX and Windows also use mutex objects to control mutually exclusive access to a resource.

Windows offers critical section objects for lightweight control of multithread access to a section of code. Critical sections are similar to mutexes, but access is limited to the threads of a single process. This makes them appropriate for controlling access to a shared resource. Threads can access the critical section in any order, but the order is not guaranteed.

Message Queues

In UNIX, a message queue is an IPC mechanism. One application sends messages to the queue and another application reads the messages from the queue. The queues are very fast because they are memory based. However, the messages disappear if the system fails. Message queues were introduced in AT&T System V UNIX. Because of this, many versions of UNIX that are based on BSD may not have them. POSIX has message queues, but the API is not exactly the same as in System V.

In recent years, dedicated products have emerged with a more robust and persistent message queue paradigm available on many different platforms. Windows provides a reliable messaging system called Message Queuing. Message Queuing provides guaranteed message delivery, efficient routing, security, and priority-based messaging. In essence, a Message Queuing message is guaranteed to be delivered, but there is no specific guarantee about exactly when it will be received. The operation is the same as on UNIX: One application writes to the queue and another reads from it. The API, however, is completely different.

Shared Memory

As mentioned previously, both Windows and UNIX provide shared memory as one of the IPC mechanisms. In both, the mechanisms provide a section of memory that can be shared between processes to pass data and control information. However, the implementation details are different.

In one of the UNIX implementations, the program must first call a function to get a shared memory identifier, shm_id, for the amount of shared memory. The identifier is then used in calls to attach the shared memory to the process. There are other functions for controlling and removing the shared memory. This type of shared memory mechanism was introduced in the AT&T System v2 version of UNIX. Later UNIX versions introduced shared memory based on the concept of file mapping. The mmap function sets up a segment of memory that can be read or written to by two or more programs. This mechanism is used to manipulate files.

The mmap function creates a pointer to a region of memory associated with the contents of the file that is accessed through an open file descriptor.

In Windows, implementation of shared memory can be done using the concept of file mapping or by sharing memory using the GlobalAlloc function. In the file mapping implementation, a common section of memory can be mapped into the address space of multiple processes. If no file is specified in the creation function, the shared memory is allocated from a section of the page file. As in the UNIX implementation, which uses an identifier, Windows uses a handle identifier to identify the memory that is mapped into the process at the requested address. The GlobalAlloc function allocates the specified number of bytes from the heap, which can be shared among processes.

Both the UNIX and Windows file mapping solutions offer the capability of saving the contents in a permanent file.

Pipes

Pipes have similar functionality in both Windows and UNIX systems. Their primary use is to communicate between related processes. UNIX pipes can be named or unnamed. They also have separate read and write file descriptors, which are created through a single function call. With unnamed pipes, a parent process that must communicate with a child process creates a pipe that the child process will inherit and use. Two unrelated processes can use named pipes to communicate with each other.

Windows pipes can also be named or unnamed. A parent process and a child process typically use unnamed pipes to communicate. The processes must create two unnamed pipes for bidirectional communication. Two unrelated processes can use named pipes, even across the network on different computers. Typically, a server process creates the pipe, and clients connect to the bidirectional pipe to communicate with the server process.

Networking

The primary networking protocol for both UNIX and Windows is Transmission Control Protocol/Internet Protocol (TCP/IP). The standard programming API for TCP/IP is called sockets. Sockets were created for UNIX at the University of California, Berkeley. Sockets provide an easy-to-use, bidirectional stream between systems across a network. The Windows implementation of sockets is formally known as Windows Sockets but is usually called Winsock. Winsock conforms well to the Berkeley implementation, even at the API level. Most of the functions are the same, but slight differences in parameter lists and return values do exist. It is interesting to note that Winsock allows new transport providers to be installed, making Winsock an extensible environment.

User Interface Differences

The UNIX user interface was originally based on a character-oriented command line, whereas the Windows user interface was originally based on a GUI. This difference is due to the background of the two operating systems. UNIX originated at a time when graphic terminals were not available. Windows was (as the name suggests) designed to take advantage of advances in the graphics capabilities of computers. However, both UNIX and Windows now support a mixture of character and graphical interfaces.

The UNIX Character-based Interface

The standard UNIX shells and tools are all character-based and command-line oriented. For the UNIX shells and UNIX applications to be capable of communicating with different models of character terminals, they must be aware of the different functions available and the command sets for each terminal.

Termcap and Terminfo

To minimize the amount of specific terminal information embedded in a program, UNIX has databases of terminal capabilities. These databases are known as termcap and terminfo. Instead of embedding terminal commands into an application, developers can use program libraries provided with the operating system to query the database for specific movement commands, thus allowing their applications to operate with a variety of hardware.

Curses

Another application development package specifically designed to alleviate the problem of terminal dependence is the curses library originally written at the University of California, Berkeley. Curses is a set of functions used to manipulate terminal input and output (mostly output). These perform actions, such as clearing the screen, moving the cursor to a specific row and column, and writing a character or string to the screen. The library also includes input functions to retrieve user input in various modes, such as read one character and read a string terminated by carriage return.

Curses and similar libraries enable developers to create highly interactive, character-based applications, such as text editors.

X Windows and Motif

The standard windowing system for UNIX systems is the X Window System (or X Windows), developed at the Massachusetts Institute of Technology (MIT). X Windows is a platform-independent, basic windowing system. It consists of a lower-level API called X library (or Xlib) and a higher-level library called X Toolkit Intrinsics. X Windows separates the server (which manages the display of graphical information) from the client (which is the application program that uses X Windows). The server and client can run on separate computers, so the application may run on a powerful numeric server while the output appears on a graphics workstation. This feature has also led to the development of X terminals, that is, computers equipped only to display graphics on a computer screen.

Because X Windows is a set of toolkits and libraries, it does not have graphical user interface standards as Windows does. Motif is the most common windowing system, library, and user interface style built on X Windows. Motif handles Windows and a set of user interface controls known as widgets. Widgets cover the whole range of user interface controls, including buttons, scroll bars, menus, and high-functionality items such as a Web browser widget.

X Windows has the capability to support multiple terminals, that is, multiple client sessions can connect to the same X Windows server simultaneously and interact with the server. Windows also has a similar capability known as Windows Terminal Services. This functionality enables users to run multiple interactive sessions on the server at the same time.

Windows Terminal Server and Citrix

Windows can provide sessions that run applications on a server but are displayed on a client workstation. These sessions can be implemented with both Terminal Server (on Windows Server 2003 and Windows XP) and Citrix.

Both Terminal Server and Citrix use a server-based session, much as UNIX does. The difference is that Terminal Server and Citrix use a smart GUI terminal specific to running Windows-based programs. This is analogous to the way an X terminal operates in a UNIX environment. System managers can use Terminal Server to deliver Windows functionality to a low-end computer or even one that does not run Windows. Terminal Server can also be used to remotely administer a Windows-based server.

Terminal Server is particularly useful for implementing server-based applications in a thin client environment. Additionally, Terminal Server provides a smart GUI protocol that works effectively on slow links. This protocol allows enterprises to consolidate applications in a remote location, without the loss of performance usually associated with slower remote networks.

System managers can implement Terminal Server using network load balancing in scale-out server clusters. This configuration allows for both higher availability and the capability to add more servers when the load increases. Applications that use Terminal Server or Citrix usually fall into the following two categories:

  • Desktop applications, such as those in the Microsoft Office suite, moved from the desktop client to a central server.

  • Remote applications that require thin client connectivity and that are unable to operate through a Web-based interface.

Download

Get the UNIX Custom Application Migration Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions