pat@tifsie.UUCP (04/10/87)
A while ago, I posted a request for information about X on MS-DOS. There seemed sufficient requests to warrant posting this summary. This represents the 'meat' of what I received. The "I'm interested too" mail/postings have been edited out. One posting was retracted by its author. Postings/mail are separated by lines of '=' characters. Several items have been edited to remove unnecessary material. All items contain mail addresses of the originator. Thanks to everyone that responded. I now have some idea of what I'm talking about (probably just enough to be dangerous). ============================================================================== Date: Wed, 25 Mar 87 06:36:13 cst Subject: Re: X on MS-DOS? I would appreciate it if you could copy me on any data you get. A neighbor of ours (Cognition) has done a port: I'm awaiting details. I quote: ---------------------------------------------------------------------- >From jim@ci-dandelion.UUCP (Jim Fulton) Wed Jan 21 15:24:48 1987 Path: hinode!eagle_snax!decvax!wanginst!ulowell!ci-dandelion!jim From: jim@ci-dandelion.UUCP (Jim Fulton) Newsgroups: comp.graphics Subject: Re: Using MIT X window-system Message-ID: <275@ci-dandelion.UUCP> Date: 21 Jan 87 20:24:48 GMT References: <502@daimi.UUCP> <102300001@datacube> Organization: Cognition, Inc., Billerica, Ma. Lines: 20 Summary: Porting X to non-Unix systems > 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-4800 --------------------------------------------------------------------- We are interested in supporting both X and NeWS servers on PC's using the network libraries we've developed for PC-NFS. Since we think that X is likely to be supported on the kind of systems which support NFS (Sun's, VAXen, Crays, etc.), there seems to be a good match here. We have no firm product plans as yet (i.e. don't quote me), but it all seems comfortingly logical..... [content-free messages need no disclaimer. is this content-free? who knows] Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS) UUCP: {ihnp4,decwrl,...}!sun!garnold <OR> decvax!eagle_snax!geoff ============================================================================= Date: Wed, 25 Mar 87 06:36:26 cst Subject: Re: X on MS-DOS? Yes, we at least have been working with X under MS-DOS. I've included a blurb I sent to various people describing some of the more interesting aspects of our X.V10 server that runs on an AT with a special hires (1280x1024) 4 plane board. Our work has just been on building a server that other machines on the network use as a display engine rather than an X replacement for MS-Windows. If you're interested in running MS-DOS applications locally under X you probably want to talk to the people at Locus Computing (try sending mail to Greg Coleman, gregc@locus.ucla.edu); they have such a beast for Merge 386. I suspect that you would have a fairly hard time writing this for a 286 running plain MS-DOS since it would probably have to be implemented as a fairly device driver. If you have further questions about PC/X, please feel free to call or send me mail (address down below). Jim A Description of Cognition Inc.'s PC/X (stuffing an elephant into a breadbox) -------------------------------------- Cognition Inc. has implemented X.V10 on the IBM PC/AT under MS-DOS. For the record, PC/X is only sold as part of our Mechanical Advantage product line (a fully integrated MCAE - Mechanical Computer Aided Engineering - system for doing conceptual design) and is not available as a separate product. This description is solely intended as a way to share our experiences with other members of the X community. Over the last year Cognition Inc. has developed a full TCP/IP-based multi-client server for the X10 protocol. It uses a high resolution (1280x1024 or 1024x768) color graphics card (4 planes) designed around the Hitachi ACRTC, the usual 3com Ethernet card, a meg or two of Expanded Memory, and a variety of tablets and mice. It understands the standard font format (using Expanded Memory to store the strike bitmaps so that it can handle really big fonts) and implements 98% of X.V10R3 (drawfilled, splines, getting XY-format pixmaps are missing mostly because we haven't needed them yet and they aren't supported in hardware) plus extension packages for doing sophisticated dynamic feedback, menus, etc. to support our product's user interface server. Most of the work was concentrated in the following areas: 1. getting the ddX code to make the graphics card jump through hoops. 2. generic support for input devices so that a minimum of interrupt code is needed to attach a new mouse or tablet. 3. developing a multi-connect TCP/IP and 4BSD emulation library. The graphics board that we are using is very fast at drawing single-width lines, adequate at doing region fills/copies/etc., and leaves something to be desired in pattern fills. In terms of overall performance, PC/X is roughly comparable to the QVSS and is actually a little faster in vector and solid region-fill applications. Given what we have to work with and that we're using color rather than monochrome, we're pretty pleased with PC/X. We've found that being able to quickly try out different types of input devices (tablets and mice in our case) is very useful. One of the few advantages of using DOS is that it is easy to add new interrupt level code without having to touch any of the operating system. Since load our interrupt handlers at run time, sharing the event queue between the server and the device drivers trivial. An implementation of select that can be woken up by the various interrupt handlers allows us to directly use most of the network code provided with the standard server. Getting the network to run fast enough and to emulate 4BSD was the hardest part of the port. Our TCP/IP currently supports up to 16 clients, and we can now write network applications that compile and run under Ultrix as well as MS-DOS with almost no source changes. PC/X has made use of this several times as more sophisticated versions of Read_segment and Write have been developed. In addition to using ethernet, we have experimented with serial line versions of PC/X (talking SLIP to a vax acting as a gateway). Although the idea of running X over modems sort of boggles the mind (we found that we really needed to get an effective throughput of up near 19.2kb for things to run adequately) it's useful for debugging graphics, a nice demonstration of modularity, and fun to watch. This was the 2 1/2th port of X that we have done (the 1/2 represents an earlier PC/Hitachi port that we did as a prototype and started replacing in April 1986) and was undoubtedly the most interesting. Working around compiler bugs (large model compilers are still a little flakey esp. when dealing with task stacks allocated off the heap), coping with the program and data size (including our 60k bytes of extension code there is currently around 275k of code, 40k of static data, and a fair amount of stuff allocated out of the heap) and debugging the sucker have definitely been an exercise in creativity. The lesson we learned was that X is a nice match for small machines as well as large. With an adequate graphics board and a reasonable amount of care, building an acceptable X on a 286 class machine is quite manageable. Jim Fulton Cognition Inc. 900 Tech Park Drive UUCP: ...!{mit-eddie,talcott}!ci-dandelion!jim Billerica, MA ARPA: jim@athena.mit.edu, fulton@eddie.mit.edu (617) 667-4800 ---- Here are some rather unscientific comparisons that I ran to try and give some feeling for how PC/X shapes up against the QVSS, GPX (8 plane, color), and VS100 implementations of X. Please do not take these to be rigorous timing tests. 1. cat a small /etc/termcap three times in an 80x65 window smooth scroll xterm window in font 6x10, starting at the top of a clear window. This is using the new xterm distributed with X10.4 (with all window trappings turned off and an idle server). % wc /etc/termcap /etc/termcap /etc/termcap 192 279 6618 /etc/termcap 192 279 6618 /etc/termcap 192 279 6618 /etc/termcap 576 837 19854 total GPX: 16 sec VS100: 33 sec QVSS: 60 sec PC/X: 72 sec 2. xstar =700x500+0+0, 10 cycles (like xdemo star except that you can specify geom, number of points, etc.). Each cycle involves drawing and redrawing a completely connected graph of 32 points using XLine calls. Thus, there are 2 * sum over (1..31) XLines = 2 * 32 * 16 = 1024 calls to XLine per cycle (or 10240 total). GPX: 10 sec PC/X: 32 sec VS100: 50 sec QVSS: 66 sec 3. flash (invert twice) squares of size 1x1 through 750x750 from +0+0. Thus, there are 750 * 2 = 1500 calls: GPX: 31 sec VS100: 36 sec PC/X: 84 sec QVSS: 125 sec =============================================================================== Date: Tue, 24 Mar 87 11:37:06 cst Subject: Re: X on MS-DOS? Sounds like you want to run NeWS (Network/extensible Window System) on MS-DOS: NeWS's central feature is an extensible server -- it's expressly designed so you can download PostScript code to deal with user interface and to reduce network overhead. The NeWS server is also inherently multi-tasking, providing you with multiple lightweight processes. I can send you a NeWS Technical Overview if you want. =S Page Tech Pubs (windows) spage@sun.COM (415)354-4688 M/S A4-40 {hplabs,ucbvax,decwrl}!sun!spage =============================================================================== Date: Thu, 26 Mar 87 09:46:25 cst From: tilde::im4u!ames!ramoth.sgi.com!msc Subject: Re: X on MS-DOS? If you want to download code you'd be better off using NeWS (from Sun Microsystems). NeWS is also better suited than X to the low bandwidth path you typically have between a terminal and a host computer. The reason? Because NeWS' protocol is PostScript. You can download PostScript programs to the server (running in a terminal if you wish). You can also, of course, send program loops and can download functions to be called later both of which can greatly reduce the communication needed between client and server. X has no mechanism for downloading programs. -Mark P.S. I've also heard rumors that Microsoft is going to adopt NeWS and will provide MS Windows support for it. >From the TARDIS of Mark Callow msc@sgi.sgi.com, ...{ames,decwrl,sun}!sgi!msc ============================================================================== Date: Sun, 29 Mar 87 01:49:04 cst Subject: Re: X on MS-DOS? Your conclusions about select, etc., are basically correct. For an example of a program that does this right now, see xterm. It has to balance between input from the pseudo-tty (output from client UNIX programs) and input from the server (keyboard and mouse events). -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff ============================================================================ From tilde::texsun!sun!gorodish!guy Sun Mar 29 18:23:26 1987 Date: Sun, 29 Mar 87 18:23:22 cst From: tilde::texsun!sun!gorodish!guy Subject: Re: X on MS-DOS? ..... Sun developed a networked window system called NeWS; we are either selling it now (much like NFS) or will be selling it. Talk to your sales office. Our NeWS server has been ported to an Atari 520ST (although this is not a product); unless the bandwidth over the network is extremely low, I don't know offhand why the X server couldn't be ported to a PC. ..... The key here is the requirement for "enough intelligence in the MS-DOS applications to handle routine dealings with humans and give concise commands across the network to the host". The X protocol is currently fixed; you send drawing requests over the wire to the server (which would be a program running on the PC) and the server sends back input events (thus-and-such a key went down, the mouse moved, the left mouse button was hit, etc.) to the client (the program running on UNIX, VMS, whatever that's talking to the server on the PC). The new X.11 protocol will include an *ad hoc* extension mechanism; you can add new protocol requests and presumably new input event types to go back to the server. You could put code into the PC server to respond to these requests. Note, though, that this wouldn't be vanilla X; applications using these protocol extensions would either have to query the server to find out if it supported them, and fall back on doing the work itself if the answer was "no", or would have to run only with modified servers. If you were to load this code into the server dynamically, you'd have to have a separate protocol (such as TFTP) for grabbing the code. The NeWS "protocol" is based on the PostScript page description language, with extensions for handling input. To draw something, you send the NeWS server a PostScript program, which it executes. You can also send it a program to read keyboard and mouse events, which it will interpret. It can do a lot of the work in the server, and only send back information to the client when it thinks it should. End of commercial. You could also do the same for X.11 - add an X extension for downloading code in some form and use that instead of TFTP. You could download PC binary code, or interpretive code in some language (which is more-or-less what NeWS does). ============================================================================ Date: Tue, 31 Mar 87 17:47:11 cst Subject: pseudo X on small PCs i was just looking through some back X mailings and saw your posting re. X on MS-DOS. i'm curious as to what you have found/decided about your intended application and i also wanted to bring up a couple of ideas i've had recently. What i envision is quite a bit like your description. i would like to see an X driver to handle displays over serial or parallel lines to machines of the Mac/Amiga/Atari-ST class. It seems to me that this might be accomplished by using a high-level protocol to communicate between the driver on the Unix machine and the virtual device which would be running on the PC. That virtual device definition could be chosen to be one that was easy to implement in the context of whatever hardware/software the small computer was running -- there need not be a limit of one such device type. Of course, the code on this "display server" (and the communication protocol) would have to be able to direct the contents of window-data packets onto the proper window to handle multi-tasking, but that is really not so hard once the protocol is defined. This would allow one to forego the expense of Ethernet cards, etc. and just string a serial line from their PC to their host MicroVAX, say, and see essentially the same window environment they would see if their graphics device sat on the bus. i'm rather new to the world of X, so i don't know what (if any) work may have been done along these lines already, or how your own work might fit in with this idea. If you have comments, i would be very glad to hear them. Thanks. -neville ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ U.S. Mail: Neville D. Newman Advanced Decision Systems 201 San Antonio Circle, Suite 286 Mountain View, CA 94040-1289 Phone: (415) 941-3912 Net mail: neville@ads.arpa (internet-relative) ============================================================================== From: jim@ci-dandelion.UUCP (Jim Fulton) Subject: Re: X on MS-DOS? Date: 30 Mar 87 15:06:07 GMT Peter Osgood (speter@athena.mit.edu) writes: > X does not work on MS-DOS. Oh really? This message is being written from an xterm that I popped onto one of the PC/AT's sitting in my office. Cognition has had X running on MS-DOS for over a year. > As of yet, we, MIT, to the best of my knowledge see no way of putting > X on a PC of any type, save the RT when it is in Unix mode. You might want to review the XPERT archives for the various discussions of low end X implementations. In January I posted a technical summary of Cognition's PC/X shortly after the X Conference (at which Locus described their 386 version of X). Also, I've spoken to several people back at Athena about PC/X. Although I agree that having X run so that local applications can talk to the window system is a hard problem on a 286 (or worse) class machine, a server is fairly straightforward to implement. Admittedly we have had to put a little extra hardware in the AT to make it perform well (moderately smart high-res graphics board and Expanded Memory), but it really isn't fair to say that X doesn't run on MS-DOS (Locus's runs on the plain 386 hardware). For the record, PC/X is NOT an available product. We sell it only as part of our integrated Mechanical Computer Aided Engineering product line. However, I'm quite willing to send out copies of the technical description mentioned above. If you would like one just send me email (please include the return address in your message). People who are interested in writing MS-DOS X applications or being able to run an MS-DOS application in an X window should contact Locus Computing about their Merge 386 product. Jim Fulton Cognition Inc. 900 Tech Park Drive uucp: ...!{mit-eddie,talcott}!ci-dandelion!jim Billerica, MA arpa: jim@athena.mit.edu, fulton@eddie.mit.edu (617) 667-4800 ============================================================================= -- Patrick Peters UUCP: ut-sally!im4u!ti-csl!tifsie!pat Texas Instruments sun!texsun!ti-csl!tifsie!pat PO Box 655012 M/S 3635 uiucdcs!convex!smu!tifsie!pat Dallas, TX 75265 Voice: (214)995-2786
jimomura@lsuc.UUCP (04/17/87)
There is currently some work being done to port X to an OS-9 computer. The group involved does not have Net access, but I have contact with them. I haven't asked about the progress yet. Cheers! -- Jim O. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura