DESQview/X Technical Perspective

1 Introduction

This document is intended to provide end users and developers with an understanding of the capabilities and implementation of the DESQview/X product, along with the DESQview DOS multitasker and the X Window System.


X Window System
The X Window System is a hardware-independent and operating system- independent graphics standard designed to operate over a network or within a stand-alone machine. Developed at the Massachusetts Institute of Technology in 1984, it has subsequently become an industry standard employed by companies such as AT&T, DEC, Hewlett-Packard, IBM, Sun Microsystems and others.

X Server
An X Server is a special X Window System graphics application that controls a computer's display screen, drawing windows, text, lines, pictures, circles, polygons and the like according to the requests (messages) from an application. An X Server may handle the screen drawing for multiple applications concurrently - each application typically displaying information with one or more windows on the screen.

X Client
An X Window System application program (such as a spreadsheet or drawing program) that communicates with an X Server is called an X Client. A well-defined messaging system links the two participants. This messaging system may occur over a network or within a single machine.


Specifically, it:

The purpose of this document is to explain how the features of DESQview/X are possible. It provides coverage of the DESQview DOS multitasker, the X Window System and the integration of both of these technologies. This document also describes the development processes necessary to create X Client graphical applications for DOS.

2 DESQview and PC Fundamentals

This section describes the fundamentals of the DESQview multitasking software and basic PC concepts. Readers familiar with these topics are still encouraged to read the information presented here.

2.1 Introduction

DESQview is a program that extends DOS (either PC-DOS,MS-DOS or DR DOS) into a fully pre-emptive multitasking system. Contrary to popular belief, DESQview can perform multitasking on all classes of processor - 8088, 8086 (PC-XT), 286 (PC-AT), 386 and 486. However, the technical advances of the later processors empower DESQview with greater capabilities.

DESQview is compatible with most current PC software - and can even run Microsoft Windows 3.0, 3.1 along with Windows programs, GEM-based, as well as other graphic programs simultaneously.

A program in the DESQview environment may run occupying the whole display screen, or can appear in a small window, framed by a border. Multiple applications may appear on the screen simultaneously, each in its own window.

Certain applications may run in a small window and in background, depending on how the program has been written and the type of processor being used - a table later in this section summarizes specific capabilities.

2.2 The PC Memory Map

A brief explanation of the architecture of a PC's memory map is beneficial to the understanding of this document. A PC's memory is laid out as follows:

2.2.1 Conventional Memory

Conventional Memory is memory that resides from 0K to 1024K (1MB). DOS, TSRs (Terminate and Stay Resident programs) and device drivers are loaded at the bottom of this memory with video RAM being located between 640K and 768K. Between the top of DOS and the bottom of video memory is the Application Area. Above the video area and below the top of conventional memory (1024K) is the System Area or what Quarterdeck refers to as High Memory. The System Area contains, for example, special system code such as the machine's BIOS (Basic Input/Output System) or RAM for a hardware card. Typically, this area is not contiguous, but contains portions of unused address space, sometimes more than 128K in size. See Quarterdeck's Manifest User Manual for a detailed description of High Memory (System Area).

2.2.2 Extended Memory

Extended Memory is memory that resides from 1MB and upwards (up to 16MB on a 286, 4 Gigabytes on a 386/486). It is available on machines that use a 286 processor or better and hence is not available on 8088/8086 machines. To be able to directly access this memory the processor must be in a special mode called protected mode. This mode is incompatible with DOS and DOS applications which run in real mode.

2.2.3 Expanded Memory

Expanded Memory is memory that acts as a pool of memory which, under the control of a special program (the Expanded Memory Manager), can be mapped into one or more conventional memory areas. Mapping is a process whereby a portion of expanded memory appears at a specific memory location through the use of special hardware (or in certain circumstances via software control - see the section titled Software Emulation of EMS Memory). Note that no transfer of data is actually performed - EMS memory is a bank-switch type of system (and hence very fast).

Unlike extended memory, expanded memory is available for all processor types. There are 3 different types of expanded memory, EMS 3.2, EEMS and EMS 4.0.

2.3 EMS 3.2

EMS 3.2 can only map four 16K pages of memory (64K) into conventional memory at a time, typically into a 64K area within the System Area called the EMS Page Frame. EMS 3.2 memory is essentially limited to enhancing the data handling capabilities of a program and has been superseded by the other two types of expanded memory.

2.4 EEMS and EMS 4.0

EEMS and EMS 4.0 memory can map multiple pages of varying size into conventional memory enhancing both data access and program execution capabilities - a far more flexible scheme than EMS 3.2. Note, however, that some EMS 3.2 memory boards were packaged with a 4.0 Expanded Memory Manager. Unfortunately, this gives the user an impression that EMS 4.0 memory is available with these boards, when only 3.2 capabilities are.

Note that for the remainder of this document, all references to EMS 4.0 memory are also applicable to EEMS memory.

2.5 Software Emulation of EMS memory

Due to the capabilities of the 386 and 486 processors, an Expanded memory manager like Quarterdeck's QEMM-386 can convert extended memory into EMS 4.0 memory. In the case of programs like QEMM-386, it is the Expanded memory manager that provides the mapping function through software control.

2.6 Multitasking more than 640K

Despite DOS normally being limited to 640K for its programs, DESQview can run more than 640K concurrently by using expanded memory. Programs are loaded first into the Application Area and when this is exhausted, DESQview will load programs into EMS 4.0 memory. As DESQview task switches from one application to another, it first maps the application from EMS memory into the Application Area and then runs it.

Note that EMS 3.2 memory is not used in this way due to the limitations of the specification; EMS 3.2 memory can only map a maximum of 64K and hence the available partition size is too small to contain the majority of programs.

On 8088/86 and 286 based systems, it is essential to disable motherboard memory to as low a value as possible (typically 256K) when using EMS 4.0 memory and DESQview. Due to hardware limitations of these processors, EMS 4.0 memory cannot be mapped on top of other memory (RAM or ROM) that is present in the system. If motherboard memory cannot be disabled, DESQview cannot multitask applications in EMS 4.0 memory. In the worst case, EMS 4.0 memory can act like EMS 3.2 memory to store swapped programs (see the Program Swapping section for details), but may still have the LOADHI capability outlined next.

2.7 LOADHI capability

Since DESQview uses the Application Area below 640K to perform its multitasking magic, it can be seen that the larger this area is, the larger applications can be that run under DESQview (unless an application is a DOS Extended application - see the DOS Extender section for details).

Any TSRs (Terminate and Stay Resident programs) or drivers (such as mouse or network drivers) that are loaded before DESQview occupy space in conventional memory on top of DOS and reduce the amount of memory available to the Application Area. It is therefore advisable to keep the number of TSRs and device drivers using conventional memory to a minimum to ensure a maximum amount of space for applications.

One solution is available with the Quarterdeck QRAM, QEMM-50/60 and QEMM-386 products - the LOADHI capability. With this utility, TSRs and device drivers can be loaded into the unused regions of the System Area, thus freeing up more space below 640K and enabling larger applications to be run inside of DESQview.

2.8 Program Swapping

When all of the Application Area and EMS 4.0 memory has been used to store programs, any further loading of applications will cause DESQview to swap applications already running onto either a hard disk, a network drive, a RAM drive or expanded memory (even EMS 3.2 can support this type of operation). Any programs swapped out in this way will be suspended from running. Despite being suspended, any swapped applications can be swapped back in at the request of the user with only a short delay. Doing this will force one of the currently running programs to be swapped out in order to make room if there is not enough memory for the incoming program.

Note: DESQview/X version 1.0 does not support DOS program swapping.

2.9 Switching and Windowing

Since DESQview can multitask multiple DOS applications, a user can switch from one application to another using two or three keystrokes or mouse clicks. Because of this, there is a concept in DESQview of one foreground application and multiple background applications.

Some applications may be running in windows smaller than the screen size and others may occupy the whole screen. In addition, some applications may be running in background, while others are suspended. These capabilities are dependent on the video behavior of the program and the machine's processor type.

2.10 Application Video Behavior

DOS applications may be written to produce display output in either of two ways. They may call DOS and BIOS routines to perform the output, or alternatively may write directly into the video area. The latter method is usually employed for speed reasons. Applications that use the DOS and BIOS routines are termed well-behaved and others that write directly to the video area are ill-behaved. Typically, graphical applications are ill-behaved; text-based applications may be either.

2.10.1 Well-Behaved Applications

Since DESQview can easily intercept DOS and BIOS calls, well-behaved applications may run in a small window or in background on any machine regardless of processor type. When a well-behaved application makes a video BIOS or DOS call, DESQview intercepts and executes the call, but places the relevant information in a special save area called the logical window buffer as well as clipping and shifting the information to appear within a small window on the screen.

2.10.2 Ill-Behaved Applications

Since ill-behaved applications write directly to the video RAM, DESQview cannot run them in a small window or in background unless the processor is a 386 or a 486 (see the Virtualization section for details). These applications, when run on an 8088/86 or 286 PC, can only run full screen in the foreground. Application developers should note that in many cases it is very easy to make an ill- behaved text application well-behaved, simply by adding a single subroutine call - see The SHADOW Call section for details.

2.10.3 Virtualization

Due to the sophisticated memory handling capabilities of the 386 and 486 processors, DESQview can redirect an application that writes directly to video RAM to a portion of memory that DESQview calls the logical window buffer. DESQview copies the information from this buffer to the actual video RAM, clipping and shifting it as necessary to appear within a small window. In this way, DESQview coupled with QEMM-386 and a 386 or 486 processor can virtualize ill-behaved applications (including graphics ones) in small windows and run them in background.

The only exception to this process are graphical DOS Extended applications - see the DOS Extenders section for more information. This is because the virtualization process uses a special processor mode that is incompatible with the DOS Extender.

Note: Version 1.0 of DESQview/X does not support the virtualization of DOS graphics programs.

2.10.4 Loaders

For machines that do not have a minimum of a 386 processor, a loader may be available to run an ill-behaved text program in a small window and in background. Loaders are utilities that alter a program's operation while it is running and coerce it into being well-behaved. Quarterdeck supplies several loaders with DESQview for use with programs such as Lotus 123.

2.11 Microsoft Windows

Microsoft Windows (and any Windows applications running within it) appears to DESQview simply as a graphical application and is handled as such. Consequently, Windows 3.0 real mode can be virtualized in a small window on machines with 386/486 processors whereas Windows 3.0 and 3.1 standard mode runs full screen (Windows standard mode acts like a DOS Extended graphical application).

Presently, Windows 3.0 and 3.1 386 enhanced mode does not function under DESQview. Note, however, that some of the extra capabilities of 386 enhanced mode (such as the virtualization of DOS windows) are duplicated in DESQview and are best handled by DESQview.

Note: DESQview/X includes special Windows drivers that enables Windows 3.0 in real mode and Windows 3.0, 3.1 in standard mode to run in small windows and remotely.

2.12 Application Types

There are three types of applications that exist in the DESQview multitasking environment: DESQview-oblivious, DESQview-aware and DESQview-specific.

DESQview-oblivious programs are ones that know nothing about DESQview - this includes programs like Lotus 123, Microsoft Word or AutoCAD.

A DESQview-aware program is one that has been modified slightly to make it run more efficiently in DESQview. Paradox, dBASE and WordPerfect are examples of DESQview-aware programs.

A DESQview-specific program has been written to take advantage of the DESQview API (Application Program Interface). Consequently, these programs can only run when DESQview is present.

2.13 DESQview API

Present in every copy of DESQview is the DESQview API (Application Program Interface). This interface allows programs to call the DESQview subroutines and functions in order to start and close down other applications; move, resize and scroll their windows; perform intertask communication and many other functions. The DESQview API is callable by Assembler, C, BASIC, Pascal, Clipper and dBASE programs.

2.13.1 The SHADOW Call

One API call of particular significance is the SHADOW call. This call may be made whether DESQview is present or not.

An ill-behaved text application will typically determine the kind of system present (monochrome or color) and load a variable with the corresponding video RAM value for the system (either B000H or B800H). From then on, the application will use the variable in order to access video RAM.

If during initialization, a program performs the SHADOW call using the desired video RAM value before storing it, the program will then become well-behaved when running under DESQview. This is because DESQview returns the logical window buffer for that application, whereas under DOS, the SHADOW call returns the value unchanged.

Since the application stores the returned value and uses it whenever video RAM access is required, the application is writing directly into the DESQview logical window buffer instead of to the screen. DESQview shadows from the logical window buffer to the screen, clipping and shifting as necessary, so the otherwise ill-behaved text application can run in a small window and in background on all processor types. This process is fast enough to be rarely noticeable by the user. WordPerfect, Dbase and Paradox are examples of commercially available programs that do this.

2.14 Processor Types and Modes

Since the original PC was introduced in 1981, various processors have been used, each one superseding the previous version and providing greater functionality. This functionality was always gained with the advantage of backward compatibility with all the previous processors.

2.14.1 The 8088/8086 and Real Mode

When the PC was first introduced, it used an Intel 8088 microprocessor. This is a 16-bit architecture processor with a segmented memory scheme capable of addressing 1MB. The 8088 used an 8 bit external data path unlike its otherwise functionally equivalent bigger brother, the 8086 which used an external data path of 16 bits. The mode of operation of these two processors is termed real mode.

2.14.2 The 286 and Protected Mode

The 286 processor supplies a real mode capability, but improved upon the 8088/86 by providing a new mode called protected mode. In protected mode, the 286 can access up to 16MB of memory (again by using a segmented addressing scheme), however certain operations available in real mode (such as segment arithmetic) are prohibited in protected mode. In addition, protected mode also has the hardware necessary for an operating system to protect an application from crashing the system or overwriting another application.

Unfortunately, protected mode is sufficiently different from real mode that DOS and regular DOS applications cannot operate in protected mode. For a long time this limited applications to running in real mode and hence constrained them to the 1MB limit. Thankfully, a solution has become available that addresses this called the DOS Extender - see the DOS Extenders section for details.

2.14.3 The 386 and V8086 Mode

Next to be introduced was the 386. Providing backward compatibility means that the 386 has both a real mode and protected mode capability. But in addition to this, Intel added a third mode called Virtual 8086 Mode that can operate under the auspices of protected mode. This mode supplies a virtual 1MB 8086 style environment while running in protected mode. This elegant solution enables regular DOS and real mode applications to run under protected mode without modification. The 386 also has an effective addressing range of 4 Gigabytes. It supports a flat memory model as well as a segmented addressing mechanism.

Also included in the 386 were memory mapping capabilities, a 32- bit architecture and hooks for a paged virtual memory system as opposed to a somewhat meager segmented virtual memory system that became available in the 286.

Note that 386 technology has been realized in several processors including the 386SX, 386SL and 386DX. The 386SX processor uses the 386 32-bit architecture internally, yet has a 16-bit external data path. The 386SL chip is a low power version of the 386SX with built-in power management features and is primarily designed for battery-powered computers. The 386DX processor (basically a renamed version of the original 386) uses an internal 32-bit architecture and a 32-bit external data path.

All 386 processors are functionally equivalent and are referred by the 386 moniker for the rest of this document.

2.14.4 The 486

The latest member of the 80x86 family to be introduced was the 486 processor. Basically this is similar to a 386 processor with an internal memory cache and is faster due to improved instruction execution. The 486 appears in several variants including a basic 486SX, a low power 486SL and a 486DX version that sports an internal math coprocessor (an optional external component with the 486SX,SL and all the other previous processors). Another variant is the 486DX2 processor which appears to a computer system much like a regular 486DX chip, but executes instructions internally at twice the speed of a 486DX.

All 486 processors are functionally equivalent (save for math functions) and are referred by the 486 moniker for the rest of this document.

2.15 DOS Extenders

Since DOS cannot run in protected mode, a way was devised for protected mode applications to run under DOS and use other real mode services. Protected mode applications are desirable since they have access to up to 16MB of memory on a 286 and 4 Gigabytes on a 386/486.

A DOS Extender is a special utility that is linked in to a protected mode application. Whenever the application makes a DOS call or any other request that requires real mode, the DOS Extender copies down any necessary data into the 1MB conventional memory area and switches into real mode. It then calls the requested function and on return switches back into protected mode, returning any results to the protected mode application.

There are usually two types of DOS Extenders - 286 DOS Extenders and 386 DOS Extenders.

286 DOS Extenders
These run 16-bit protected mode applications on a machine with a minimum of a 286 processor. They have access to a 16MB address space.

386 DOS Extenders
These run 32-bit protected mode applications on a machine with a minimum of a 386 processor. They have access to a 4GB address space.

Note that some DOS Extenders combine the capabilities of the two different types and can handle both 16-bit (286) protected mode applications as well as 32-bit (386) protected mode applications.

Most DOS Extenders also have a virtual memory option. That is, a DOS Extended application may run in less memory than normally is required by using virtual memory techniques.

In essence, the DOS Extender becomes the system's control program. This normally would have posed a problem to DESQview as protected mode allows only one control program in a system. Since DESQview multitasks applications, multiple DOS Extended applications would conflict with each other as each expects to be the control program. This is compounded with the fact that DESQview 386 (DESQview plus QEMM-386) is also a control program.

To obviate this problem, Quarterdeck and Phar Lap (one of the companies that produce a DOS Extender) developed the VCPI (Virtual Control Program Interface) specification which has been adopted by all major 386 DOS Extender manufacturers - see the VCPI Specification section for details.

It should be noted that VCPI is a specification for 386 and 486 processors, yet 16-bit protected mode applications may be run on 286 machines. In order for DESQview to multitask multiple 16-bit protected mode programs on a 286 so that they do not assume control of the same blocks of extended memory, their individual 286 DOS Extenders must use the XMS (Extended Memory Specification) interface specification. A utility program called QEXT.SYS supplies the necessary XMS services for 286 DOS Extenders running under DESQview on a 286 machine whereas QEMM-386 supplies the services for DESQview 386.

Note that a DOS Extended application consists of two parts. A real mode portion of the DOS Extender resides in conventional memory and interfaces with the protected mode portion that resides with the protected mode application in extended memory. When DESQview performs a task switch to a DOS Extended application, it ensures that the real mode portion of the application is mapped into the conventional memory Application Area and that the protected mode portion is visible in extended memory. Since the majority of the application resides in extended memory and only a small portion (the real mode part) need occupy the Application Area, DOS Extended applications tend not to be constrained by the size of the Application Area as regular real mode applications are.

Note: DESQview/X includes a built-in DOS Extender supporting 16- and 32-bit virtual memory and dynamic link libraries.

2.16 VCPI Specification

The VCPI specification was developed so that multiple protected mode control programs can coexist and interact within a single 386 (or 486) system. The specification consists of two parts - a VCPI server and several VCPI clients. The VCPI clients request memory and mode switching services from the VCPI server.

In a DESQview 386 system, the VCPI server is implemented within QEMM-386 and the DOS Extended applications become VCPI clients. Whenever a DOS Extended application requires memory services it calls upon the VCPI server to perform them. When QEMM-386 is not present, the DOS Extender performs all services for itself. The end result is that DESQview is able to run a mix of real mode and DOS Extended (protected mode) applications concurrently on a 386/486.

As mentioned earlier, 286 machines may run multiple 286 DOS Extended applications only if the DOS Extenders utilize XMS services.

2.17 DESQview Capabilities

DESQview's ability to window an application and run it in the background is a function of the machine's processor and the type of application. Here is a table that summarizes the possible combinations:

3 An Introduction to X

The basic concepts of the X Window System are described in this section. Readers familiar with X may elect to skip this section.

The X Window System is a powerful concept that utilizes machine and device independence as well as providing a graphical interface to users with both keyboard and mouse support.

3.1 Traditional Graphics Output

In traditional systems, if an application wishes to produce graphical output on a computer's display device, it will typically call a library or system software graphic subroutine. This subroutine performs the task requested (in the example shown, draw a line) and once the task has completed, control returns to the application.

3.2 X Servers, Clients and Protocol

In an X Window System, the system software is replaced by an application called the X Server - it is this application that has complete control of the display screen. An application that wishes to produce graphical output instructs the X Server to perform a specific task by sending it an information message that describes the task required. Sending a message to an X Server returns control immediately to the application and may or may not provoke a response from the Server.

The different types of messages are collectively called the X Protocol. One message draws a line, another a circle and yet another may print some text.

Any application that displays graphical output by sending X Protocol messages is labelled an X Client in contrast to an application that uses some other means.

In return the X Server may send back to an X Client special messages, such as event messages or error messages. These special messages are also part of the X Protocol.

X Clients typically create windows for their output. It is quite feasible (and generally the case) that a single X Client will create and utilize several windows on the X Server's screen simultaneously.

Note that an X Server may handle the graphics output for multiple X Clients concurrently and only understands X Protocol requests as a means to produce graphical output - it usually does not produce graphics output any other way.

3.3 An Event-Driven System

X is an event-driven system. That is, X Clients are typically suspended until an action occurs on the X Server for which they have a vested interest. X Clients are restarted by the X Server sending them special X Protocol messages. These event messages include ones that instruct an X Client to redraw its window (for example, if a part of its window becomes uncovered by the movement of another window), that a window's size has changed or that a key has been pressed. An X Client processes these messages, producing whatever output may be necessary and then returns to a suspended state until another message is received.

This is in direct contrast to the way traditional applications have been written. Those applications are procedure-oriented and are written to assume an active role in the interrelationship between the user and the program. Typically, the program will steer the user through the execution of the task at hand, forcing the user down a narrow set of predefined procedures. The program only accepts input (be it keystrokes or mouse clicks) from the user at predictable times. An order entry application is a good example of a procedure-oriented program.

Event-driven applications take a more passive role in that they respond to input from the user or the system at unpredictable times. This type of application can provide a more flexible framework within which a user may operate. Typically there are no predefined procedures and many ways to complete a task - a user is free to use whatever tools the application provides and in any manner desired to achieve the final result. A drawing/designing type of program is a good example of an event- driven application.

3.4 A Distributed System

Since the X Client communicates with the X Server through information messages, it is possible for the X Protocol requests to be sent over a network to an X Server running on a different machine.

In fact the X Window System was designed around a system of messages specifically to be a networked graphical system.

