UNIX OR Windows ......... the debate is on..............

Organizations today are constantly focusing on improving the availability, manageability, performance, and serviceability of their services and products, while at the same time reducing the cost and complexity involved in providing them. As the IT decision maker, these requirements create a difficult situation for you. You can either choose to make no changes and risk your systems becoming obsolete, or you can make a change and risk joining a computing trend that turns out to be an evolutionary dead end.
Mainframe computers have been used by the industry for a long time. They often use any one of the various versions of UNIX provided by vendors. The various implementations of the UNIX operating system have served the industry well, as witnessed by the large base of installed systems and the number of large-scale applications installed on these systems. However, there are increasing signs of dissatisfaction with expensive, often proprietary solutions running on UNIX architecture. In many cases, the user experience of these systems involves text-based interaction with dumb terminals or a terminal-emulation session on a computer. Dissatisfied with these characteristics of UNIX, IT managers have often sought alternatives to the increasing expense of being tied to single-vendor software and hardware solutions. In addition, since the mid-1980s, corporate data centers have been moving away from mainframes, with their dedicated operating systems, to minicomputers.
This has prompted more organizations to evaluate migrating to Intel-based architecture as an option. One of the most extraordinary and unexpected successes of the Intel PC architecture is the flexibility to extend its framework to include very large server and data center environments. Large-scale hosting organizations are now offering enterprise-level services to multiple client organizations at an availability level of more than 99.99 percent on what are just racks of relatively inexpensive computers.
These catalysts have led more organizations to migrate their enterprise-level applications from UNIX to Windows. The key benefits (for example, reduction of costs and increased flexibility) of the Microsoft® Windows® operating system has fueled this interest, increasing the number of organizations that are considering migrating to alternative platforms.
Migration, or coexistence, with the Microsoft Windows operating system makes sense because it offers greater enterprise-readiness and a better-integrated future roadmap for application development and server support, along with quantifiable reductions in total cost of ownership (TCO).
Before you migrate from UNIX to Windows, it is recommended that you learn about the evolution and architecture of the two operating systems. The following section provides this information.

Evolution and Architecture

This section provides an overview of the development and production environments in both Windows and UNIX. Before you begin to plan your UNIX-to-Windows migration, however, it is important that you understand the Windows and UNIX operating systems, their terminologies, and the key differences between them.

Windows

This section outlines the evolution of the Windows family of operating systems. The section also discusses the architecture of Microsoft Windows Server™ 2003 and its salient features.

Evolution of the Windows Operating System

In the late 1980s, Microsoft began designing a new operating system that could take advantage of the advancements in processor design and software development. The new operating system was called Windows NT® (for new technology). (The Windows Server 2003 and Windows XP operating systems are based on Windows NT.)

Windows Server 2003 Architecture

Windows Server 2003 architecture uses two processor access modes: the user mode and the kernel mode.
The user mode includes application processes, which are typically Windows programs and a set of protected subsystems. These subsystems are referred to as "protected" because each of these subsystems is a separate process with its own protected virtual address space. Of these, the most important subsystem is the Microsoft Win32® subsystem, which supplies much of the Windows functionality. The Windows application programming interface (API) is useful for developing both 32-bit and 64-bit Windows-based applications.
Another important subsystem, particularly with respect to migration of UNIX applications, is the Portable Operating System Interface (POSIX) for computing environments. This is a set of international standards for implementing UNIX-like interfaces. The POSIX subsystem implements these standards-based interfaces and allows application developers to easily port their applications to Windows from another operating system. The POSIX subsystem is not implemented on Windows Server 2003 but comes as a part of the Interix (Windows Services for UNIX 3.5) installation on Windows.
The kernel mode is a highly privileged mode of operation in which the program code has direct access to the virtual memory. This includes the address spaces of all user mode processes and applications and their hardware. The kernel mode is also known as the supervisor mode, protected mode, or Ring 0. The kernel mode of Windows Server 2003 contains the Windows NT executive as well as the system kernel. The Windows NT executive exports generic services that protected subsystems call to obtain basic operating system services, such as file operations, input/output (I/O), and synchronization services. Partitioning of the protected subsystems and the system kernel simplifies the base operating system design and makes it possible to extend the features of an individual protected subsystem without affecting the kernel. The kernel controls how the operating system uses the processors. Its operations include scheduling, multiprocessor synchronization, and providing objects that the executive can use or export to applications.
The Windows operating system supports the following features and capabilities:

