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.

Definitions

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.

DESQview/X:

   Is a third DESQview (DESQview, DESQview 386 and now
   DESQview/X), adding distributed graphics and remote computing
   capabilities to Quarterdeck's multitasking DOS environment.

   Brings the X Window System to DOS thereby enabling DOS users to
   participate in the many graphical and multimedia advances available
   today only on workstation platforms.

   Allows DOS PCs to participate in industry standard, multivendor,
   multi-operating system, distributed processing (cross-platform
   computing).

   Supports the latest advancements in font technologies and advanced
   memory management.

   Provides printer spooling for DOS PCs as well as remote printing
   capabilities for Unix X Window workstations and other DOS PCs.

   Gives users of Unix X Window workstations access to many off-the-
   shelf DOS and Microsoft Windows software packages.

   Gives DOS users access to Unix X Window workstations or mainframe
   programs (Clients).

   Gives DOS users access to Unix text-based applications (using xterm).

   Gives DOS users access to more powerful DOS and Microsoft
   Windows programs that are not capable of being run on their own
   machine.

   Promotes DOS to that of a multiuser system through its remote
   execution and security features.

   Provides file transfer capabilities between DOS and Unix or other
   DOS machines on a network.

   Provides developers with an industry standard open, graphical
   development environment and choice of user interface.

   Supports industry standard methods for application programs to
   communicate across a network (Inter Process Communications),
   regardless of the network type.

   Provides X Client developers and manufacturers access to the huge
   installed base of DOS machines.

Specifically, it:

   Runs either stand-alone or as a networked system.

   Adds a graphical 3D look and feel to DESQview.

   Provides a growth path from character mode DOS to industry
   standard graphical user interfaces.

   Gives users a choice of interfaces (window managers) - the
   DESQview/X, OSF/Motif or OPEN LOOK interfaces are prime
   examples.

   Dynamically scales the windows of DOS text applications to any size
   (scalable DOS windows), from just a few pixels to full screen, using
   scalable font technology.

   Can run applications up to 16MB (16-bit protected mode) or 4GB
   (32- bit protected mode) by supporting the use of 16-bit and 32-bit
   DOS Extenders.

   Supports the use of virtual memory and dynamic link library
   technology to drastically reduce the amount of memory needed to run
   large application programs.

   Incorporates the Adobe Type Manager and scalable font technology
   giving X Clients access to the vast array of Adobe Type 1 fonts.

   Allows users to run many off-the-shelf DOS and Microsoft Windows
   applications in windows side-by-side with local or remote X Window
   Clients.

   Incorporates a Print Server that can handle print requests from
   remote machines (both DOS and Unix) connected on a network, while
   spooling to a printer.

   Allows local users to display and use many off-the-shelf DOS and
   Microsoft Windows applications that are running on another machine
   on a network.

   Allows local users to display and use Unix graphical applications (X
   Clients) that are running on another machine on a network.

   Allows local users to display and use Unix text-based applications that
   are running on another machine on a network (using the xterm
   program).

   Allows local users to display and use DOS Clients written for X
   (graphical applications) that are running on another machine on a
   network.

   Allows X Window Unix users to display and use many off-the-shelf
   DOS and Microsoft Windows applications that are running on another
   DOS machine on a network.

   Provides a multiple level security feature to restrict access to a
   machine by other remote machines.

   Implements the File Transfer Protocol (FTP) for the peer-to-peer
   transferring of files to remote machines (DOS or Unix).

   Gives developers a choice of application styles - OSF/Motif, OPEN
   LOOK and others - or the freedom to design their own.

   Implements a printer imaging model that mimics X Window System
   display output so that X Clients need only support a single imaging
   model for both display and printer output, greatly simplifying the
   coding of X Clients.

   Implements the Berkeley Socket interface, providing Inter Process
   Communications between separate applications (on the same machine
   or even across a network) that is independent of the underlying
   network type.

   Provides developers a platform to port X Clients from Unix to DOS.

   Allows developers to create X Clients in a DOS environment for later
   porting to other operating systems using the X Window System.

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 
   DESQview-oblivious programs are ones that know nothing about
   DESQview - this includes programs like Lotus 123, Microsoft Word or
   AutoCAD.

DESQview-aware 
   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.

DESQview-specific 
   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.

FrameMaker 
   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.

Xterm 
   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.

X11

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:

DWM 
   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!

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

OPEN LOOK 
   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 
   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 
   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.

   If a 16-bit protected mode application is required, then a compiler and
   linker capable of handling 16-bit protected code must be used as
   should 16-bit protected library modules.

   For a 32-bit protected mode application, a compiler and linker
   capable of handling 32-bit protected code must be used as should
   32-bit protected library modules.

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:

X11 
   includes XLIB, Xt Intrinsics, Athena Toolkit and sample X Clients. 
OSF/Motif 
   add on to X11 Toolkit 
OPEN LOOK 
   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.

   Contact Quarterdeck Office Systems Customer Service at (800)
   354-3222 for a complete list of products and services offered as well as
   current list prices.

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.

   Note that many components of the DESQview/X Development Kits
   (including developer support) are available separately - please contact
   Quarterdeck Office Systems for a complete list of products/services
   and current list prices.

FREE EVALUATION DEVELOPMENT KIT

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 barnacle.erc.clarkson.edu, qddvx100.zip 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:


       host:      barnacle.erc.clarkson.edu
       login:     ftp
       password:  
       directory: ~ftp/pub/msdos/djgpp

Non-FTP users:


   % mail archive-server@barnacle.erc.clarkson.edu
   Subject: 
   help
   index msdos/djgpp
     

COPYRIGHT

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.

U.S. GOVERNMENT RESTRICTED RIGHTS

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.

CREDITS


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

TRADEMARKS

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. 

