🚀 go-pugleaf

In article <1583@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes:

> In article ... edward@ga.ecn.purdue.edu (Edward L Haletky) writes:
> > 1) Several software house have ported X to various PC's.
> 
> > 2) X is a unixed based program. [ It runs on the PC under UNIX ]
> 
> > 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.)
> 
> That's one way of saying it. You also need an operating system to support
> all the UNIX calls (like fork()) or else you need to do more or less a
> complete rewrite to jam it into a device driver.

The software houses that are offering "X on a PC" are actually offering
X *servers* on a PC.  As far as I know, nobody offers X clients on a PC.
While it would be possible to run one client at a time on a PC, talking
to a server on another, such a stunt strikes me as just that -- a stunt.

The so-named "sample server" delivered on the X release tape has *all*
OS-dependent system calls collected in a few modules in a single directory
named "os/4bsd".  None of these calls are particularly UNIX-specific.  The
server has no reason to fork, exec, or anything like that.  Mostly it opens
and closes files and network connections.  There is no need to use a fancy
C library, nor to jam the whole thing into a device driver.  The hardest
part is getting rid of all of MIT's 32-bit assumptions so the thing can run
on the 16-bit 286.  The second hardest part is writing, porting, or interfacing
the so-called "device-dependent" code so that it will drive an EGA or whatever.
The changes needed to convert "os/4bsd" to "os/dos" are quite minor by
comparison.
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff