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.
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.
Note that for the remainder of this document, all references to
EMS 4.0 memory are also applicable to EEMS memory.
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.
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.
Note: DESQview/X version 1.0 does not support DOS
program swapping.
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.
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.
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.
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.
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.
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.
All 486 processors are functionally equivalent (save for
math functions) and are referred by the 486 moniker for the rest
of this document.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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:
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.
A Widget Set uses both function calls in the Intrinsics
as well as Xlib.
The Athena, OSF/Motif and Olit
Toolkits consist of a Widget Set and the first Intrinsics
to be developed for X - 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.
The current revision of these distribution tapes is the X version
11 release 5 of the X Window System, otherwise
known as X11 R5.
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.
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.
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).
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.
Because of this, a Microsoft Windows session
can appear within a resizeable DESQview/X window alongside other X
Client windows.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.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.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).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.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.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).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.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.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.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).2.12 Application Types
There are three types of applications that exist in the DESQview
multitasking environment: DESQview-oblivious,
DESQview-aware and DESQview-specific.
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.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.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.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.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.
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.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.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.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.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.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.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.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.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.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.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.
*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.
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.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.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).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.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.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.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.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.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.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.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.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.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:
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.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.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.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!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.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).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.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.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.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.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.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.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.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.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.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.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.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.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.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.4.10 Stand-Alone or Networked?
DESQview/X may be run either as a stand-alone
system or networked.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.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:
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.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: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!)
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.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.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.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:
Each development tookit includes different versions of the program
libraries for use by particular compilers. The versions that are
(or will be) available include: