[comp.sys.ibm.pc] X on MS-DOS

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