In the diagram, an X Client executing on machine A is displayed on machine C's screen (using the X Server on C) and an X Client executing on machine C is being displayed on machine B's screen (using machine B's X Server).

3.5 Operating System and Architecture Independence

None of the machines need be from the same vendor or running the same operating system, since all communication between X Clients and Servers is performed over a network using a well-defined message protocol (the X Protocol). Naturally, a program cannot be copied to a different type of machine on the network and subsequently run - it would have to be recompiled for a different machine's architecture/operating system.

3.6 X Terminals

In the previous diagram, one of the clients running on machine A is being displayed by a special machine that only has an X Server running on it - in effect acting as a remote graphics terminal to machine A. This type of machine is called an X Terminal and its sole purpose is to display graphics from X Clients running on remote machines.

Typically, the majority of PC implementations of the X Window System have been as X Terminals. PCs are notorious for memory limitations and hence an X Server application would normally occupy all of the PC's memory. With the advent of DESQview/X, however, PCs can run X Servers, DOS applications, Microsoft Windows and X Clients simultaneously.

3.7 A Stand-Alone System

In the previous diagram, machine B's X Server was displaying output from an X Client running on machine C, but is also displaying graphics from an X Client running on itself. In this case, the X Protocol messages are not sent out over the network to another X Server, but are routed within the machine to the local X Server.

This concept can be extended to include a scenario whereby the machine is not connected to a network - all X Clients run locally and are displayed by the local X Server. Naturally, this requires a multitasking operating system - such as DOS with DESQview.

3.8 The Window Manager

The X Server only produces graphical output according to X Protocol requests and does not provide functions for the user to control the size, position and stacking order of the displayed windows.

These functions could have been implemented within each X Client, but would have lead to much redundant programming. They could have been implemented within the X Server itself, but the designers of the X Window System took a more flexible approach.

A special X Client is run (either locally or remotely) for each X Server, called the window manager. This program is given special privileges and is allowed to supervise all of the windows being displayed by the X Server. The window manager will typically place some form of window decoration around the outside of each X Client window that includes resize and move buttons as well as a title bar. It then becomes a function of the window manager to resize, move, rearrange a window according to the wishes of the user by mouse clicks on a window's decoration or selections from a window manager menu.

At present, there are several managers for the X Window System, the most prominent of which are the OSF/Motif, OPEN LOOK and the Tab (previously known as Tom's) Window Managers. DESQview/X also supplies its own window manager, DESQview Window Manager (DWM).

Due to the design of the X Window System, a window manager may be closed down and another may be subsequently started- -without affecting any of the X Clients being displayed on the screen! The old window decorations disappear from the screen and are replaced by new decorations created by the incoming window manager.

Note that the window manager only creates the look and feel of an X Client with regards to its window decoration. Whatever an X Client chooses to display in its output window is independent of the window manager. Program libraries are available to X Client developers that allow them to create an application with a specific look - either an OPEN LOOK or OSF/Motif look, for example. These program libraries are called toolkits and are explored in the next section.

3.9 X Development Layers

In order to create an X Client, a developer will call upon a variety of program libraries for assistance. For DESQview/X, these libraries can be linked into each X Client, or may be a shared resource among all X Clients on a system through the use of Dynamic Link Libraries (DLLs).

3.9.1 Xlib

For an X Client to be able to communicate with an X Server, it needs to generate X Protocol requests for transmission to the Server. Building these requests can be cumbersome and hence a library was created called Xlib. Xlib is (generally) the lowest level interface that an X Client uses to communicate with the X Server. It is a set of C subroutines that, for the most part, are a one-to-one mapping from C to X Protocol requests, though some Xlib functions can generate multiple X Protocol requests.

For example, if an X Client uses the function XDrawLine it calls the appropriate code inside Xlib which builds a PolySegment request and transmits it to the X Server.

Note that the Xlib library imparts no specific look and feel to an X Client - it merely consists of requests to create a window, draw a line, print some text, etc. The appearance of an application is generally determined by another program library - a toolkit.

X Clients may be written so that they use only Xlib and no other program libraries (toolkits).

3.9.2 Toolkits

Since Xlib is rudimentary in the scope of its capabilities, another program layer may exist on top of Xlib - the toolkit. Toolkits generally have routines for building menus, push buttons, slider controls and the like. Since the toolkit generates these basic window components for the X Client, it is the toolkit which creates the actual look of an application.

An individual toolkit function may call several Xlib functions, which in turn can create multiple X Protocol requests.

For example, if the X Client wishes to make a popup window appear, it could call (using one specific toolkit) XtPopup to perform the function. XtPopup in turn makes several Xlib calls which may generate multiple X Protocol requests.

An X Client may still (and often does) call Xlib functions even if it uses a toolkit.

Some of the more prominent toolkits that are generally available are as follows.

Athena Toolkit
A fairly rudimentary toolkit supplied by MIT (Massachusetts Institute of Technology).

OSF/Motif Toolkit
This toolkit is supplied by the Open Software Foundation and provides a sculptured 3D look. This toolkit (and its complimentary window manager) is promoted by a consortium of companies (OSF) that include DEC, Hewlett-Packard and IBM.

Olit Toolkit
A toolkit conforming to the OPEN LOOK* graphical user interface standard that is 3D in appearance. This toolkit and its OPEN LOOK window manager is promoted by Unix System Laboratories.

XView Toolkit
A toolkit conforming to the OPEN LOOK* graphical user interface standard, but with a different programming interface (SunView) than Olit. It is promoted by Sun Microsystems.

*Note that OPEN LOOK is not a toolkit or window manager in itself - it is merely a design specification for the appearance of a user interface. Olit and XView are toolkits that adhere to this specification and hence create the same look and feel.

The following screen shots should help to illustrate the concepts of a Window Manager, Toolkits and the like.

The X Clients in the previous picture are:

QOS Background
An X Client written using only Xlib. A Toolkit is not necessary since it only creates a simple output window.

This electronic publishing package was written using the OSF/Motif Toolkit. The X Client is currently displaying two windows - an edit window and a Generate window.

Sun File Manager
OPEN LOOK has characteristic buttons with rounded ends. This file manager, which uses an OPEN LOOK toolkit, has these rounded buttons. This X Client is currently displaying two windows - a directory tree and a wastebasket box.

This X client uses the Athena Toolkit to display a terminal session with a scrollbar on the left.

All of these X Clients are running under the control of the DESQview/X Window Manager. The window manager has placed a frame around many of the windows on the screen, along with decorations such as title bar and window number.

If the DESQview/X Window Manager is closed down and the OSF/Motif window manager is started, the following display appears:

Despite a change in window managers, the X Clients' window contents remain the same. Only the window decoration has changed - in this case to an OSF/Motif 3D effect. Note that with the OSF/Motif window manager active, the X Client built using the OSF/Motif toolkit (FrameMaker) blends well into the environment, since it has the same appearance style as the window manager.

If the OSF/Motif window manager is now replaced by an OPEN LOOK window manager, the following display appears:

Once again a change in window managers does not change the contents of the X Clients' windows - only the window decoration has altered. In a similar fashion to FrameMaker and the OSF/Motif window manager, it can be seen that the Sun File Manager windows complement the OPEN LOOK window manager's window decoration. This is because both of these products were built using an OPEN LOOK toolkit and hence have an OPEN LOOK appearance.

Although it is unlikely that a user would want to run X Clients without a window manager, the following picture shows how this would appear:

As can be seen in the previous picture, the usefulness of having no window manager is debatable, but not impossible. Having no window manager active would most probably occur when only one X Client is being run on an X Server.

These pictures highlight the concept of a window manager as being a special X Client that decorates the outside of all other X Clients' windows and allows a user to control their size, position and ordering on the screen. The pictures also show how a toolkit influences the look and feel of an X Client and how its appearance is independent of the active window manager.

3.9.3 Intrinsics and Widgets

Some toolkits may only be regarded as a single entity, but others are conceptually split into two parts. One of these parts is termed the Intrinsics and the other part, a Widget Set.

The Widget Set

Widgets are abstract data objects such as buttons, scrollbars and other such objects. An X Client can be easily constructed from a number of widgets. The X Client does not have direct control of the actual appearance of a widget - only its general form, size or contents. The appearance is determined by the toolkit.

A Widget Set uses both function calls in the Intrinsics as well as Xlib.

3.9.4 The Intrinsics

The Intrinsics provide an object-oriented framework on which a Widget Set depends. It handles the creation, deletion and management of widgets as well as their event message handling. It is possible for an X Client to call the Intrinsics directly as well as the Widget Set (and of course, Xlib).

The Athena, OSF/Motif and Olit Toolkits consist of a Widget Set and the first Intrinsics to be developed for X - Xt.

3.10 Xt Intrinsics

In some cases, an X Client may only call the Xt Intrinsics and Xlib library. This type of application provides its own widget set, hence supporting its own unique set of abstract data objects (widgets) that are manipulated and managed by Xt.

An application that does this is able to provide its own look and feel, all the while saving its developer time and effort by using the object-oriented functions of Xt.


MIT in association with a consortium of companies who have a vested interest in the X Window System (The X Consortium) releases MIT X distribution tapes containing the Xlib and Xt libraries as well as sample X Clients and an X Server. It is these tapes on which all other toolkits and X products are based.

The current revision of these distribution tapes is the X version 11 release 5 of the X Window System, otherwise known as X11 R5.

3.11 Toolkit Summary

Here follows a table of the Toolkits discussed in this document in summary form for quick reference:

4 DESQview/X

This section describes how the X Window System is integrated into the DESQview environment resulting in DESQview/X and highlights the capabilities of the combined system.

4.1 Minimum Requirements

DESQview/X currently requires a minimum of a 386SX processor, an EGA display, 4MB of RAM and 10MB of free hard disk space. In addition, a mouse is highly recommended.

4.2 General Structure

The general structure of a stand-alone DESQview/X system is shown to the right.

DESQview is loaded on top of DOS, the first program booted into the computer. Multitasking within DESQview can be several program partitions - one containing an X Server in the case of DESQview/X.

4.2.1 The X Server

Display output for the system is provided by the X Server program. The X Server is run within a DESQview partition and is multitasked along with all of the other programs in the system. The X Server in DESQview/X v1.0 is based on Release 4.0 of the X Window System.

The X Server controls the display screen (for the most part) and hence the display resolution of the system and compatible display types are determined by the X Server and not by DESQview. Currently EGA, VGA, Super VGA, 8514/A and DGIS displays are supported. XGA, TIGA and S3 displays are expected for the future - check with Quarterdeck Office Systems for an up-to-date list of displays supported.

The X Server is run as a DOS Extended application (up to 16MB) - this gives the X Server more workspace to perform its display functions and enables it to handle more windows concurrently. It is also available in virtual memory form so that it may use less memory than is normally required.

4.2.2 Socket Driver

Communication in most X Window Systems is accomplished using the Berkeley Socket interface. Consequently, DESQview/X includes the DESQview/X Socket Driver, which accepts these communication requests and intelligently routes the message to the appropriate destination. In the case of a standalone DESQview/X system, the messages are always routed between the X Server and the applications using the X Server for output. Note that the DESQview/X Socket Driver is loaded as part of the DESQview multitasking kernel.

4.2.3 Regular DOS Applications

If a regular real mode DOS application (for example WordPerfect or Lotus 123 release 2) is running within the system, its display output is translated dynamically (that is on-the-fly) by special DESQview/X Translation Software into X Protocol requests.These X Protocol requests are sent using the Berkeley Socket interface to the Socket Driver which routes them to the X Server for output. In effect, a DOS application is made to appear like a regular X Client.

DESQview/X does this for well-behaved applications by trapping their BIOS and DOS calls and converting them into X Protocol requests.

In the case of ill-behaved real mode applications DESQview/X virtualizes the application. DESQview/X remaps the application's video RAM to a different portion of memory and scans this logical window buffer for any changes, producing X Protocol requests from the scanning process. Note that this process requires a minimum of a 386 processor - the 286 processor lacks the necessary hardware to perform the remapping operation.

If a regular DOS application is DOS Extended (for example Lotus 123 release 3 or Paradox) and is running within the system, it is treated much the same as a regular real mode DOS application. The major difference being that DOS Extended applications have a far greater workspace available to them than do regular DOS applications (up to 16MB for a 16-bit protected mode application, 4GB for a 32-bit protected mode application).

4.2.4 DESQview API Applications

DESQview API Applications are, by their very nature, well-behaved DOS applications as they use the DESQview API to perform display output. However, the DESQview API allows these applications to create multiple windows as well perform display output to these windows.

This is handled in DESQview/X by intercepting all of the DESQview API calls and generating equivalent X Protocol requests, turning a DESQview API application into what would appear to be an X Client, just as with a regular well-behaved DOS application.

4.2.5 Microsoft Windows and Windows Applications

If Microsoft Windows 3.0 or 3.1 is running in a DESQview/X system along with one or more Windows applications, DESQview/X dynamically translates all Windows display output into X Protocol requests, much the same as it does with regular DOS applications. In effect, Microsoft Windows and Windows applications are made to appear like a regular X Client.

Because of this, a Microsoft Windows session can appear within a resizeable DESQview/X window alongside other X Client windows.

4.2.6 Regular DOS Graphical Applications

Translating a DOS application's graphics screen into X Protocol requests is possible, but is not implemented in DESQview/X Version 1.0. Currently, DESQview/X runs all regular DOS graphical applications as full screen applications only.

4.2.7 X Clients

X Clients may be running on a DESQview/X machine in one of three forms. If small enough to fit within the conventional memory Application Area, they may run in real mode. If larger, they require a DOS Extender to reside in the system. If the X Client is a 16-bit protected mode application, it may be as large as 16MB. If it is a 32-bit protected mode application, the X Client may (theoretically) be as large as 4GB.

Since X Clients already produce X Protocol requests (unlike DOS or Microsoft Windows applications), they need no translation software. Instead, their X Protocol requests are sent to the Socket Driver from the applicable Xlib routines using the Berkeley Socket interface (the standard method of communication in an X Window System). The Socket Driver then routes them directly to the X Server for display output.

Note that these X Clients may be ported from other X platforms (such as many Unix machines) or else may be developed directly under DESQview/X - see the Development Issues section for details.

It should be remembered that an X Client is similar to a DOS graphical application in that it produces graphical output, but is very different in the way it achieves this. DOS graphical applications usually write directly to video RAM; an X Client uses X Protocol requests to an X Server to produce the same effect. Thus an X Client can always be windowed.

4.3 Direct Windows

Note that regular DOS and Microsoft Windows applications can be configured to bypass the DESQview/X translation software and run as full screen direct windows (like regular DOS Graphical applications). Doing this eliminates the overhead of translating an application into X protocol requests, resulting in an increase of display speed, but at the expense of the application not being able to display on a remote machine.

4.4 Available Memory

In a typical DESQview/X system, real mode applications usually have at least 500K available to them regardless of their type - DESQview API, regular DOS or otherwise.

DOS Extended applications (which includes Microsoft Windows in standard mode), on the other hand, are usually constrained only by the total amount of memory in the system.

4.5 The Window Manager

Since a user will want to control the windows displayed on the screen by the X Server, a minimum of one X Client will normally be run in a DESQview/X system - the window manager. The window managers that are currently available include:

The DESQview/X Window Manager provides a 3D sculpted look and has a menu system similar to DESQview. In addition, it boasts popular DESQview features such as Mark & Transfer and scripts. Best of all, DWM is under 100K in size!

Using the OSF/Motif 3D sculpted look, this window manager is a DOS Extended X Client.

This window manager implements the OPEN LOOK graphical user interface and is a DOS extender X Client.

4.6 Fonts

The X Window System (through Release 4.0) has typically relied on bitmapped fonts to produce text output on an X Server. That is, a bitmap exists for a specific typeface (for example, Helvetica or Times Roman) realized at a specific point size. If an X Client requests a particular size of typeface and that size is not available (even though other point sizes in that typeface are available), the X Server would normally tell the X Client that the font does not exist and the X Client either terminates or uses a different font.

Drawbacks to this technique include the limited availability of a typeface to a few point sizes (typically 8 to 24) as well as excess use of hard disk space to store the different sizes that are supported.

4.6.1 Scalable Fonts

With the advent of laser printers, Adobe Systems, Inc introduced the PostScript printing language that took a different approach. Each typeface file was coded in such a way that the printer could scale an individual typeface to any size required. This new file format and the typefaces that were encoded in it are termed Adobe Type 1 fonts.

The intelligence inside of the laser printers that produces the scaling function is actually a sophisticated computer program developed by Adobe Systems, Inc. This technology has been licensed by Quarterdeck Office Systems, Inc and has been incorporated transparently into the DESQview/X system. These font extensions, in no way prohibit continued support of Quarterdeck's scalable fonts when DESQview/X supports the X Window System Release 5.0 (which does define the use of scalable fonts).

When an X Client requests a typeface at a particular size, the DESQview/X X Server first checks its list of available fonts - this font list contains both bitmap and Adobe Type 1 fonts. If it cannot find either a bitmap font of the correct size or a scalable font that can be scaled appropriately, the X Server will return an error. If, however, a font was found, the X Server checks to see if it is presently loaded into memory (for another X Client). If necessary, the X Server will load the font and (in the case of Adobe Type 1 fonts) scale it to the requested size.

4.6.2 Using Scalable Fonts

Advantages of the scalable font technology include an almost endless choice of point sizes for a particular typeface as well as the subsequent economies of hard disk space. In addition, the Adobe Type 1 font format has proved to be the most popular and prolific file type resulting in a vast choice of Type 1 typefaces currently available.

Since the interface for using a scalable font is identical to that for requesting a bitmapped font, an X Client which has no knowledge of scalable fonts may, in fact, be given a scalable font realized at a particular point size if the requested bitmapped one is not present!

On the other hand, an X Client that has been written to recognize scalable fonts can use them to its advantage by creating fully scalable windows, wherein if a user resizes a window, the contents of the window (including the text) scales accordingly. In addition, this kind of X Client can also make use of the fractional spacing and kerning information that is stored in the scalable font file. One example of an X Client that uses scalable windows is the Adobe Type Manager that is supplied with DESQview/X which allows a user to install or delete Adobe Type 1 fonts from a DESQview/X system.

4.6.3 Scalable DOS Windows

Scalable fonts have also been used to great advantage in DESQview/X when displaying DOS text windows (regular DOS applications). When instructed to do so, DESQview/X will scale a DOS window to whatever size the user resizes the window - from a window that occupies the full screen all the way down to a size where each character in the window is represented by only a single pixel!

The benefits of this technology become clear within minutes of using it - a user can view many more DOS windows simultaneously than was previously possible and can shrink a window down to its minimum size in order to keep an eye on the DOS application's progress in background (for example, when performing a long file transfer with a communications program).

4.7 Advanced Memory Management

Incorporated into DESQview/X is the DOS/4GX Extender technology from Rational Systems, Inc that provides many useful benefits in the area of memory management.

With this technology, it is possible for DESQview/X to run all three types of application for the PC (real mode, 16-bit protected and 32-bit protected) directly. This produces a substantial saving in memory overhead for protected mode applications.

In addition, the DOS/4GX technology also provides both virtual memory and dynamic link library (DLL) capabilities to protected mode applications.

Note, however, that only applications generated specifically for the DOS/4GX Extender can call upon the DOS/4GX technology in DESQview/X. This does not, however, preclude applications developed using other DOS Extenders from running in a DESQview/X system - they will simply not be as memory conscious as a DOS/4GX application since a separate copy of the DOS Extender will be loaded for each instance of the program. In addition, they will not be able to take advantage of virtual memory or dynamic link libraries unless their individual DOS Extender supports these features.

4.7.1 Virtual Memory

Virtual Memory is a technique used in advanced computer systems, wherein an application is divided up into discrete chunks - usually these chunks are regular in size and are called pages (otherwise if the chunks are irregular in size, they are called segments, though for the rest of this section the former term will be used).

When an application is actively running, it typically only uses a few pages of the program in a given time frame - these active chunks are referred to by computer scientists as the working set of pages. Since only a few pages are being used at any one time, a large program can waste a lot of memory in a system with inactive pages that may never even be used.

To maximize the use of memory, a computer can load only the working set of pages into memory and run the application as normal. If the application requires a page that is not currently in memory (for example, when jumping to a different part of the program, crossing over from one page to the next or accessing a piece of data), a page fault is generated by the computer hardware. At this point, the computer chooses a page not being used, swaps it out to hard disk, reads in the required page and then continues executing the application. This process is totally invisible to the application and requires no special programming by the application's developer, hence the term virtual memory since the memory always appears to be present to the developer, though physically it may not be all the time.

It is important, however, that sufficient memory is available to hold an application's working set - too little memory will cause page faults to happen with greater frequency so that the computer will spend most of its time accessing the hard disk.

With its DOS/4GX technology, DESQview/X provides this virtual memory option so that more applications can be run concurrently than the amount of memory would normally dictate.

4.7.2 Dynamic Link Libraries

Most applications call on a standard set of routines which need to be duplicated in every application that uses them. Typically these routines are stored in a library of routines and are linked in when an application is being generated (at compile time). A good example of this would be the Xlib programming library that is required by X Clients.

Naturally, this leads to a waste of both computer memory and hard disk space as the same information appears in separate applications.

Dynamic Link Libraries (or DLLs) are a way of sharing these routines among several applications. The routines are stored on disk in only one place - the dynamic link library - saving space on a computer's hard disk. Whenever an application is loaded that requires a specific DLL, the computer first checks to see if that DLL has already been loaded for another application. If it has been loaded, the computer points the application to the DLL already in memory. If it is not loaded, the computer will load the DLL first before it can be used by the application. Since multiple applications use the same copy of the DLL while running, memory space is conserved. Note that when all applications using a DLL terminate, the DLL is discarded from memory as it is no longer needed.

Along with the advantages of saving disk and memory space, DLLs also provide another benefit known as late-binding. Early-binding occurs when routines are linked into an application at compile/link time on the application developer's machine - the application becomes a single entity that cannot be changed unless the developer issues an update. DLLs, by their very nature, exhibit late-binding - the linking process occurs at run time, on the user's machine, after the application was compiled.

This difference seems trivial until a scenario is considered whereby several different applications from different manufacturers (or even the same manufacturer) use the same DLL. Assume the DLL provides access to a particular type of device, a tape drive for example, and that the drive manufacturer releases a new drive with a slightly different hardware interface. Without DLLs, all applications that used the previous tape drive would have to be recompiled by their respective companies and updates sent to existing customers that purchase the new drive. With DLLs, only a new DLL need be produced and distributed to customers along with the new drive. The more applications that use a particular DLL, the bigger the advantage of late-binding. Note that DLLs are not updated solely because of new features, but can also be updated because of enhancements to a DLL's routines.

With its DOS/4GX technology, DESQview/X can conserve both disk and memory space as well as delivering the advantages of late- binding through the availability of a dynamic link library option.

4.8 Print Server

The DESQview/X Print Server consists of several components - a Print Manager, an X Print Server and an X Print Driver. In addition, the Print Server calls upon the services of the DESQview/X Resource Manager when printing from DOS applications.

For DOS applications, DESQview/X may be configured such that it will manage contention for the same printer and can spool the print information to disk until a printer is ready to receive it. (Note that DESQview/X can also be configured such that no spooling or contention management is performed and printer output is routed directly to a printer.)

For X Clients, DESQview/X always spools X Protocol requests to disk and translates these requests into the appropriate printer commands thus providing a single output imaging model.

The components of the DESQview/X Print Server and the interrelationships between those components are shown to the right.

Despite there being the interaction of several components in order to print a file under DESQview/X, the user normally only sees and interacts with the Print Manager (which provides choices such as holding, resuming and killing print jobs). The X Print Driver is a daemon (unseen) process that is both created and killed by the Print Manager, the X Print Server is implemented inside of the X Server process and the DESQview/X Resource Manager is a special driver loaded by the DESQview multitasker.

4.8.1 DOS Application Printing

When a DOS application prints to a printer, it does so through either the printer ports LPT1, LPT2, LPT3, the communication ports COM1, COM2, or the DOS file handle 4. When running in DESQview/X, the DESQview/X Resource Manager traps these requests and spools the print information into a DOS print file as well as creating a print control file that specifies additional information (such as which printer to print the file on and the number of copies). These two files are created in the DESQview/X spool directory. The Resource Manager then informs the Print Manager of the file that needs printing, whereupon the Print Manager adds the request to the end of its print list.

When the Print Manager is ready to print a particular file, it reads the information from the relevant printer control file and routes the DOS print information from the file to the correct printer. The Resource Manager recognizes that it is the Print Manager trying to print and allows the printer information to pass through (via the printer ports LPTx, communication ports COMx or DOS file handle 4) instead of trapping the print operation.

Note that DESQview/X does not alter the DOS print information in any way. Therefore, all DOS applications must be configured correctly for the printer type attached to a DESQview/X system (PostScript, IBM Proprinter or otherwise).

4.8.2 X Client Printing

Unfortunately, the X Window System does not define a standard for X Clients to produce printer output, with each system manufacturer taking their own approach. It was decided for DESQview/X that printing from an X Client should be performed using exactly the same method as for displaying output on the screen, that is, by using the X Protocol.

This single imaging model has the distinct advantage of simplifying the coding of X Clients as they need only support one type of output device - regardless of whether the output is destined for the screen or printer. In addition, this also makes existing X Clients easier to update to include printing capabilities.

Under the X Window System, an X Client specifies on which X Server it wishes to display output by means of an address that takes the form machine_name:display_number.screen_number (note that in X, the term display refers to a workstation that consists of a keyboard, a pointing device and one or more screens). Hence the address radish:2.1 refers to the second screen (0 is the first and 1 is the second) on the third workstation (0,1 then 2) on the machine called radish on the network.

If an X Client connects to a DESQview/X workstation using the display number 7, for example radish:7, (note that if a screen number is not specified it is presumed to be 0), the X Print Server in the DESQview/X X Server recognizes this and spools the X Client's X Protocol requests into a file in the DESQview/X spool directory. In addition it also creates a print control file that specifies additional information for the Print Manager.

When the X Client disconnects from display number 7, the X Print Server informs the Print Manager of the file that needs printing, whereupon the Print Manager adds the request to the end of its print list.

When the Print Manager is ready to print a particular file, it reads the information from the relevant printer control file and, recognizing that the file is an X Protocol file, passes the file over to the X Print Driver for processing. Note that the X Print Driver is under the control of the Print Manger which both starts and removes the X Print Driver from the system as necessary. When the X Print Driver is handed an X Protocol File, it translates the X Protocol requests into the necessary printer codes and outputs them to the X Printer connected to the DESQview/X system.

The Resource Manager recognizes that it is the X Print Driver trying to print and allows the printer information to pass through (via the printer ports LPTx, communication ports COMx or DOS file handle 4) instead of trapping the print operation.

Note that only one printer may be designated as the X Printer (though, DOS applications may also output to this printer if they are configured to recognize the printer type) - the selection of the X Printer is performed using the DESQview/X Setup program.

4.8.3 Print Manager

The Print Manager can be thought of as a traffic officer, directing files to the appropriate printers at specific times or alternatively to the X Print Driver. It is possible for the user to interact with the the Print Manager, list and reorder files in its print queue, suspend and resume printing as well as other operations.

Note, however, that DESQview/X may be configured such that spooling can still occur even if the Print Manager is not present in the system. When the user then starts up the Print Manager, it searches the spool directory for printer control files, produces a resulting print queue and begins printing.

4.9 The Network Connection

When a DESQview/X system is connected to a network, the structure is identical to that of a stand-alone system, but with the inclusion of network software and the DESQview/X Network Manager.

4.9.1 The Network Manager

The DESQview/X Network Manager is the bridge between the DESQview/X Socket Driver and the underlying network software. Since PC networks and their supporting network software vary greatly, a different version of the Network Manager is supplied depending on the type of network installed. Currently, the DESQview/X Network Manager can communicate using the following network APIs and network software: NetBIOS, Novell Netware IPX/SPX, FTP Systems PC/TCP, and Novell's LAN WorkPlace for DOS. Check with Quarterdeck Office Systems for an up-to-date list of network APIs/software supported.

Note that there are many pieces in the network puzzle that must be compatible with each other in order for DESQview/X (or any other piece of software) to function over a network.

The DESQview/X Network Manager communicates with the Network Software using a network API. The network software in turn communicates with a piece of network hardware (using the hardware's specific interface) which then sends the network data out over a network medium (usually a cable of some sort) according to a network protocol (a particular format for the data). The examples at right should make this relationship clear.

Because of the tremendous variety available between network software and hardware, Quarterdeck Office Systems cannot publish an exhaustive list of networks supported. Quarterdeck has an ongoing program to support popular network API's/software and will be making them available as soon as they are developed.

4.9.2 Operation over a Network

When an X Client (DOS-based X Client, DOS or Microsoft Windows application translated to X Protocol requests) is started under DESQview/X, a parameter is supplied that specifies which screen the program's output should be displayed on. (This is standard procedure for any X Window System.) If the display specified is not the local DESQview/X screen, the DESQview/X Socket Driver will route the X Protocol requests to the DESQview/X Network Manager. The Network Manager then uses the appropriate network API to transmit the request to the correct machine on the network via the network software. If, on the other hand, the output should appear on the local screen, the Socket Driver will route the X Protocol requests directly to the local X Server as in the case of the stand-alone system.

Conversely, if another machine on the network sends X Protocol requests to the DESQview/X system for display on its screen, the request is first accepted by the Network Manager. The Network Manager will then route the requests to the local X Server via the Socket Driver by using the Berkeley Socket interface.

4.9.3 Communication Ports

Most networks rely on the notion of ports when communicating. An application will connect to a port on a remote machine in order to communicate with it. In machines that run the X Window System, TCP/IP or the Unix operating system, several of these ports are reserved and imply a special type of connection.

For example, port numbers starting at 6000 are the X Protocol ports (remember that a machine can have multiple X Servers connected to it so that 6000 refers to the first X Server (or display number 0), 6001 to the second, etc). Whenever an application connects to port (for example) 6002 on a remote machine and sends a message to it, the receiving machine knows that it is an X Protocol request by virtue of the port number. It is then the receiving machine's duty to dispatch the request to the appropriate X Server (the third X Server, or display number 2, in this case).

Note that there can be multiple connections to a single port. This is because a connection is defined by both the sending machine/port number and the receiving machine/port number. Since most reserved ports do not take into account the number of the sending port, one machine can have multiple connections to another machine's port by choosing different send ports. This is necessary when (for example) multiple applications on one machine connect to the X Server on another.

Other reserved ports imply several other functions - RSH (Remote Shell), REXEC (Remote Exec), FTP (File Transfer Protocol) and Telnet. Unlike the X Protocol port, these 4 other ports typically spawn daemons - programs that are invisible to users of the remote machine and execute in the background. DESQview/X supplies daemons for RSH, REXEC and FTP, but not Telnet - see the Telnet section for details.

4.9.4 Remote Shell

A remote shell (RSH) is one method for starting up applications on remote (other) machines anywhere on the network. When a user types in an RSH command on one machine, the RSH program connects to the RSH port on the remote machine. At this point, the remote machine (recognizing that the RSH port was connected to), spawns an RSH daemon. This RSH daemon takes the command supplied in the RSH message and executes it on the remote machine for the user specified in the message, sending any output back to the originating port - typically this output is simply echoed to the screen by the originator's RSH program.

DESQview/X supplies both an RSH daemon to respond to RSH requests as well as an RSH program that can send RSH requests to another machine.

This is a very powerful concept - remember that X Protocol requests produced by an X Client may be routed to any X Server on the network. A user seated at one machine (be it DESQview/X or Unix) may use the remote shell feature to start up an application on another machine, yet have its output appear on the user's local machine (or any other display on the network). The user is now able to operate and use the X Client that is running remotely. X Clients that are run this way are termed remote clients.

Naturally, there are safeguards in the RSH feature that are intended to stop unauthorized access to remote machines, however, they are far from complete. Because of this, the Remote Exec feature was developed.

4.9.5 Remote Exec

The remote exec (REXEC) function is very similar to the RSH command except for how it guards against unauthorized access. With REXEC, the user supplies a password that is transmitted along with the REXEC command. If the password is not valid for the user name specified in the message, the command will fail.

DESQview/X supplies both an REXEC daemon to respond to REXEC requests as well as an REXEC program that can send REXEC requests to another machine.

4.9.6 File Transfer Protocol

The file transfer protocol (FTP) function is used to transfer files to and from a remote machine, as well as list directories on the remote machine.

The FTP daemon responds to a limited set of english-like commands that specify actions such as listing a directory, changing to another directory and receiving or transmitting a file. The DESQview/X File Manager application uses these capabilities to perform sophisticated file operations between machines. It connects to the remote machine's FTP port and issues the low-level FTP commands to gather information required and transfer files.

DESQview/X supplies an FTP daemon to respond to FTP requests and the DESQview/X Network Manager - DESQview/X to Other X Systems includes an FTP program that can send basic FTP requests to another machine. The FTP program is not included in the base product as the File Manager companion is easier to use and more advanced.

4.9.7 Telnet

The Telnet function is used to create a terminal session on a remote machine which is displayed on the local machine. A Telnet request invokes the Telnet daemon, which in turn (typically) starts a shell program, such as the login program on most Unix machines. The session then behaves much like a modem communications session - the shell program on the remote machine (and any programs run under the shell) send characters and terminal control sequences which are routed via the Telnet daemon to the Telnet requestor and then to the user's display. In turn, the Telnet requestor will also send characters typed by the user to the Telnet daemon which routes them to the shell program.

Since Telnet was primarily designed for communicating with a TTY- style (line and character-oriented) device, the Telnet daemon has not been implemented for DESQview/X as this would require a program capable of translating DOS screens into TTY-style commands. Instead, a remote machine running the X Window System can use RSH or REXEC to start a DOS session. Note, however, DESQview/X does supply a Telnet client that can start a Telnet session on a remote (non-DESQview/X) machine.

4.9.8 Remote Clients

The remote shell and remote exec functions open up a wealth of possibilities for users connected over a network by spawning remote clients. All of the X Clients on an X network can be started up and used by any X Window user on the system.

Since regular DOS and Microsoft Windows application screens can be dynamically converted to X Protocol requests by DESQview/X, DOS and Windows applications appear on a network as X Clients. Because of this, non-DOS users on a network may use DOS and Windows applications available on a DESQview/X machine. Applications that may not be used this way are those which cannot be translated into X Protocol requests on the host DESQview/X system. Currently, those applications are regular DOS graphical applications.

In effect, any DESQview/X machines on a network appear somewhat as Unix machines with their DOS and Microsoft Windows applications running as X Clients.

The converse to the above is also applicable - a networked DESQview/X machine may use X Clients available on other non-DOS machines (for example, a Sun or SCO Unix system.)

4.9.9 Interprocess Communications

Communications between processes is implemented in DESQview/X through the industry standard Berkeley Socket interface - the primary means of IPC communications for Unix machines.

This interface was designed to be totally independent of any underlying network and hence can be used by one process to communicate with another on a different machine across a network, regardless of the type of network (TCP/IP or Novell, for example). In DESQview/X, Berkeley Socket interface calls are accepted by the DESQview/X Socket Driver which routes them to the appropriate destination - whether to another application in the same machine, or to an application on a remote machine by broadcasting the message over a network. This results in the simplified coding of an application as it communicates with both local and remote applications in exactly the same way.

In a similar fashion to the DESQview API mailbox interface, the Berkeley Socket interface does not dictate the content of the message sent to another process, hence any manner of dialog may be implemented between two processes.

4.10 Stand-Alone or Networked?

DESQview/X may be run either as a stand-alone system or networked.

If run as a stand-alone system, applications typically run on the system will be the X Server (for display output), a window manager (to control the windows), multiple DOS and Windows applications and multiple X Clients.

If a DESQview/X machine is networked, the minimum required running is the X Server and Network Manager. The window manager and any X Clients (be they regular X Clients or dynamically translated DOS or Windows applications running on another DESQview/X machine) may all be run remotely on other machines on the network. Usually, some local applications will also be run.

4.10.1 Unix Machines and DOS/Microsoft Windows programs

Assume a network to primarily consist of Unix machines and/or X terminals. If a DESQview/X machine is added to the network that has a powerful processor (such as a 386 or 486), all of the Unix X Window users would then be able to use many of the DOS and Microsoft Windows applications that are available on the DOS (DESQview/X) machine.

4.10.2 DOS Machines and Unix Programs

The converse to the above situation is also true. On a DOS-based (DESQview/X) network, the addition of a Unix machine provides the DOS users access to any X Clients on the Unix machine. Large, powerful applications now become feasible that are not available for DOS and which would suffer running under a slower processor. In addition, by using the Xterm application on a Unix machine enables DOS users to access that machine's character- based non-X applications as well.

4.11 A User's View

It is not important to the user whether an application being used is running locally or remotely. It is possible with DESQview/X to hide all of these details, such that a user views a screen much like the one shown.

The screen shot shows a DESQview/X system with the DESQview/X Window Manager. Some applications are labelled remote or local for illustration purposes only, though a user's implementation of this system may elect not to show this kind of information.

In the picture, DOS 128K (COMMAND.COM) and Borland C++ are DOS applications, one running on a remote DESQview/X machine, the other locally; Lotus 123 is also a local DOS application, but is displayed in a scalable DOS window. Application Manager (labelled Toolbox), its Help window and Clock are DOS-based X Clients; Xterm is a remote X Client running on a Sun workstation; and MS Windows is a Microsoft Windows session that is being run on another DESQview/X system, but displayed locally.

4.12 A Consistent Growth Path

DESQview/X is built on the existing technology of DESQview and DESQview 386 - two time-proven DOS multitaskers that are popular worldwide. Because of this, Quarterdeck can provide users with an excellent and consistent growth path that starts with DESQview:

DESQview provides the DOS user with a multitasking environment on machines with as little as 640K, a hard disk, a monochrome monitor and an 8088 processor. DESQview is a character-based environment, but can also run graphics applications. Features include windowing and program swapping as well a keyboard macro program, a help system, a DOS Services utility and easy-to- use keyboard or mouse control.

DESQview 386
In addition to DESQview's features, DESQview 386 provides the 386/486 DOS user with a multitasking environment that incorporates superior memory handling, windowing features and program protection.

DESQview/X incorporates the functionality of DESQview and DESQview 386, yet sports a graphical interface that is consistent with the menuing system used by those products. Because of its complete X Window capability, DESQview/X also gives users the capability to run local X Clients as well as access to DOS or Microsoft Windows applications and X Clients on remote machines (using the appropriate network software).

DESQview/X and OSF/Motif, OPEN LOOK Window Managers
When DESQview/X is joined by either the OSF/Motif or an OPEN LOOK window manager, users will have a consistent look and feel across all machines on a network, from DOS machines (DESQview/X) to X Terminals, Unix workstations, minis and mainframes.

4.13 DESQview/X System Capabilities

The capabilities of a DESQview/X system outlined in the preceding sections can be dependent on many factors. Consequently, here is a table of DESQview/X's capabilities:

5 Development Issues

This section outlines the development procedures for the different program types that DESQview/X supports and examines how these relate to the development of X Clients under DESQview/X.

DESQview/X supports the following kinds of applications: DOS text (regular DOS applications), DOS graphical (regular DOS graphical applications), DESQview API, Microsoft Windows and of course, X Clients. Most of these application types can appear as either real mode, 16-bit protected or 32-bit protected.

5.1 Real Mode Applications Development

In order to generate a real mode application, a developer will follow the traditional steps to produce an application:

First, all necessary source files are compiled using a regular DOS compiler to create real mode object files. Next, a regular DOS linker is used to link those object files with real mode library modules to produce a runnable application.

Often the compiler, linker and library modules are supplied by a single manufacturer as a complete package.

Library modules are available (sometimes from third party manufacturers) with graphic routines to produce a graphical application or Microsoft Windows routines to produce a Windows application.

5.2 Protected Mode Applications Development

To generate a protected mode application for DOS, a developer will require the use of a DOS Extender package and normally follows one of two paths.

5.2.1 Using a Protected Mode Compiler and Linker

If a protected mode compiler is used, it will generate protected mode object files. (Note that the words protected mode in the name protected mode compiler are referring to the kind of output the compiler generates, not the kind of program the compiler may be - it could actually be a real mode program or a protected mode program running under a DOS Extender!)

These protected mode object files are then linked with protected mode library files and DOS Extender modules to create a protected mode application that is runnable from DOS.

Typically the compiler, linker and library modules are supplied by a single manufacturer as a complete package.

As in the case of real mode applications, library modules are available (sometimes from third party manufacturers) with graphic routines to produce a graphical application or Microsoft Windows routines to produce a Windows application.

Note that a trend in protected mode compilers is to offer a DOS Extender as part of the compiler package, obviating the need to choose and purchase a DOS Extender separately.

Previously, there was not as big a selection of 16-bit and 32-bit protected mode development packages as there are today. To address this situation, many DOS Extender manufacturers supply an alternate route: using regular DOS compilers.

5.2.2 Using a Regular DOS Compiler

If a regular DOS compiler is used, this will create real mode object files. This may seem inconsistent, however real mode is very similar to 16-bit protected mode code, save for a few constraints. Note that if generating code for a 32- bit environment, using a regular (16-bit) DOS compiler will result in code that will not take advantage of the 32-bit architecture of the processor.

At this point either a regular DOS linker or a protected mode linker may be used. Whatever linker is used, it will typically link in real mode library routines and some protected mode modules as well in addition to the DOS Extender modules. The real mode library routines are ones supplied by the regular DOS compiler manufacturer that do not violate protected mode guidelines and hence may be used in a protected mode environment. Any library modules that do violate those guidelines are replaced by modules that have been rewritten by the DOS Extender manufacturers and are linked in as protected mode modules.

Sometimes it may be necessary to run a conversion program after the linking stage to create the final protected mode program.

Note that a need for protected mode linkers has become apparent because many regular DOS linkers have certain limitations when creating protected mode programs (since they were not designed to produce these kinds of programs).

5.2.3 DOS Extenders

In order for a protected mode application to run under DOS (or DESQview/X) it requires the use of a DOS Extender. A third-party DOS Extender may be used, though many compilers now supply their own DOS Extender and protected mode libraries. DESQview/X includes the DOS/4GX DOS Extender and the DESQview/X Development Kits (see later) supply the necessary protected mode libraries.

5.3 X Client Development for DESQview/X

Developing or porting X Clients to the DESQview/X platform requires a developer to follow the general steps outlined in the previous section.

Depending on the size of the resultant X Client, a developer will create either a real mode, 16-bit protected mode or 32-bit protected mode application. Typically, X Clients that are ported from another environment (usually Unix) will be implemented the easiest as a 32-bit protected mode application.

In order to create an X Client as opposed to a regular DOS or DOS Extended application, the X Client object files are linked with Xlib and/or Toolkit function libraries in addition to the usual program libraries.

5.3.1 DESQview/X Development Kits

The development kits that are (or will be) available for the development of X Clients in DESQview/X are:

includes XLIB, Xt Intrinsics, Athena Toolkit and sample X Clients.
add on to X11 Toolkit
add on to X11 Toolkit
Each development tookit includes different versions of the program libraries for use by particular compilers. The versions that are (or will be) available include:

OSF/Motif and OPEN LOOK libraries will not be supplied for use by real mode applications due to the size of their libraries.

Rational Instant-C is of interest in that it is an incremental compiler - it recompiles functions as they are changed to provide a fast development environment much like interpreted BASIC. For final code, however, a program should then be compiled with a fully-optimizing compiler such as Microsoft C.

This table is by no means exhaustive and is expected to change - check with Quarterdeck Office Systems for a list of compilers/program modes currently supported.

5.3.2 DOS/4GX Support

Because DESQview/X contains DOS/4GX DOS Extender technology, a separate DOS Extender is not required for use with the DESQview/X Development Kits. Compilers supported by the DESQview/X Development Kits produce code that is compatible with the DOS/4GX support.

6 DESQview/X Products

There are several products available in the DESQview/X suite of system software - base products, additional window managers, development kits and additional network manager product.

DESQview/X(for 386 PCs)

This product enables a single user to implement on a 386 processor (or better), the DESQview/X graphical environment system for running DOS, Microsoft Windows and/or DOS-based X Clients. In addition, remote computing facilities are provided so that the DESQview/X system can interact with other DESQview/X systems using either a Novell (IPX/SPX) or NetBIOS network. Specifically, a DESQview/X system may use remote DOS, Microsoft Windows or DOS-based X Clients on other DESQview/X systems as well as being able to transfer files.

It includes QEMM-386, Quarterdeck Manifest, the X Server product, the DESQview/X Window Manager (DWM), several graphical utilities (the DESQview/X Companions - Application Manager, File Manager, Icon Editor and Adobe Type Manager) and support software such as a Print Manager and DESQview/X to DESQview/X Network Manage for IPX/SPX and NetBIOS.

OSF/Motif Window Manager

An addition to the DESQview/X base product, the OSF/Motif Window Manager replaces the default DWM window manager to sport an OSF/Motif look and feel.

OPEN LOOK Window Manager

An addition to the DESQview/X base product, the OPEN LOOK Window Manager replaces the default DWM window manager to sport an OPEN LOOK style interface.

DESQview/X Network Manager - DESQview/X to Other X Systems

This network software product is an addition to the DESQview/X base product and enables a DESQview/X system to communicate with other X machines (DESQview/X or otherwise) over a variety of networks. Note that the DESQview/X base product includes support for NetBIOS and IPX/SPX (Novell) networks - this additional package delivers support for other network APIs such as PC/TCP (FTP Systems) and LAN WorkPlace for DOS (Novell) and includes a coupon for a free copy of Novell's TCP/IP Kernel for DOS. Since this list may change, check with Quarterdeck Office Systems for an up-to-date list of network APIs that DESQview/X supports.

Note that this package permits a DESQview/X system to communicate with other DESQview/X and X Window machines over a network. It is not a substitute for and does not replace the standard network software that is required to form a network.

DESQview/X X11 Toolkit

The DESQview/X X11 Toolkit enables developers to port existing X Clients to the DESQview/X platform or create new ones. This kit contains the X11 program libraries for all supported compilers (Xlib, the Xt Intrinsics, the Athena Toolkit) and sample X Clients. In addition, the kit includes the DOS/4GX Extender tools, Rational System's Instant-C and Oxygen utility, full printed documentation, and developer support from Quarterdeck Office Systems.

Check with Quarterdeck Office Systems for a list of compilers/program modes currently supported for this and other development kits.

DESQview/X X11 Library Kit

The DESQview/X X11 Library Kit is a less expensive version of the DESQview/X X11 Toolkit that does not include Rational System's Instant-C and Oxygen utility. In addition it only includes standard 90-day end user support from QOS.

DESQview/X X11 Starter Kit

The DESQview/X X11 Starter Kit consists of the GNU C/C++ compiler and GNU versions of the DESQview/X X11 Libraries (Xlib, Xt Intrinsics and Athena Widgets). In addition, minimal printed documentation is included that describes compiling X Clients as well as specific details on programming and configuring the DESQview/X environment. No documentation regarding generic X Window programming is supplied with this kit.

Even though this kit does not include the DOS/4GX Extender tools, 32-bit protected mode applications may be developed as the GNU compiler includes its own DOS Extender.

This kit is provided at a very competitive and inexpensive price and only includes standard 90-day end user support from QOS.

DESQview/X OSF/Motif Toolkit

An addition to the DESQview/X X11 development kits, the OSF/Motif Toolkit enables developers to create applications with an OSF/Motif look and feel. It consists of the OSF/Motif program libraries, the DESQview/X OSF/Motif Window Manager, Motif and DESQview/X Programming manuals at a very attractive price.

Check with Quarterdeck Office Systems for a list of compilers/program modes currently supported for this development kit.

DESQview/X Developer Passport Support

DESQview/X Developer Passport Support (included only with the DESQview/X X11 Toolkit and available separately) provides a year of special access to DESQview/X development support technicians and to the DESQview/X porting laboratories. The porting laboratories offer individual personalized assistance when porting to the DESQview/X platform or creating new DESQview/X applications. Two locations currently exist - Santa Monica, California and Chelmsford, England with more planned.


DESQview/X X11 Libraries for GNU C/C++

The GNU C/C++ versions of the DESQview/X X11 Libraries (Xlib, Xt Intrinsics and Athena Widgets) are available on Internet (anonymous ftp server, file (note '100' denotes version 1.00 - this can change) in directory /pub/msdos/djgpp) and from the Quarterdeck Office System BBS ((310) 314-3227). Note that the GNU C/C++ compiler is also available from Internet and the QOS BBS.

Even though this libraries do not include the DOS/4GX Extender tools, 32-bit protected mode applications may be developed as the GNU compiler includes its own DOS Extender.

These libraries are offered free of charge, but include no documentation or support from QOS.

Internet Downloading Instructions

FTP users:

File location:

       login:     ftp
       directory: ~ftp/pub/msdos/djgpp
Non-FTP users:

   % mail
   index msdos/djgpp


This document describes software that is copyrighted and all rights reserved by Quarterdeck Office Systems. Portions of the software are copyrighted by Adobe Systems Incorporated, Graphics Software Systems, Inc., Massachusetts Institute of Technology, Microsoft Corporation, Rational Systems, Inc.

This document is copyrighted and all rights reserved. This document may not, in whole or part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from Quarterdeck Office Systems.

(c) 1985-1994 Quarterdeck Office Systems, Inc. 1901 Main Street, Santa Monica, CA 90405 (310) 392-9701

All Rights Reserved U.S. Patent No. 4,125,873; Patent pending.


If this product is acquired under the terms of a DoD contract: Use, duplication or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of 252.227-7013. Civilian agency contract: Use, reproduction or disclosure is subject to 52.227-19 (a) through (d) and restrictions set forth in the accompanying end user agreement. Unpublished-rights reserved under the copyright laws of the United States. Quarterdeck Office Systems, Inc., 1901 Main Street, Santa Monica, CA 90405.


Writer: Mark Radcliffe
Cover design: Cynthia Ford
Production notes: This document was created electronically using
Ventura  Professional.


DESQ, DESQview, DESQview/X, Application Manager, DESQview/X File Manager, DESQview/X Icon Editor, Quarterdeck Expanded Memory Manager-386, QEMM-386, Quarterdeck Manifest, Manifest, Quarterdeck QRAM, QRAM, Quarterdeck Expanded Memory Manager 50/60 and QEMM 50/60 are trademarks of Quarterdeck Office Systems, Inc.

Adobe Type Manager, ATM, Postscript and Adobe are trademarks or registered trademarks of Adobe Systems Incorporated. AT&T and OPEN LOOK are trademarks or registered trademarks of AT&T. AutoCAD is a registered trademark of Autodesk, Inc. Clipper is a registered trademark of Computer Associates International,Inc. DEC is a registered trademark of Digital Equipment Corporation. DGIS is a registered trademark of Graphic Software Systems, Inc. DOS/4G, DOS/4GX and Instant-C are trademarks of Rational Systems, Inc. FrameMaker is a registered trademark of Frame Technology Corporation. Helvetica and Times Roman are trademarks of Linotype AG and/or its subsidiaries. High C is a registered trademark of MetaWare Incorporated. IBM, PC, PC-DOS, Presentation Manager, NetBIOS and OS/2 are trademarks or registered trademarks of International Business Machines Corporation. Intel, 386 and 486 are trademarks of Intel Corporation. Lotus and 1-2-3 are registered trademarks of Lotus Development Corporation. Macintosh is a registered trademark of Apple Computer, Inc. Microsoft, MS, MS-DOS, XMS, Word and Microsoft Windows are trademarks or registered trademarks of Microsoft Corporation. Novell, Netware, DR DOS, GEM and LAN WorkPlace for DOS are trademarks or registered trademarks of Novell, Inc. OSF/Motif, OSF and Open Software Foundation are trademarks of the Open Software Foundation, Inc. Paradox, Dbase and Borland C++ are trademarks or registered trademarks of Borland International,Inc. PC/TCP and FTP Software are trademarks or registered trademarks of FTP Software, Inc. SunView is a trademark of Sun Microsystems, Inc. Unix is a registered trademark of AT&T in the U.S. and other countries. Ventura Publisher is a trademark of Xerox Coporation. Watcom C is a trademark of Watcom, Inc. WordPerfect is a registered trademark of WordPerfect Corporation. X Window System is a trademark of the Massachusetts Institute of Technology. Zortech is a trademark of Symantec Corporation. Other brand or product names are trademarks or registered trademarks of their respective holders.