Running Nonnative Applications in Windows 2000 Professional

The OS/2 subsystem is implemented as a protected server; OS/2-based applications communicate with the subsystem by using the LPC message-passing facility. These applications use calls to the DLLs that contain the APIs, the same kind of messages used to communicate with the OS/2 kernel as they use on native OS/2.

The subsystem runs in its own protected address space. Each application also runs in its own protected address space. This protects them from other processes running on Windows 2000.

Memory Management

Figure B.4 shows memory usage on the OS/2 subsystem while an application is running.

Figure B.4 OS/2 Subsystem Memory Map

The tiled area is 512 MB of virtual address space, which is reserved up front, then used when 16-bit applications need segments. The OS/2 subsystem maintains a local descriptor table (LDT) for each process, with shared memory segments at the same LDT slot for all OS/2 processes.

The OS/2 subsystem removes some of the memory management limitations of OS/2 1 .x . The most important of these is the 16-MB limit on physical random access memory (RAM). The high memory capacity of Windows 2000 is available to the OS/2 subsystem, and this capacity translates into increased performance for applications that can use the added memory.

Microsoft SQL Server, for example, can use the added memory. At setup time SQL Server determines the physical memory available in the system and uses that amount of memory to set the level of caching it will use. In Windows 2000, the caching level can be as high as 32 MB or more — double the caching capability allowed in native OS/2.

Protection Model

The OS/2 subsystem provides the same protection between OS/2-based applications that exists in the native OS/2 operating system. The OS/2 subsystem constructs protected address spaces (both the flat address space and LDTs) for the applications.

Paging Mechanism

The OS/2 subsystem uses the Windows 2000 paging mechanism and does not perform segment swapping, which is less efficient. Segment swapping exists in OS/2 only to support the Intel 286 processor, which Windows 2000 does not support.

Object Maintenance

The OS/2 subsystem uses OS/2 semantics to maintain the various OS/2 objects. Examples include process IDs, the process tree, handles, local and global infoseg , thread-1 semantics, exit list processing, signals, and semaphores . The subsystem uses Windows 2000 objects only when they are relevant; when used, they are embedded in OS/2 objects (for example, file handles).

Process Tree

The process tree records the descendant processes of a given process. The OS/2 subsystem uses the process tree in all related operations, such as ending a program when you press CTRL+C.

Threads and Scheduling

Every thread created by an OS/2-based application is implemented with a Windows 2000 thread in the same process. The Windows 2000 thread receives the priority and ID that are relevant in OS/2. The exact OS/2 semantics (such as contents of the register and the stack) are retained when the thread function starts.

The Windows 2000 scheduler handles the scheduling of OS/2 threads. OS/2 priorities 0 through 63 are mapped to Windows 2000 variable priorities 0 through 15. (OS/2 priorities are changed only by the application; they are not changed by the scheduler.) OS/2 threads never receive Windows 2000 real-time priorities 16 through 31.

VIO User Interface

The VIO user interface is partially supported by the OS/2 subsystem. Applications cannot get direct control of the video hardware. For more detail on allowed and disallowed VIO applications, see the lists of APIs in Compatibility of OS/2-based Applications and APIs earlier in this chapter.

Input/Output Processing

The OS/2 subsystem supports all the native device drivers of Windows 2000, such as those for the display, print, disk, communications, keyboard, and mouse devices. It also supports filters. The OS/2 subsystem does not support custom OS/2 device drivers unless the drivers are rewritten, or device monitors unless the monitors are limited to the session. Partial support is also provided for I/O privilege code.

Filters

The OS/2 subsystem supports filters and integrates them with Win32 and MS-DOS; meaning that you can redirect input and output between applications based on OS/2, MS-DOS, and Win32 in an operation that is transparent to the end user.

Custom Device Drivers

Some applications have their own custom OS/2 device drivers (also called private drivers), which are not included in the OS/2 subsystem. Examples are drivers that provide custom support for security, fax, Musical Instrument Digital Interface (MIDI), or IBM 3270 Communication Cards.

To be usable, a custom driver must be rewritten to the Windows 2000 device driver model. However, no change to the application is required because it can still communicate with the driver using the DosDevIOCtl API. The application code can still load and run in a binary-compatible manner because the device-specific parameters passed by the DosDevIOCtl2 API are only pointer-to-void (PVOID) buffers. To be compatible with the original custom driver, the rewritten version must accept the same set of parameters within the PVOID buffers.

Other Dos APIs, such as DosOpen , are compatible with both custom drivers and native Windows 2000 device drivers. This is because the OS/2 subsystem reads its Config.sys file at initialization, finds the internal name of the custom driver, and maps the custom driver to the Windows 2000 driver. You can enter the device driver name in Config.sys by using the devicename command

(devicename = os2devicename [[path][ntdevicename]]).

See Configuring the OS/2 Environment later in this chapter.

Device Monitors

Device monitors, which enable an application to monitor and filter all events on a physical device, are a feature of OS/2 at the device-driver level. If implemented across the Windows 2000 system, a device monitor would violate security. Therefore, the OS/2 subsystem implements device monitors only within an OS/2 session (an OS/2-based application and all of its descendants). Within the session, device monitors are fully compatible with OS/2. The vast majority of OS/2-based applications already use monitors within sessions.

I/O Privilege Mechanism

Some OS/2-based applications and APIs have I/O privilege code segments that let them perform I/O operations in Ring 2 of the Intel protection architecture. However, in Windows 2000, Ring 2 corresponds to user mode, where I/O operations are not allowed. Windows 2000 restricts these operations to kernel mode (Ring 0), which is protected to maintain the systems robustness. Thus IN/OUT instructions using the I/O privilege are disabled because they take control of hardware and thereby threaten robustness. However, CLI/STI instructions, which disable and enable hardware interrupts, will work.

Unlike native OS/2, the OS/2 subsystem does not require an IOPL=YES statement in the Config.sys file to use the I/O privilege. But before using CLI/STI instructions, consider the following: A CLI instruction suspends all other OS/2-based applications and all other threads in the issuing process until an STI instruction follows. Windows 2000 cannot simply disable external interrupts, as native OS/2 does, because this action would compromise the robustness of the operating system. Semaphore calls use far less run-time overhead and are the preferred alternative for implementing critical sections of an application when it is possible to modify the application.

Caution

IN/OUT instructions cause your application to fail. When an IN or OUT instruction is issued, Windows 2000 immediately terminates the application with a general protection fault.

Files Used by the OS/2 Subsystem

Table B.8 lists the main files that make up the OS/2 subsystem.

Table B.8 OS/2 Subsystem Files

Note

The Windows NT Add-on Subsystem for Presentation Manager supplies and uses many other files not listed here, such as all the 16-bit PM DLLs (Pmwin.dll, Pmgre.dll, and so on) and 16-bit executables (Pmshell.exe, Pmspool.exe, and so on).

OS/2 Interprocess Communication

The OS/2 subsystem can communicate with Windows 2000 processes through named pipes, mail slots, NetBIOS, files, and COM devices. The OS/2 subsystem implements all OS/2 interprocess communication mechanisms as shown in Table B.9.

Table B.9 OS/2 Interprocess Communication Mechanisms

Dynamic Linking

The OS/2 subsystem uses a full OS/2 loader, which loads DLLs, executables, and resources the same way as in native OS/2. Static linking, load-time dynamic linking, and run-time dynamic linking all function as they do in native OS/2.

Windows 2000 also has a useful feature, called thunking, which allows 16-bit OS/2-based and PM-based applications to load and call any Win32 DLL. A small set of new APIs is provided for thunking. For more information about thunking, see OS/2 Application Processing later in this chapter.

OS/2 Network Connectivity

The OS/2 subsystem uses many LAN Manager APIs. It also uses NetBIOS (both version 2 .x and version 3.0 functionality), named pipes, and mail slots.

The OS/2 subsystem maintains remote drives the same way native OS/2 does. With these, any OS/2-based application can use redirected drives transparently with the file I/O APIs. Uniform Naming Convention (UNC) naming is supported as well. Redirected drives of various network operating systems can be used if the related Win32 Windows 2000 device drivers (redirectors) have been installed.