Xref: utzoo comp.sys.ibm.pc:14030 comp.graphics:2134
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!jumbo!jg
From: jg@jumbo.dec.com (Jim Gettys)
Newsgroups: comp.sys.ibm.pc,comp.graphics
Subject: Re: X on IBM PC
Message-ID: <2294@jumbo.dec.com>
Date: 10 Mar 88 01:14:35 GMT
References: <347@ga.ecn.purdue.edu>
Reply-To: jg@jumbo.UUCP (Jim Gettys)
Organization: DEC Systems Research Center, Palo Alto
Lines: 60

In article <347@ga.ecn.purdue.edu> edward@ga.ecn.purdue.edu (Edward L Haletky) writes:
>
>Okay,
>
>My mail box is getting full of letters from people who are requesting the
>same information. Here is what I have found out.
>
>1) Several software house (mentioned in previous articles) have ported
>   X to various PC's.
>
>2) X is a unixed based program. In order to run it on a PC you would most
>   likely need to be running a unix system. (Minix, Xenix, Unix PC may
>   be adequate.) X makes unix system level calls. You would also need lots
>   of disk space to hold the X system. Plus lots of memory. A virtual
>   machine is the best bet (386, 68020 boxes).

Ultimately, X is a network protocol, not a specific implementation.
People are indeed working on other implementations other than the "sample
server" on the MIT distribution.  Lisp implementations have also been
done for LispM environments.

The sample server implementation was very carefully designed not to
be Unix dependent; all of the OS dependencies are fully isolated in the
implementation.  In fact, this server has been ported to other systems
than Unix, VMS for example (look at the VAXstation 8000 announcement
made in January).  The VS8000 development group on VMS kept within a week or
so of the Unix development; they kept us reasonably honest.

X performs relatively few system calls; read and write (preferably,
but not necessarily non-blocking), select (or poll in the System V world)
are the major ones.

The only piece of the distribution particularly Unix dependent is the
terminal emulator, by nature somewhat OS dependent.

Porting the server only to MS-DOS is straightforward, as the various
commercial implementations suggest (the biggest problem is a reasonable
network transport).  The server plus clients in 640 k would be
a serious problem.  We implemented the sample server often trading
memory for speed, which was a conscious design decision, though much
could be done to make it smaller.  With the time constraints on the
sample server implementation, we did not have extra time to do work
to make it smaller while preserving speed.  (For example, some internal server
data structures could be shared in the window heirarchy, at the cost of
some additional code complexity, but no performance penalty).

By far the biggest issue on a PC is getting a good multiconnection
network transport, not X itself.  There are kludge arounds for this,
but they are hackish enough not to mention here.

>
>3) To port such a beast to a PC would require C compiler that can handle
>   all the Unix system calls. I do not know one that can. (possibly MSC.)
>

As stated above, X makes very few system calls, not "all the calls", and
they are well isolated.
				Jim Gettys
				Digital Equipment Corporation
				Systems Research Center