Figure 1.2 shows a high-level illustration of the Windows Server 2003 architecture.

• multitasking
• Flexibility to choose a programming interface (user and kernel APIs).
  
• A graphical user interface (GUI) and a command-line interface for users and administrators. (The default UI is graphical.)
  
• Built-in networking. (Transmission Control Protocol/Internet Protocol [TCP/IP] is standard.)
  
• Persistent system service processes called "Windows Services" and managed by the Windows Service Control Manager (SCM).
  
• Single compatible implementation irrespective of the vendor from whom it is purchased.
  
  

  UNIX

  This section outlines the evolution of the UNIX operating system. The architecture of UNIX and its salient features are also discussed.
  

  Evolution of the UNIX Operating System

  In 1969, Bell Laboratories developed UNIX as a "timesharing" system, a term used to describe a multitasking operating system that supports multiple users at each terminal. Although the first implementation was written in assembly language, the designers always intended to write UNIX in a higher-level language. Therefore, Bell Labs invented the C language so that they could rewrite UNIX. UNIX has evolved into a popular operating system that runs on computers ranging in size from personal computers to mainframes.
  
  
  Figure 1.3 depicts the evolution of UNIX from a single code base into the wide variety of UNIX systems available today. In fact, this is only a summary—there are more than 50 flavors of UNIX in use today. The codes in the diagram refer to the brands and versions of UNIX that are in common use, including:
  
• AIX from IBM.
  
• Solaris from SUN Microsystems.
  
• HP-UX and Tru64 from Hewlett Packard.
  
• UnixWare from Caldera.
  
• FreeBSD, which is an open source product
  

  UNIX Architecture

  The architecture of UNIX can be divided into three levels of functionality, as shown in Figure 1.4.
  
• The lowest level is the kernel, which schedules tasks, manages resources, and controls security.
  
• The next level is the shell, which acts as the UI, interpreting user commands and starting applications.
  Note   For more information about the shell, refer to Chapter 2, "Developing Phase: Process Milestones and Technology Considerations" of Volume 3: Migrate Using Win32/Win64 of this guide.
  
• The tools are at the highest level. These provide utility functions such as ls, vi, and cat.
  
  
  Figure 1.4. UNIX architecture
  The UNIX operating system supports the following features and capabilities:
  
• Multitasking and multiuser.
  
• Kernel written in high-level language.
  
• Programming interface.
  
• Use of files as abstractions of devices and other objects.
  
• Character-based default UI.
  
• Built-in networking. (TCP/IP is standard.)
  
• Persistent system service processes called "daemons" and managed by init or inetd.
  

Comparison of Windows and UNIX Environments

This section compares the Windows and UNIX architectures, emphasizing the areas that directly affect software development in a migration project.

Kernels and APIs

As with most operating systems, Windows and UNIX both have kernels. The kernel provides the base functionality of the operating system. The major functionality of the kernel includes process management, memory management, thread management, scheduling, I/O management, and power management.
In UNIX, the API functions are called system calls. System calls are a programming interface common to all implementations of UNIX. The kernel is a set of functions that are used by processes through system calls.
Windows has an API for programming calls to the executive. In addition to this, each subsystem provides a higher-level API. This approach allows Windows operating systems to provide different APIs, some of which mimic the APIs provided by the kernels of other operating systems. The standard subsystem APIs include the Windows API (the Windows native API) and the POSIX API (the standards-based UNIX API).

Windows Subsystems

A subsystem is a portion of the Windows operating system that provides a service to application programs through a callable API.
Subsystems come in two varieties, depending upon the application program that finally handles the request:

