
NeWS – Network Extensible Window System - stevewilhelm
https://en.wikipedia.org/wiki/NeWS
======
zxv
Speaking of interesting mid 80s window systems, there was a light weight
window system developed by Stephen Uhler at Belcore.

It is under 20K lines of C, and very easy to port. It is able to run over a
serial line or a socket, in a few hundred K of RAM.

Screenshot:
[http://www.hack.org/mc/mgr/images/mgrscreen.png](http://www.hack.org/mc/mgr/images/mgrscreen.png)

More info: [http://www.hack.org/mc/mgr/](http://www.hack.org/mc/mgr/)

"MGR is to X as Unix is to Multix." -Dan Nachbar

~~~
cm3
MGR never supported X clients, right?

~~~
rwmj
No. The cool thing about MGR was that you programmed it by sending terminal-
like control codes to stdout. (I used to run MGR on Minix).

~~~
arethuza
Neat - even works that way for input as well:

 _" MGR notifies a client program of an event by sending it an ASCII character
string in a format specified by the client program."_

------
mhandley
NeWS was really cool. Back in 1987/88 I used an early release of NeWS for my
final-year undergrad project. It was made a little more challenging by only
having a photocopy of a pre-release of the documentation, that was missing all
the diagrams.

The model was really cool - completely different from X11, which is much more
limited. With X, your app runs on the client and sends drawing commands to the
display server. With NeWS, you can split your app arbitrarily between the
client and the display server. The client simply extends the server by sending
it postscript functions to locally interpret when asynchronous events happen.
So you can write new widgets, and they run entirely on the display server so
get really low latency, while the rest of the app is running remotely over a
piece-of-wet-string network connection.

You could be sitting in from of a display running a nice interactive GUI, with
the app running in a different country or over a modem connection. At least
you could if the application designer got it right. Getting the split of
functionality between the client and server (and the communication between
them) right was definitely more challenging than writing X apps, but the
benefits were significant.

~~~
mcguire
8 1/2, from Plan 9, used a similar architecture, IIRC, because of the smart
terminals it was written for. Check out the editor Sam for an example; one
side is ed++, the other is the GUI.

~~~
jonjacky
There are emulations of the Plan 9 smart terminals that run under Unix-like
operating systems. They are quite different from xterms - they have much
simplified communication with the remote host but much richer local editing
capabilities:

[http://sydney.edu.au/engineering/it/~matty/9term/](http://sydney.edu.au/engineering/it/~matty/9term/)

[https://github.com/chneukirchen/tt](https://github.com/chneukirchen/tt)

The original Plan 9 terminal and window manager are described here:

[http://plan9.bell-labs.com/magic/man2html/1/rio](http://plan9.bell-
labs.com/magic/man2html/1/rio)

------
tilt_error
PostScript really is a lovely programming language. Some 20 years ago, I used
a development environment (PSAlter) that made it quite palatable --
visualising dictionaries and stacks -- and made it possible to step through
programs.

There exists a nice free e-book describing PostScript (Thinking in PostScript
by Glenn C. Reid) [1].

[1]
[https://web.archive.org/web/20000914161447/http://www.rightb...](https://web.archive.org/web/20000914161447/http://www.rightbrain.com/download/books/ThinkingInPostScript.pdf)

EDIT

While looking for the Thinking in PostScript book mentioned above, I stumbled
upon this legal online archive for books on the net [2] which may be of
interest to others.

[2]
[http://onlinebooks.library.upenn.edu](http://onlinebooks.library.upenn.edu)

~~~
tonyedgecombe
PSAlter is still available:
[http://www.quite.com/psalter/psalter.htm#order](http://www.quite.com/psalter/psalter.htm#order)

------
tracker1
This just reminds me how much of a shame it is that the best option for a
remote UI today is a localized browser, and the tools that go with it... Don't
get me wrong, I think the browser/web is a great platform, and better than
many other options that have come and gone, that said...

It sucks that VNC, X11, and RDP are the best we have... though, I will admit
RDP is pretty serviceable, X11 just seems too janky to work over a really
remote connection... and VNC, well it works, but, sigh...

I don't think that any remote application UI will really take over as everyone
that might work on such a thing wants to gain a lock in with the goal of
financial gain... so nothing really reaches a significant market share. This
is the case were something that is great and libre/opensource would be better
than a standard.

~~~
twsted
> X11 just seems too janky to work over a really remote connection.

Surely It is.

But I cannot forget how magic it seemed in the 80s doing

    
    
      titan$ export DISPLAY=zeus:0.0; xeyes &
    

over slow serial lines.

~~~
gpvos
xmeltdown

~~~
DonHopkins
Jeremy Huxtable made the original "Big Brother" NeWS version of eyes [1],
which inspired xeyes at SIGGRAPH '88 [2], and he also made the NeWS version of
melt [3], in just 30 lines of code!

My favorite OpenWindows demo was Pat Lashley's monaeyes [4], of course. And I
made a fancy version of eyeball windows for The NeWS Toolkit [5] to show off
its drag-n-drop and nested window management capabilities, where the eyeball
was the window frame, and the iris was the client window, and you could split
them in two, and even drag and drop eyes inside of each other, so that sub-eye
window frame was reparented inside the moving super-eye client iris! The
effect was very creepy and CPU intensive, and I could never quite talk the
OPEN LOOK folks into adopting them into the standard.

[1] [http://donhopkins.com/home/archive/news-
tape/fun/eye/eye.ps....](http://donhopkins.com/home/archive/news-
tape/fun/eye/eye.ps.txt)

[2]
[http://www.x.org/archive/X11R7.5/doc/man/man1/xeyes.1.html](http://www.x.org/archive/X11R7.5/doc/man/man1/xeyes.1.html)

[3] [http://donhopkins.com/home/archive/news-
tape/fun/melt/melt.p...](http://donhopkins.com/home/archive/news-
tape/fun/melt/melt.ps.txt)

[4]
[http://donhopkins.com/home/archive/NeWS/monaeyes.txt](http://donhopkins.com/home/archive/NeWS/monaeyes.txt)

[5]
[http://donhopkins.com/home/archive/NeWS/eyes.ps.txt](http://donhopkins.com/home/archive/NeWS/eyes.ps.txt)

------
david-given
NeWS was lovely --- the application got to download custom logic via
Postscript onto the display server and run it there, so you could run
interactive applications quite comfortably on high-latency links. Proper MVC
separation!

Also, it had PizzaTool.
[http://www.donhopkins.com/home/catalog/images/pizzatool.gif](http://www.donhopkins.com/home/catalog/images/pizzatool.gif)

Source code:
[http://www.donhopkins.com/home/code/pizzatool.ps.txt](http://www.donhopkins.com/home/code/pizzatool.ps.txt)

I've always rather wondered why no open source NeWS clone never came along.

~~~
arethuza
Do you think the _forking_ off multiple processes to draw all of the toppings
concurrently was premature optimisation? ;-)

[Edit: I was pleasantly surprised at how readable that code is]

~~~
david-given
Possibly premature, definitely not optimisation...

...but I saw it running in real time, and it was actually pretty cool to see
all the toppings appear (this was on a Sparc ELC-class machine, so it didn't
have much grunt). Seamless dithering on the monochrome display, too.

Also, the spinning the pizza was done by rotating the rendered bitmap. The
inaccuracies meant that as you spun it, the toppings would all gradually blend
into each other. I suppose that's realistic, in a way.

~~~
DonHopkins
I'm glad you had fun! Thanks for the mention. The point of PizzaTool was to be
well commented example code for developers to read, that showed how to plug
many different parts of The NeWS Toolkit together (thus all the drag-n-drop
and threading and image transformation stuff).

You're right, that was the best "melting" effect I could come up with, within
the constraints of the PostScript imaging model. PizzaTool spins the pizza
automatically, because I got tired of turning the image rotate tool in Stuart
Marks' RasterRap by hand again and again to get that melting effect. I left it
running over Christmas vacation, and it collapsed into an blob. But you can
still add more toppings at any time while it's spinning!

Here's a demo of spinning pizzas, dragging and dropping images between
RasterRap and PizzaTool, and cleaning the pizza tray afterwards with a wave.
Sorry about the bad video quality!

[https://www.youtube.com/watch?v=avJnpDKHxPY&feature=youtu.be...](https://www.youtube.com/watch?v=avJnpDKHxPY&feature=youtu.be&t=21m42s)

~~~
david-given
While you're here...

What was the NeWS security model like? Could it safely combine Postscript
programs from multiple users on the same display server without information
leakage between users?

And I suppose the NeWS source code got eaten by lawyers long ago and is
unlikely ever to see the light of day?

~~~
DonHopkins
NeWS was just as "open" (in the bad security sense of the term) as X11 was at
the time, and didn't have any protection between clients, but was much more
reflective and easier to explore. Once you're in, you're really really in.

Tools that imported EPS could be tricked into doing all kinds of stuff like
forking Unix processes, and open files. And being able to open files also
meant opening sockets with the %socket syntax.

NeWSPrint was a laser printer that ran NeWS on a workstation to render pages,
in a stripped down presumably firewalled environment. But I was able to cause
an error in a certain context that left an execution stack dump on the operand
stack before calling my code, and inside that stack dump were nested
executable arrays of PostScript code that contained an inlined unrestricted
'file' operator. So it was possible to make a PostScript file that would
connect to the finger server and print out a list of anyone who was logged in.
Or anything else if you can fish out a fork operator!

The NeWS source code is in that indeterminate "not lost but not published"
state.

It would be a lot of fun and not so difficult to reimplement clean room NeWS
in JavaScript from scratch, using canvas for all your PostScript rendering
needs, which would otherwise be the hard part. James Gosling wrote the
original SunDew interpreter in a weekend, but the graphics stuff took years to
get right.

Gosling's SunDew paper: [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p005.htm)

A few years ago I dabbled in writing a spec and some plumbing for NeWS in
JavaScript, but haven't had the time to work on it recently. If anyone wants
to work on it, I'd be happy to answer questions and put a little more time
into it when I can.

Source code:
[http://donhopkins.com/home/sundew/sundew.js](http://donhopkins.com/home/sundew/sundew.js)

It doesn't do anything exciting or graphical yet, since I was just working on
the interpreter. So far I've classified and listed out all of the operators
you'd need to cover, made nucleus classes for the vm, processes and objects,
modeled shared bodies for dicts, array and string sub-intervals, stubbed out
all of the NeWS primitive and magic dictionary data types, and stopped just
short of writing the main interpreter loop in PSProcessBody.run, which will
work a lot like ps.ps:
[http://donhopkins.com/home/code/ps.ps.txt](http://donhopkins.com/home/code/ps.ps.txt)

It still needs a lot of fleshing out, including a tokenizer (but that's
trivial for PostScript) and many operators and graphics (but that stuff's
fun!).

I'm sure that with some more work on a clean room JavaScript NeWS server, it
would be both possible and legal to run a lot of the old NeWS 1.1 demos and
apps like psiber, and maybe even later OpenWindows stuff like pizzatool,
pretty darn fast in a web browser.

------
simula67
This is the project the demise of which lead to Java :
[http://www.blinkenlights.com/classiccmp/javaorigin.html](http://www.blinkenlights.com/classiccmp/javaorigin.html)

~~~
DonHopkins
Keep in mind that while extremely fascinating and enlightening and well worth
reading, and how apt his comparison to the Gaza strip, that essay is from
Patrick's own unique perspective, and he does not necessarily share all the
same opinions as the dispassionate people for whom he recommended euthanasia.
;)

------
arethuza
I used HyperNeWS for a few years on a project and had great fun with it (front
end in PostScript/NeWS, back end in Common Lisp and plumbing in C).

You could do some neat tricks - draw something in the graphical editor, copy
it and paste it as the shape of a window (stack). Another thing you could do
was log in through the PostScript shell to the server, navigate to your window
(or anything else) and fiddle with it using standard PostScript 2D transforms.
e.g. You could gradually rotate a terminal window, although I would never have
done this to a colleague as they were using it, honest.

I rather enjoyed working in PostScript although I believe there was a C to
PostScript compiler built at one point (inevitably this being done in Glasgow
it was called pdb for "pure dead brilliant").

Don't think there was much of a security model in NeWS so probably not a great
fit for today's world but it was so much cooler than X.

------
grymoire1
I used and wrote code for NeWS - the pre-curser for Java. I was also at the
talk where Gosling admitted the problems it had. In some cases, a lot of
features of Java were in response to the problems with NeWS.

NeWS was so awesome when it came out, where you can dynamically change the
interface at any time. But NeWS had some horrible bits. As a language, it was
very hard to read. If you saw a name, you didn't know if it was a variable or
a function. That is, you didn't know if the value would be pushed onto the
stack, or if it would pop some values off the stack. Best Practice was to add
a comment after each line to indicate what the top of the stack would look
like after that line. So if you got lost reading one line, you could figure
out what the next line would do. But without it, after seeing three words in a
row that you didn't fully understand, you were hopelessly lost.

NeWS (PostScript) was a write-only display model. You could not remove
anything painted on the screen. You had to write over it. Adobe had Display
PostScript, but that never took off.

And because of the write-only display, NeWS had a hard time freeing resources.
Garbage collection was very difficult because of this. You would allocate a
white square, and never truly "remove it" from memory. As I recall, a page
refresh had to re-interpret all of the code - there wasn't any caching of the
window.

Also - the entire display model with postscript-based scaling was CPU
intensive, especially if you had a computer with slow graphics (quite common
at the time).

~~~
rthille
"Adobe had Display PostScript, but that never took off." Well, except for it's
use in NeXTStep. Though I think they threw it out in favor of PDF/Quartz for
OS-X.

------
cer314
Just this morning I spoke of NeWS (for the first time in at least 20 years) to
a colleague at work. Very strange to see this posting on HN in the same day...
PostScript with classes... and input methods... seemed to be a very
interesting way to model user-interfaces, and graphics rendering in general...

------
mhd
Ah, pie menus... Weirdly enough, the only place I see them these days is
games.

~~~
jle17
That may be due to Don Hopkins. He did the pie menus for NeWS and latter for
The Sims.

~~~
shrizza
jwcad usage is very piemenu-centric.

------
mozumder
OpenLook window manager was great.. I loved how customizable it was, using
things like text files to customize root menus. It was also the best looking
WM I've used.

------
agumonkey
Maybe my google-fu was blurred by the 'news' term but it was very hard to find
things about it (beside "NeWS was great").

------
baus
NeWS wasn't the only windowing system to use Display PostScript. The other big
one was NeXTSTEP which obviously became OS X.

~~~
DonHopkins
NeWS was not actually Adobe's Display PostScript, but it was Sun's independent
implementation and specialized dialect of PostScript, supporting light weight
processes, overlapping arbitrarily shaped canvases, window management, event
distribution, garbage collection, networking, object oriented programming,
etc.

The most important ability that NeWS had, but was missing from Display
PostScript and its successors (OS/X Core Graphics, PDF, SVG, canvas API, etc),
is the ability to download code to create an efficient custom high level
application specific protocol between the client and server.

That essential ability is what people call "AJAX" these days, now that
PostScript has been supplanted by JavaScript and a whole bunch of different
APIs, and now we're even downloading shaders to the GPU! Truly exciting!

James Gosling chose PostScript from the start, for how its network programming
ability dovetails with its graphics and data representation, instead of
nailing it onto the side of a bunch of different technologies as an
afterthought.

To quote the comparison from the wikipedia article:

NeWS was architecturally similar to what is now called AJAX, except that NeWS
coherently:

1) used PostScript code instead of JavaScript for programming.

2) used PostScript graphics instead of DHTML and CSS for rendering.

3) used PostScript data instead of XML and JSON for data representation.

~~~
DonHopkins
Here's a deeper discussion of the technical design differences between NeWS
and Display PostScript, from a discussion with Robin Schaufler and James
Gosling:

    
    
        From: James Gosling <jag@Sun.COM>
        Subject: Re: Display PS vs NeWS
        Date: 22 December 1988 at 19:35:08 GMT+1
        To: Robin Schaufler <robin@Sun.COM>
        Cc: don@brillig.umd.edu (Don Hopkins), sevans%norquay@Sun.COM
    

Robin: Don, I'm replying just to you, not to NeWS-makers (trying to stay out
of trouble). The one major area where NeWS cannot emulate Display PS is that
of memory management. Display PS introduces the notion of spaces; effectively,
each process group gets its own heap. Kill the process group - the memory gets
cleaned up whether it has cycles in it or not. Very nice, actually. But a
major project for us if we decide to adopt it. Fortunately, we already started
on a new memory management system for data localization that will help some
with implementation.

James: The thing that we don't have is a thousand caveats on what can be
assigned to what. You can't have pointers that cross spaces in Adobe's scheme,
so as you read through their documentation you find zillions of restrictions
that make life very difficult. Also, the "kill the process group..." doesn't
really apply: they don't have process groups. Each process is alone. If you
want to share, you have to stick stuff in the "shared" space or be forked from
a common parent. save/restore has bizarre semantics in this memory model: eg.
if a process executes "save" then any other process that shares the same
storage pool is blocked (honest, I'm not making this up!)

Robin: We also can't emulate their lock mechanism. I had the distinct
impression that they analysed NeWS monitors completely, figured out exactly
what was wrong with them, and fixed it. I really like this extension, but
again, considerable work for us (tho less than for the memory management
extension).

James: Far from considerable work and of dubious value: almost no one has ever
used locks. DPS locks are identical to NeWS monitors (they're even applied
with the same primitive "monitor"). NeWS is missing condition variables, which
are a good idea but not difficult to implement. Events are the common form of
process syncronization in NeWS.

Robin: Another area we would have trouble emulating is their new halftoning
operators, but that seems like less of a problem. The new operators allow for
tiling, which we've implemented for X, but we'd still have to hook it up for
NeWS, and provide their model, which isn't quite the same model. Actually,
NeWS probably can emulate it but it would be beastly slow.

James: Actually, the DPS threshhold are NOT the tiling operators that
PostScript so badly needs. If you read it carefully, for devices with more
than one bit per pixel you can't get the tiling effect. Halftones continue to
only be useful for halftoning.

Robin: In a few cases they picked the same names and operator spec as us, but
in general they didn't try to be compatible. A few incompatibilities seem
gratuitious to me.

James: eg. processes

