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.
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.
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.
Check with Quarterdeck Office Systems for a list of compilers/program modes currently supported for this and other development kits.
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.
Check with Quarterdeck Office Systems for a list of compilers/program modes currently supported for this development kit.
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
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.
Writer: Mark Radcliffe Cover design: Cynthia Ford Production notes: This document was created electronically using Ventura Professional.
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.