edward@ga.ecn.purdue.edu (Edward L Haletky) (03/09/88)
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).
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.)
Good-Luck to any one who wants to port.
===================================== ^ =================================
Edward L. Haletky |E |o| U| "To race against the sky..."
Usenet: ~!pur-ee!edward |L ^/| |\^ S| "The world of the
Arpa: edward@ga.ecn.purdue.edu |H / | | \ A| immagination is boundless."
=====================================/__-|-__\=================================jg@jumbo.dec.com (Jim Gettys) (03/10/88)
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
peter@sugar.UUCP (Peter da Silva) (03/18/88)
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. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
geoff@desint.UUCP (Geoff Kuenning) (03/23/88)
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
tada@athena.mit.edu (Michael Zehr) (03/25/88)
Sorry to have to subject the net to this question again, but my handy on-line list of sources for PC X software got trashed. Could someone plese e-mail me a list? Thanks in advance. ------- michael j zehr "My opinions are my own ... as is my spelling."