• Environment subsystems. These subsystems run in a user mode and provide functions through a published API. The Windows API subsystem provides an API for operating system services, GUI capabilities, and functions to control all user input and output. The Win32 subsystem and POSIX subsystem are part of the environment subsystems and are described as follows:
  
  • Win32 subsystem. The Win32 environment subsystem allows applications to benefit from the complete power of the Windows family of operating systems. The Win32 subsystem has a vast collection of functions, including those required for advanced operating systems, such as security, synchronization, virtual memory management, and threads. You can use Windows APIs to write 32-bit and 64-bit applications that run on all versions of Windows.
    
  • POSIX subsystem and Windows Services for UNIX. To provide more comprehensive support for UNIX programs, Windows uses the Interix subsystem. Interix is a multiuser UNIX environment for a Windows-based computer. Interix conforms to the POSIX.1 and POSIX.2 standards. It provides all features of a traditional UNIX operating system, including pipes, hard links, symbolic links, UNIX networking, and UNIX graphical support through the X Windows system. It also includes case-sensitive file names, job control tools, compilation tools, and more than 300 UNIX commands and tools, such as KornShell, C Shell, awk, and vi.
    Because it is layered on top of the Windows kernel, the Interix subsystem is not an emulation. Instead, it is a native environment subsystem that integrates with the Windows kernel, just as the Win32 subsystem does. Shell scripts and other scripted applications that use UNIX and POSIX.2 tools run under Interix.
    
• Integral subsystems. These subsystems perform key operating system functions and run as a part of the executive or kernel. Examples are the user-mode subsystems, Local Security Authority subsystem (LSASS), and Remote Procedure Call subsystem (RPCSS).
  

Kernel Objects and Handles

Kernel objects are used to manage and manipulate resources—such as files, synchronization objects, and pipes—across the processes. These kernel objects are owned by the kernel and not by the process. Handles are the opaque numbers or the data type used to represent the objects and to uniquely identify the objects. To interact with an object, you must obtain a handle to the object.
In UNIX, the kernel object can be created using the system calls and it returns an unsigned integer. There is no exact equivalent of handles in UNIX.
In Windows, Windows APIs are used to create the kernel object and it returns a Windows-specific data type called HANDLE.

Hardware Drivers

Hardware drivers are system software used to interact the hardware devices with the operating system.
In UNIX, there are several different ways to manage drivers. Some UNIX implementations allow dynamic loading and unloading of drivers, whereas other implementations do not. The UNIX vendor usually provides drivers. The range of Intel hardware supported for UNIX is typically smaller than that for Windows.
In Windows, the Windows driver model provides a platform for developing drivers for industry-standard hardware devices attached to a Windows-based system. The key to developing a good driver package is to provide reliable setup and installation procedures and interactive GUI tools for configuring devices after the installation. In addition, the hardware must be compatible with Windows Plug and Play technology in order to provide a user-friendly hardware installation.

Process Management

A process is usually defined as the instance of the running program. Process management describes how the operating systems manage the multiple processes running at a particular instance of time. Multitasking operating systems such as Windows and UNIX must manage and control many processes simultaneously. Both Windows and UNIX operating systems support processes and threads.
The following sections provide more details on process management in both UNIX and Windows:

• Multitasking. UNIX is a multiprocessing, multiuser system. At any given point, you can have many processes running on UNIX. Consequently, UNIX is very efficient at creating processes.
  Windows has evolved greatly from its predecessors, such as Digital Equipment Corporation’s VAX/VMS. It is now a preemptive multitasking operating system. As a result, Windows relies more heavily on threads than processes. (A thread is a construct that enables parallel processing within a single process.) Creating a new process is a relatively expensive operation while creating a new thread is not as expensive in terms of system resources like memory and time. Hence, multiprocess-oriented applications on UNIX typically translate to multithreaded applications on the Windows platform, thus saving such system resources as memory and time.
  
• Multiple users. One key difference between UNIX and Windows is in the creation of multiple user accounts on a single computer.
  When you log on to a computer running UNIX, a shell process is started to service your commands. The UNIX operating system keeps track of the users and their processes and prevents processes from interfering with one another. The operating system does not come with any default interface for user interaction. However, the shell process on the computer running UNIX can connect to other computers to load third-party UIs.
  When a user logs on interactively to a computer running Windows, the Win32 subsystem’s Graphical Identification and Authentication dynamic-link library (GINA) creates the initial process for that user, which is known as the user desktop, where all user interaction or activity takes place. The desktop on the user's computer is loaded from the server. Only the user who is logged on has access to the desktop. Other users are not allowed to log on to that computer at the same time. However, if a user employs Terminal Services or Citrix, Windows can operate in a server-centric mode just as UNIX does.
  The Windows operating system supports multiple users simultaneously through the command line and a GUI. The latter requires the use of Windows Terminal Services. The UNIX operating system supports multiple simultaneous users through the command line and through a GUI. The latter requires the use of X Windows. Windows comes with a default command shell (cmd.exe); UNIX typically includes several shells and encourages each user to choose a shell as the user’s default shell. Both operating systems provide complete isolation between simultaneous users. There are some key differences between the two: Windows comes with a “single user” version that allows one user at a time (Windows XP) as well as a multiuser server version (Windows Server). It is rare for a Windows Server system to have multiple simultaneous command-line users.
  
• Multithreading. Most new UNIX kernels are multithreaded to take advantage of symmetric multiprocessing (SMP) computers. Initially, UNIX did not expose threads to programmers. However, POSIX has user-programmable threads. There is a POSIX standard for threads (called Pthreads) that all current versions of UNIX support.
  In Windows, creating a new thread is very efficient. Windows applications are capable of using threads to take advantage of SMP computers and to maintain interactive capabilities when some threads take a long time to execute.
  
• Process hierarchy. When a UNIX-based application creates a new process, the new process becomes a child of the process that created it. This process hierarchy is often 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 ID of the process it created, so a hierarchical relationship can be maintained or simulated if required by the application. However, the operating system treats all processes like they belong to the same generation. Windows provides a feature called Job Objects, which allows disparate processes to be grouped together and adhere to one set of rules.
  

Signals, Exceptions, and Events

In both operating systems, events are signaled by software interrupts. A signal is a notification mechanism used to notify a process that some event has taken place or to handle the interrupt information from the operating system. An event is used to communicate between the processes. Exceptions occur when a program executes abnormally because of conditions outside the program's control.
In UNIX, signals are used for typical events, simple interprocess communication (IPC), and abnormal conditions such as floating point exceptions.
Windows has the following mechanisms:

• Windows supports some UNIX signals and others can be implemented using Windows API and messages.
  
• An event mechanism that handles expected events, such as communication between two processes.
  
• An exception mechanism that handles nonstandard events, such as the termination of a process by the user, page faults, and other execution violations.
  

Daemons and Services

A daemon is a process that detaches itself from the terminal and runs disconnected in the background, waiting for requests and responding to them. A service is a special type of application that is available on Windows and runs in the background with special privileges.
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. To modify such a script, it needs to be opened in a text editor and the values of the variables in the script need to be physically changed. On UNIX, a daemon runs with an appropriate user name for the service that it provides or as a root user.
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 UI. Services may start when the system restarts and then continue running across logon sessions. Windows has a registry that stores the values of the variables used in the services. Control Panel provides a UI that allows users to set the variables with the valid values in the registry. The security context of that user determines the capabilities of the service. Most services run as either Local Service or Network Service. The latter is required if the service needs to access network resources and must run as a domain user with enough privileges to perform the required tasks.

Virtual Memory Management

Virtual memory is a method of extending the available physical memory or RAM on a computer. In a virtual memory system, the operating system creates a pagefile, or swapfile, and divides memory into units called pages. Virtual memory management implements virtual addresses and each application is capable of referencing a physical chunk of memory, at a specific virtual address, throughout the life of the application.
Both UNIX and Windows use virtual memory to extend the memory available to an application beyond the actual physical memory installed on the computer. For both operating systems, on 32-bit architecture, each process gets a private 2 GB of virtual address space. This is called user address space or process address space. The operating system uses 2 GB of virtual address space, called system address space or operating system memory. On 64-bit architecture, each process gets 8 terabytes of user address space.

File Systems and Networked File Systems

This section describes the file system characteristics of UNIX and Windows. Both UNIX and Windows support many different types of file system implementations. Some UNIX implementations support Windows file system types, and there are products that provide Windows support for some UNIX file system types.
File system characteristics and interoperability of file names between UNIX and Windows are discussed as follows:

• 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 the following:
  
  • In UNIX: /
    
  • In Windows: ?, ", /, \, >, <, *, |, and :
    
  UNIX file names are case sensitive while Windows file names are not.
  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. UNIX makes no distinction between files on a local hard drive partition, CD-ROM, floppy disk, or network file system (NFS). All files appear in one tree under the same root.
  The Windows file system can have many hierarchies, for example, one for each partition and one for each network drive. A UNIX system provides a single file system tree, with a single root, to the applications it hosts. Mounted volumes (whether local devices or network shares) are "spliced" into that tree at locations determined by the system administrator. The Windows operating system exposes a forest of file system trees, each with its own root, to the applications it hosts. Mounted volumes appear as separate trees ("drive letters") as determined by the administrator or user. Both UNIX and Windows provide a tree view of all network-accessible shares. UNIX provides an administrator-defined view of these shares through an automounter mechanism, while Windows provides a full view through the Universal Naming Convention (UNC) pathname syntax.
  
• Server message block (SMB) and Common Internet File System (CIFS). One of the earliest implementations of network resource sharing for the Microsoft MS-DOS® platform was network basic input/output system (NetBIOS). The features of NetBIOS allow 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). Later, additions were made to SMB to apply it to the Internet, and the protocol is now known as Common Internet File System (CIFS).
  UNIX supports this through a software option called Samba. Samba is an open-source, freeware, server-side implementation of a UNIX CIFS server.
  In Windows, the server shares a directory, and the client then connects to the Universal Naming Convention (UNC) to connect to the shared directory. Each network drive usually appears with its own drive letter, such as X.
  
• Windows and UNIX NFS interoperability. UNIX and Windows can interoperate using NFS on Windows or CIFS on UNIX. There are a number of commercial NFS products for Windows. For UNIX systems, Samba is an alternative to installing NFS client software on Windows-based computers for interoperability with UNIX-based computers. It also implements NetBIOS-style name resolution and browsing. Microsoft offers a freely downloadable NFS Server, Client, and Gateway as part of Windows Services for UNIX 3.5 installation. Windows Services for UNIX also provide a number of services for interoperability between Windows-based and UNIX-based computers.
  

Security

This section describes some of the security implementation details and differences between UNIX and Windows:

• User authentication. A user can log on to a computer running UNIX by entering a valid user name and password. A UNIX user can be local to the computer or known on 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. A Windows user can be local to the computer, can be known on a Windows domain, or be known in the Microsoft Active Directory® directory service. The Windows domain contains only a user name, the associated password, and some user groups. Active Directory contains the same information as the Windows domain and may contain the contact information of the user, organizational data, and certificates.
  
• UNIX versus Windows 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. When a user logs on to the system with a user name and a password, UNIX starts a shell with the UID and GID of that user. From then on, the permissions assigned to the UID and GID, or the process, control all access to files and other resources. Most UNIX vendors can provide Kerberos support, which raises their sophistication to about that of Windows.
  Windows uses a unified security model that protects all objects from unauthorized access. The system maintains security information for:
  
  • Users. System users are 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. Each user’s security context is represented by a logon session.
    
  • Objects. These are the secured resources (for example, files, computers, synchronization objects, and applications) that a user can access.
    
• Active Directory. Windows Server 2003 uses the Active Directory directory service to store information about objects. These objects 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. It provides a store for all the domain security policy and account information.
  

Networking

Networking basically provides the communication between two or more computers. It defines various sets of protocols, configures the domains, IP addresses, and ports, and communicates with the external devices like telephones or modems and data transfer methods. It also provides the standard set of API calls to allow applications to access the networking features.
The primary networking protocol for UNIX and Windows is TCP/IP. The standard programming API for TCP/IP is called sockets. The Windows implementation of sockets is known as Winsock (formally known as Windows Sockets). Winsock conforms well to the Berkeley implementation, even at the API level. The key difference between UNIX sockets and Winsock exists in asynchronous network event notification. There is also a difference in the remote procedure calls (RPC) implementation in UNIX and Windows.

User Interfaces

The user interface (UI) provides a flexible way of communicating between the users, applications, and the computer.
The UNIX UI was originally based on a character-oriented command line, whereas the Windows UI was based on GUI. UNIX originated when graphic terminals were not available. However, the current versions of UNIX support the graphical user interface using the X Windows system. Motif is the most common windowing system, library, and user-interface style built on X Windows. This allows the building of graphical user interface applications on UNIX.
The Windows user interface was designed to take advantage of advancements in the graphics capabilities of computers. It can be used by all applications—including both client side and server side—and can also be used for tasks such as service administration. Windows contains the Graphics Device Interface (GDI) engine to support the graphical user interface.

System Configuration

UNIX users generally configure a system by editing the configuration files with any of the available text editors. The advantage of this mechanism is that the user does not need to learn how to use a large set of configuration tools, but must only be familiar with an editor and possibly a scripting language. The disadvantage is that the information in the files comes in various formats; hence the user must learn the various formats in order to change the settings. UNIX users often employ scripts to reduce the possibility of repetition and error. In addition, they can also use NIS to centralize the management of many standard configuration files. Although different versions of UNIX have GUI management tools, such tools are usually specific to each version of UNIX.
Windows has GUI tools for configuring the system. The advantage of these tools is that they can offer capabilities depending on what is being configured. In recent years, Microsoft Management Console (MMC) has provided a common tool and UI for creating configuration tools. Windows provides a scripting interface for most configuration needs through the Windows Script Host (WSH). Windows provides WMI (Windows Management Instrumentation), which can be used from scripts. Windows also includes extensive command-line tools for controlling system configuration. In Windows Server 2003, anything that can be done to manage a system through a GUI can be done through a command-line tool as well.

Interprocess Communication

An operating system designed for multitasking or multiprocessing must provide mechanisms for communicating and sharing data between applications. These mechanisms are called interprocess communication (IPC).
UNIX has several IPC mechanisms that have different characteristics and which 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 usually chosen for communicating with a child process through standard input and output. For communications across the network, sockets are usually the chosen technique.
Windows also has many IPC mechanisms. Like UNIX, Windows has shared memory, pipes, and events (equivalent to signals). These are appropriate for processes that are local to a computer. In addition to these mechanisms, Windows supports clipboard/Dynamic Data Exchange (DDE), and Component Object Model (COM). Winsock and Microsoft Message Queuing are good choices for cross-network tasks. Other cross-network IPC mechanisms for Windows include remote procedure calls (RPCs) and mail slots. RPC has several specifications and implementations, developed by third-party vendors, which support client server applications in distributed environments. The most prevalent RPC specifications are Open Network Computing (ONC) by Sun Microsystems and Distributed Computing Environment (DCE) by Open Software Foundation. UNIX systems support interoperability with Windows RPC. UNIX does not implement mailslots.

Synchronization

In a multithreaded environment, threads may need to share data between them and perform various actions. These operations require a mechanism to synchronize the activity of the threads. These synchronization techniques are used to avoid race conditions and to wait for signals when resources are available.
UNIX environments use several techniques in the Pthreads implementation to achieve synchronization. They are:

• Mutexes
  
• Condition variables
  
• Semaphores
  
• Interlocked exchange
  

Similarly, the synchronization techniques available in the Windows environment are:

• Spinlocks
  
• Events
  
• Critical sections
  
• Semaphores
  
• Mutexes
  
• Interlocked exchange
  

DLLs and Shared Libraries

Windows and UNIX both have a facility that allows the application developer to put common functionality in a separate code module. This feature is called a shared library in UNIX and a dynamic-link library (DLL) in Windows. Both allow application developers to link together object files from different compilations and to specify which symbols will be exported from the library for use by external programs. The result is the capability to reuse code across applications. The Windows operating system and most Windows programs use many DLLs.
Windows DLLs do not need to be compiled to position-independent code (PIC), while UNIX shared objects must be compiled to PIC. However, the exact UNIX behavior can be emulated in Windows by pre-mapping different DLLs at different fixed addresses.

Component-based Development

Component-based development is an extension to the conventional software development where the software is assembled by integrating several components. The components themselves may be written in different technologies and languages, but each has a unique identity, and each of them exposes common interfaces so that they can interact with other components.
UNIX supports CORBA as the main component-based development tool. However, it is not a standard component of the UNIX system; you have to obtain a CORBA implementation from another source.
On the other hand, the Windows environment offers a wide range of component-based development tools and technologies. This includes:

• COM
  
• COM+
  
• Distributed COM (DCOM)
  
• .NET components
  

Middleware

