larsp@daimi.UUCP (01/09/87)
Has someone used the MIT X window-system ?? Before choosing X for a devolopment-system, I would like to hear some comments about X. -- Lars Bak Petersen AArhus Universitet Denmark UUCP: larsp@daimi.UUCP
ghemawat@svax.UUCP (01/18/87)
I have been using X for two or three months. Advantages: 1) Easy to write window based applications - provides a very simple interface. 2) Works over a network, so you don't have to run your applications on a workstation. 3) The window system has been implemented on a large number of different workstations (including VAXStations, IBM RT's, SUN's, ...). In a recent draft, one of the designers of X said that X had been ported to more hardware than any other window system he was aware of. 4) You are not tied down to a particular window manager - the guy who moves your windows around, resizes them... There are several window managers in the distr. and you can write your own if you want to. Disadvantages: 1) It might be slow at times because all window system calls are routed to the server through a socket (on unix). 2) At the moment, there is no standard toolkit for things like buttons, scrollbars, etc. However, Version 11 of X (due in March) is supposed to provide an extensible toolkit containing objects like buttons, scroll bars, labels, menus, edit-windows... 3) Security is not enforced very strictly. The server maintains a list of hosts from which it can accept connections. Any user on any of these hosts can connect to the display. V 11 will provide hooks for implementing more security. 4) It does not provide 3D primitives. 3D primitives will also be absent from V 11, but a facility will exist for extending V11 X, so interested parties should be able to write their own 3D extensions to X. There is a mailing list for X windows (requests for addition should be sent to xpert-request@athena.mit.edu). You might want to hold out on this, because they are thinking of starting a newsgroup and discontinuing the mailing list. -Sanjay Ghemawat (ghemawat@wrath.cs.cornell.edu) Cornell University
berger@datacube.UUCP (01/20/87)
How hard is it to port X to non-unix environments?
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: ihnp4!datacube!berger
{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!bergerjim@ci-dandelion.UUCP (Jim Fulton) (01/21/87)
> How hard is it to port X to non-unix environments?
For the server code, it depends on how easily you can emulate select(2). If
you can do that (including providing a way for it to be woken up by the
network and by the input device) then you should have relatively few problems.
This is what enables the server to efficiently wait for input from any client
on the network or from the tablet or mouse. If your server doesn't have to
share the machine with any other processes then polling will work; but if
you're using a multitasking machine a "real" select is pretty important.
For those who are interested I have a note that I sent out to the XPERT and
XPORT mailing lists describing PC/X, our port of X10 that runs on a PC/AT
under MS-DOS using a 1280x1024 Hitachi ACRTC-based graphics card. Send me
mail and I'll forward it on to you.
Jim Fulton
Cognition Inc.
900 Tech Park Drive
UUCP: ...!{mit-eddie,talcott}!ci-dandelion!jim Billerica, MA
ARPA: fulton@eddie.mit.edu, jim@athena.mit.edu (617) 667-4800root@sbcs.UUCP (Root) (01/22/87)
> > How hard is it to port X to non-unix environments? > > Bob Berger > > Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960 I'm busy porting X to the Commodore Amiga, and generally finding it not too difficult. The server part of the implementation tries, by design, to make minimal use of Unix system calls. All one generally has to do to retarget the environment is deal with Unix'ish calls such as socket(), fstat(), fopen(), etc, which are most probably similar in principle to the OS calls available in the target environment. As for the graphics interface portion of the server, porting is generally facilitated if the target machine has some concept of graphics primitives, e.g. ability to draw a (textured) line, block copy one rectangular area to another on the screen would be just fine. If you also want to port the client part of X, namely the ultilities such as xterm, xperfmon, xlock, xdemo, etc, GOOD LUCK! They can be very Unix specific (e.g. xperfmon needs to trot around in /dev/kmem). My application requires only the server part of X on the Amiga, so I will not port most of the client code.. BTW, my final resolution on porting X onto the Amiga was to try to produce as Unix like environment as possible, since it eases the conversion problems, and makes it easier to upgrade things to V11 in March. Hope some of this helps, Rick Spanbauer
jpm@calmasd.UUCP (01/24/87)
In article <275@ci-dandelion.UUCP>, jim@ci-dandelion.UUCP (Jim Fulton) writes: > > How hard is it to port X to non-unix environments? > > For the server code, it depends on how easily you can emulate select(2). If > you can do that (including providing a way for it to be woken up by the > network and by the input device) then you should have relatively few problems. We have implemented a server-based user interface toolkit, originally under 4.2 BSD with ports to VMS and Apollo. The crux of the problem in porting servers in general is exactly as Jim describes - emulating the UNIX select call. We found ways of doing this in both VMS and Aegis by using native system facilities. Actually, this whole problem should be trivial if the non-unix O.S. people would simply include the select call in their C system libraries. All the other usual (UNIX) system calls are present (open, malloc, etc.), but not select - in my opinion a major omission. I would also like to point out that the select call was not our only portability problem. User interface tools have to deal with things like windows and graphics and these CAN be major portability problems (but not when X and XLib become the universal standard!). But then, these are not strictly O.S./Unix issues and don't relate to the original poster's request... However, the original requestor is advised to consider the display end of things when porting X to non-unix environments. If your display hardware can't do the things that X expects at that level, you could have big problems... -- John McNally GE/Calma 9805 Scranton Rd. San Diego CA 92121 ...{ucbvax | decvax}!sdcsvax!calmasd!jpm (619)-587-3211