The World of Computer Software/World_Of_Computer_Software-02-387-Vol-3of3.iso/p/portclnt.tec

Text File | 1993-03-21 | 9KB | 177 lines

ID:XC Porting X Window System programs to DESQview/X
Quarterdeck Technical Note #262
by Brian Cunningham
Last revision:  24 September 1992

INTRODUCTION

The following technote was written to help those who are somewhat familiar
with X Window programming determine what tools they will need to port X Window
applications to the DESQview /X environment.  For an introduction to X Window
programming, see the "Introduction to Writing X Window Clients" technote
available from Quarterdeck as well.

AN OVERVIEW OF THE X WINDOW SYSTEM

It is important to realize that the X Window System is nothing more (nor
less!) than a system-independent GRAPHICS standard.  It is NOT a computer-
independent OPERATING SYSTEM standard.  Especially in terms of disk access,
memory allocation and multitasking, each operating system is different - even
when the X Window System is running.  Because this is true there are many
reasons that programs will or must contain code that won't work at all on
another type of system.

From the perspective of an application programmer, X Windows is a collection
of pre-written program elements (called "libraries") that can be used in any
program when graphics need to be manipulated.  X Windows also accepts user
input specifying the location of the display hardware (this control is not
part of an application, however, so the application programmer does not need
to write code to handle this type of user input).  Since user input - from
either a keyboard or a mouse - is usually required to work with information
displayed on the screen, the X Window System also provides standard libraries
for responding to input activity as well.

Although the X Window System can be found on many computers, it is currently
most common on Unix machines.  As a result, the following two porting
scenarios are both related to porting X Window programs (called "clients")
from Unix to DOS.  There will be similar operating system specific issues to
address when porting X Windows clients to DESQview/X from ANY other operating
system (e.g., MacIntosh or VMS based X Window clients).

EXAMPLE ONE - MULTITASKING

In a program written for a Unix machine, each part of a program can run
independently of the rest of the program.  These "parts" are called processes.
No matter which program is responsible for starting a process each process
will be stored in a queue by the operating system.  Thus the operating system
determines how much time to give a particular program based on how many
separate processes it has in the queue, as well as what priority each of those
processes have been assigned.

The command that is used to run a process is "fork".  In Unix programs,
processes are "forked" all the time.  Unfortunately, there is nothing even
remotely similar to "fork" in DOS.

In a single-tasking operating system, like DOS, there is no queue.  Whatever
program is running has complete control of the processor and is responsible
for running any subprograms that it needs, each of which will control the
processor entirely until it finishes.

Multitasking in the DOS environment is basically a matter of switching whole
programs in and out of the one megabyte DOS limit and then giving the programs
some fixed amount of processing time while they are there, even if they don't
need to do anything at all at that time!

This implies, of course, that programs that are ported from Unix to DOS must
have all commands that attempt to run separate processes removed.

Although this is normally true, DESQview/X, which has the multitasking
features of DESQview built in, allows a programmer (in SOME cases) to replace
the "fork" command with the app_start() function from the DESQview API (A
library of DESQview-specific multitasking functions).

To decide whether references to separate processes should be removed or
modified when porting to DOS it will be important to become familiar with the
DESQview API documentation.  The documentation describes the purpose and
function of each API call in detail.

EXAMPLE TWO - MEMORY

Using and allocating memory is another area where Unix and DOS environments
differ.  Unix systems use what is known as a "flat" memory model.  That is,
the memory is all of one type and linear.  Memory, if present, is simply
allocated when needed.

With a DOS machine the situation is quite different.  No matter how much
memory is physically installed in the system, DOS limits the executable
program size to one megabyte or less.  Furthermore, in a DOS machine,
addresses between 640k and one megabyte are normally used by hardware and,
potentially, by programs such as device drivers and TSRs (programs that stay
resident in memory after terminating, often re-activated using a program
specific key combination).  Thus the effective maximum size of an application
is usually 640k MINUS the space used by DOS and any device drivers and TSRs
that are too large to load between 640k and one megabyte.  DOS uses anywhere
from 20k to 80k.

DESQview/X and network drivers will also consume memory inside the one
megabyte limit.  Therefore it is a good idea to make a program as small as
possible.  Inside DESQview/X, on a networked computer, the program space may
sometimes be limited to less than 450k (although a typical system will usually
have 520k to 580k of conventional memory free).  Generally users will be able
to increase their window size to a certain extent by following the procedures
outlined in MAXWINDO.TEC, a technote available from Quarterdeck.  Since there
are programs that require  more than 450k of RAM, various methods are used to
access more than the first megabyte of address space.

1) Replace DOS

DOS Extenders allow 32-bit programs to use many megabytes of RAM for the
program space.  The extender is incorporated into the program rather than into
DOS.  Using a DOS extender allows a program to be ported to DOS without
worrying about altering its memory model (there are some special
considerations, however, but the details are specific to the brand of DOS
extender and will only be found in the documentation for such a product).
Using a DOS Extender is generally the simplest way to port large, 32-bit
programs to DOS.

2) Use expanded memory

A memory device can be added to a DOS system that is capable of both
controlling a number of megabytes of memory, as well as swapping the contents
of that memory in and out of a 64k address range inside DOS's one megabyte
limit.  This device is known as an expanded memory board.  Because the memory
that contains a running program must be contiguous (i.e., sequential) and
entirely inside the one megabyte DOS limit, expanded memory boards are not
capable of running programs.  They can, however, be used for storing large
quantities of data.  A programmer should be aware of this kind of memory only
when the program being ported is small (500k or less) but uses a large data
space.  In this case the programmer may wish to use expanded memory simply
because there are so many systems with this type of memory board installed.

Also, expanded memory hardware may be emulated by a special program called an
"expanded memory manager" on 80386 and i486 based machines.  Quarterdeck's
pioneering expanded memory manager, QEMM-386, is an integral part of
DESQview/X.  Thus expanded memory is available to every program that is
running inside of DESQview/X.

WHAT YOU WILL NEED TO LEARN

If you really want to port programs from Unix to DOS (and vice versa), you
will need to become familiar with writing programs from scratch for both
environments.  Only by studying DOS programming will it become clear how to
modify existing Unix programs.

To become proficient in DOS programming, especially as this relates to writing
DESQview/X programs, you will need quite a bit of information.  If you already
know how to write X Window system programs in C then you will need to read the
following as well.

C Compiler Manual - DOS based

DOS Extender Manual

A DOS programming guide

DESQview API Documentation

DESQview /X X11 Toolkit Documentation

CONCLUSION

As a final note it should be mentioned that it IS possible to write a program
that can be ported EASILY from Unix or other non-DOS X/Windows systems to DOS.
Programs like Xeyes that use no operating system specific code can be ported
in a matter of minutes - as long as the C compiler and DOS Extender elements
are all in place.  Using only ANSI C standard library calls and standard X
Window library calls will make simple porting a reality.  If your goal as a
programmer is to write portable code, then using standard C library calls,
rather than operating system or hardware specific code, should be your normal
practice.

  ************************************************************************
  *          Trademarks are property of their respective owners.         *
  *This technical note may be copied and distributed freely as long as it*
  *is distributed in its entirety and it is not distributed for profit.  *
  *          Copyright (C) 1992 by Quarterdeck Office Systems            *
  ************************ E N D   O F   F I L E *************************