\chapter{Comparison with other versions}
\section{Portability and sharing}

The language implemented by \gpm\ is identical among the various 
implementations. That is to say, exactly the same programs should
compile and run on any version of \gpm. This chapter describes any 
limitations to the sharing of files among different implementations,
and points out where libraries differ in some detail.

For those who are working with heterogeneous networks of machines,
it may be important to know about the limitations of this portability.
In particular, some files may be shared among different implementations
while others cannot.

\subsection*{Portability of data files}
All versions of \gpm\ which use the same byte packing order and word-size are 
able to share data files.  The following versions of \gpm\ use 
{\em little-endian\/} byte packing: {\em DECstation ULTRIX/RISC}, all 
{\em Intel 386/486\/} versions,
and {\bf gpm-pc}.  All others implementations (including non-{\em DEC\/} 
versions using the {\em MIPS\/} processor) use {\em big-endian}
byte packing. 

If regions of program data memory are written to files in image mode, the 
files may not
be portable even between versions with the same endian-ness.  This is because
different machine architectures demand different alignment of objects in 
memory.  

\subsubsection*{Big- and little-endian}
Suppose a four byte integer is stored in memory. The location is necessarily
on a four-byte boundary, even for versions of \gpm\ where the machine 
architecture does not insist on such an alignment. 
If the address of the location is cast to the type {\em POINTER TO CHAR}
and the value extracted on big-endian machines the most significant byte
(the big end)
of the integer will be returned, while on little-endian machines the 
least significant byte (the little end) will be returned.

It should be noted that {\em all} versions of \gpm\ pack sets so that
bit-0 is at the least significant end of the word. Thus on all implementations
it is true that
\[\makebox{{\em BITSET\/}\{0\}} = \makebox{{\em SYSTEM.CAST\/}({\em BITSET},1)}\]

\subsubsection{Big-endian (Sparc, and non-DEC Mips processors)}
\begin{center}
\begin{picture}(200,40)
\put(0,25){\framebox(50,15){high byte}}
\put(50,25){\framebox(50,15){}}
\put(100,25){\framebox(50,15){}}
\put(150,25){\framebox(50,15){low byte}}
\thicklines
\put(25,10){\vector(0,1){15}}
\thinlines
\put(25,5){\makebox(0,0){\bf word address points here}}
\end{picture}
\end{center}

\subsubsection{Little-endian (DECstations, Alpha and Intel 486)}
\begin{center}
\begin{picture}(200,40)
\put(0,25){\framebox(50,15){high byte}}
\put(50,25){\framebox(50,15){}}
\put(100,25){\framebox(50,15){}}
\put(150,25){\framebox(50,15){low byte}}
\thicklines
\put(175,10){\vector(0,1){15}}
\thinlines
\put(175,5){\makebox(0,0){\bf word address points here}}
\end{picture}
\end{center}

Non-text files are not usually sharable between little- and big-endian 
versions.  Despite this, it is possible to write code which does read and
write portable binary files, and this technique is used within the compiler
itself. In effect the program must determine the endian-ness of its host
machine, and repack the bytes it reads correspondingly.

\subsection*{Definition and symbol files}
All non-foreign definition modules are identical for all versions of
\gpm\ in the current release cycle. Certain foreign definitions are 
slightly different because of the different facilities provided by
the underlying {\em UNIX} implementation. In all cases, these differences
do not affect the users of the module, but do mean that these 
definition and symbol files cannot be shared.

For this implementation the following differences are known
\begin{itemize}
\item in general, foreign implementations written in C language
	are not portable between {\em ANSI-C} and traditional
	{\em C} environments. This is because of the necessary
	use of function prototypes in {\em ANSI} versions.
\end{itemize}


\section{X-windows and gpm}
The simple interface to the C libraries
make it a simple matter to use the language C bindings to X-lib
for programs written in Modula.
However, the facilities of X-lib are so enormous in their scope 
that is difficult to decide on a simple subset to offer as a ``standard
interface'' to Modula.

This release contains a number of X-windows demonstration programs.
These include a number of interface definition modules which may be
used as is, or cut and pasted at will.
The development team are not yet ready to commit themselves to freezing
these definitions, so no guarantee is given that the next release will
be the same.

We would welcome feedback and suggestions for improvement 
on these aspects of the libraries.

Most of the graphics demonstration programs are copyright \copyright
1985 -- 1990 Raoul Gough. They are supplied for demonstration purposes
and may be used, copied or modified provided that the 
copyright notice in the source text remains intact.