This section compares the various middleware solutions available for UNIX-based and Windows-based applications. Middleware technologies are mostly used to connect the presentation layer with the back-end business layers or data sources. One of the most prominent middleware technologies used in applications is a message queuing system.
Message queuing is provided as a feature in AT&T System V UNIX and can be achieved through sockets in Berkeley UNIX versions. These types of memory queues are most often used for IPC and do not meet the requirements for persistent store and forward messaging.
To meet these requirements, versions of the IBM MQSeries and the BEA Systems MessageQ (formally the DEC MessageQ) are available for UNIX. Microsoft provides similar functionality with Message Queuing for Windows.
IBM and BEA Systems also provide versions of their queuing systems for Windows.

Transaction Processing Monitors

A transaction processing monitor (TP monitor) is a subsystem that groups sets of related database updates and submits them to a database as a transaction. These transactions, often monitored and implemented by the TP monitors, are known as online transaction processing (OLTP). OLTP is a group of programs that allow real-time updating, recording, and retrieval of data to and from a networked system. OLTP systems have been implemented in the UNIX environments for many years. These systems perform such functions as resource management, threading, and distributed transaction management.
Although OLTP was originally developed for UNIX, many OLTP systems have Windows versions. Windows also ships with its own transaction manager. In addition, gateways exist to integrate systems that use different transaction monitors.

Shells and Scripting

A shell is a command-line interpreter that accepts typed commands from a user and executes the resulting request. Every shell has its own set of programming features known as scripting languages. Programs written through the programming features of a shell are called shell scripts. As with shell scripts, scripting languages are interpreted.
Windows and UNIX support a number of shells and scripting languages, some of which are common to both operating systems. Examples are: Rexx, Python, and Tcl/Tk.

Command-Line Shells

A number of standard shells are provided in the UNIX environment as part of the standard installation. They are:

• Bourne shell (sh)
  
• C shell (csh)
  
• Korn shell (ksh)
  
• Bourne Again Shell (bash)  
  

On the Windows platform, Cmd.exe is the command prompt or the shell.
Windows versions of the Korn shell and the C shell are delivered with the Windows Services for UNIX 3.5, MKS, and Cygwin products.

Scripting Languages

In UNIX, there are three main scripting languages that correspond to the three main shells: the Bourne shell, the C shell, and the Korn shell. Although all the scripting languages are developed from a common core, they have certain shell-specific features to make them slightly different from each other. These scripting languages mainly use a group of UNIX commands for execution without the need for prior compilation. Some of the external scripting languages that are also supported on the UNIX environment are Perl, Rexx, and Python.
On the Windows environment, WSH is a language-independent environment for running scripts and is compatible with the standard command shell. It is often used to automate administrative tasks and logon scripts. WSH provides objects and services for scripts, establishes security, and invokes the appropriate script engine, depending on the script language. Objects and services supplied allow the script to perform such tasks as displaying messages on the screen, creating objects, accessing network resources, and modifying environment variables and registry keys. WSH natively supports VBScript and JScript. Other languages that are available for this environment are Perl, Rexx, and Python. WSH is built-in to all current versions of Windows and can be downloaded or upgraded from Microsoft.

Development Environments

The generic UNIX development environment uses a set of command-line tools. In addition, there are many third- party integrated development environments (IDEs) available for UNIX. Most of the character-based and visual IDEs provide the necessary tools, libraries, and headers needed for application development
The Windows development environment can be of two types: a standard Windows development environment or a UNIX-like development environment such as Windows Services for UNIX.
The standard Windows development environment uses the Microsoft Platform Software Development Kit (SDK) and Microsoft Visual Studio® .NET. The platform SDK delivers documentation for developing Windows-based applications, libraries, headers, and definitions needed by language compilers. It also includes a rich set of command-line and stand-alone tools for building, debugging, and testing applications. It is available at no cost from the MSDN Web site.
The Microsoft Visual Studio .NET environment delivers a complete set of tools for application development, including the development of multitier components, user interface design, and database programming and design. It also provides several language tools, editing tools, debugging tools, performance analysis tools, and application installation tools.
The development environment of Windows Services for UNIX contains documentation, tools, API libraries, and headers needed by language compilers. It also comes with a UNIX development environment, with tools such as GNU gcc, g++, g77 compilers, and a gdb debugger, which makes compilation of UNIX applications possible on the Windows environment.

Application Architectures

The following sections introduce and discuss different application architectures and how these applications are implemented on UNIX and Windows platforms.

Distributed Applications

Distributed applications are logically partitioned into multiple tiers: the view or the presentation tier, the business tier, and the data storage and access tier. A simple distributed application model consists of a client that communicates with the middle tier, which consists of the application server and an application containing the business logic. The application, in turn, communicates with a database that stores and supplies the data.
The most commonly used databases in UNIX applications are Oracle and DB2. You can either run the application’s current database (for example, Oracle) on Windows (that is, migrate the existing database from UNIX to Windows) or migrate the database to Microsoft SQL Server™. In some cases, the best migration decision is a conversion to SQL Server.
Another option available is Oracle. It offers a range of features available to both Windows Server 2003 and UNIX. You may choose to use these features with the current Oracle database. By separating the platform migration from the database migration, you have greater flexibility in migrating database applications.
Next is the presentation tier, which provides either a thick or a thin client interface to the application. UNIX applications may use XMotif to provide a thick client interface. In Windows, a thick client can be developed using the Win32 API, GDI+. The .NET Framework provides Windows Forms that help in rapid development of thick clients. Either one of these two methods can be used while migrating the thick client from UNIX to Windows.

Workstation Applications

Workstation-based applications run at the UNIX workstation (desktop) computer and access data that resides on network file shares or database servers. Workstation-based applications have the following architectural characteristics:

• They can be single-process applications or multiple-process applications.
  
• They use character-based or GUI-based (for example, X Windows or OpenGL) UIs.
  
• They access a file server (through NFS) or a database server for data resources.
  
• They access a computer server for computer-intensive services (for example, finite element models for structural analysis).
  

The Windows environment supports a similar workstation application using client/server technology.

Web Applications

Web applications from a UNIX Web server are normally one of the following types:

• Common Gateway Interface (CGI). CGI is a standard for connecting external applications with information servers, such as Hypertext Transfer Protocol (HTTP) or Web servers. CGI has long been out of favor because of performance problems.
  
• Java Server Page (JSP). Java Server Page (JSP) technology also allows for the development of dynamic Web pages. JSP technology uses Extensible Markup Language (XML)-like tags and scriptlets written in the Java programming language to encapsulate the logic that generates the content for the page. The application logic can reside in server-based resources (for example, the JavaBean component architecture) that the page accesses by using these tags and scriptlets. All HTML or XML formatting tags are passed directly back to the response page.
  
• HTML. Hypertext Markup Language is the authoring language used to create documents on the World Wide Web.
  
• PHP. PHP is a widely used, general-purpose scripting language that is especially suited for Web development and can be embedded into HTML.
  
• JavaScript. JavaScript is an extension of HTML. JavaScript is a script language (a system of programming codes) created by Netscape that can be embedded into the HTML of a Web page to add functionality.
  

Web applications on UNIX can be used on Windows with minor configuration changes on the Web server. You can also migrate Java-based Web applications on UNIX to Microsoft Web technologies on Windows.

Graphics-Intensive Applications

Graphics-intensive applications may support additional UI standards, such as OpenGL. OpenGL has become a widely used and supported two-dimensional and three-dimensional graphics API. OpenGL fosters innovation and provides for faster application development by incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. Developers can take advantage of the capabilities of OpenGL across all popular desktop and workstation platforms, ensuring wide application deployment.
OpenGL runs on every major operating system, including Macintosh OS, OS/2, UNIX, Windows Server 2003, Windows XP, Linux, OPENStep, and BeOS. OpenGL also works with every major windowing system, including Win32, Macintosh OS, Presentation Manager, and X-Windows. OpenGL includes a full complement of graphics functions. The OpenGL standard has language bindings for C, C++, Fortran, Ada, and Java; therefore, applications that use OpenGL functions are typically portable across a wide array of platforms.

System-Level Programs or Device Drivers

The existence of an appropriate device driver on the Windows platform is often a gating factor for migrating applications that make use of nonstandard device drivers. Typically, customers do not have access to device-driver source code and are therefore unable to migrate a UNIX device driver to Windows. The topic of migrating device drivers is highly specialized and is not covered in this guide. The Windows Driver Development Kit (DDK) can be used to develop drivers on the Windows environment.