https://github.com/larsbrinkhoff/bagley-nottingham-tapes

For now we have the sources of NeWS 1.1 (and operators.h if you look more in depth) and X/NeWS 2.0. I also have the RBuss sources (an incomplete clone), but I have to ask the author if they can be put on the internet.

P.S: check BitSavers and Don Hopkins archives...

I also hope to see resurface binaries/sources of other server implementations, Sun Symbolic Programming Environment (which includes code originally developed at Schlumberger, including LispScript), the sources of the PdB compiler, CMU Andrew wm (although is not directly related, is the ancestor of this window system, from the same authors), and whatever is related to this system.

It would be interesting a revival like Interlisp.

Anyway, if I was persuaded that Wayland has a rather backwards design (here my reasons: https://news.ycombinator.com/item?id=47477083), now I have the confirmation that its philosophy is something like "put surfaces on the screen and distribute events to the clients, all the other stuff is not my business", and that exploring alternative approaches to window management is still worth it. Having applications that manage all their resources (canvases, events, decorations) is not bad per se (for example video games), but not all of them need to.

The NeWS book at page 35 has a picture explaining the structure of the CMU Andrew Window System: the window manager on top of the "base window system" (assuming protocol and logic), which sat on the graphic library, and applications connected to it through sockets. A limit was that the window manager was fixed, so you couldn't change its policy/look and feel without having the sources and recompiling it (and here I wish the source code was available).

Wayland it's kinda similar, but most of the graphic layer is moved from the server into each application (where each one use its own). Unless you have a compositor that is designed to be extensible out of the box, a set of widgets will be needed if you don't ship a desktop environment, and each one is a separate system process (for example: toolbar, clipboard manager, status bar, wallpaper). Another limitation is its "static" protocol, in the sense that you cannot extend the compositor at runtime loading extensions (you have the XML which is used to generate the stubs for the implementation in the compositor AFAIK). This can prevent applications that use them to run on compositors that don't implement them.

On the other hand, systems like NeWS, GMW (a window system from Kyoto University, ASTEC and Omron) and the one described by Rob Pike in "A concurrent window system" are interesting for these reasons:

- runtime extension loading code: new functionalities to the server can be added when needed

- code as a protocol: instead of sending "raw data" and requests, equivalent pieces of code are sent, allowing for compression and to offload a portion of the logic to the server (or even have applications that run inside the server). This can also allow to have applications that run on remote machines, which download the code for the interface to the server.

- concurrency: their programming model is structured around "lightweight processes" (or equivalent), which allow to decompose the interaction in independent tasks, which can eventually interact by sending messages/events or sharing resources.

I think it's worth re-investigating this kind of design, considering also the technological advancement (like the evolution of graphic hardware, multicore CPUs, touchscreens, ecc) and challenges (including security). It would be interesting something like NeWS but a bit more abstract and capable of supporting whatever graphic model you wish.

These are some screenshots of NeWS 1.1 running on SunOS 4.1.4 on QEMU that I took time ago. Unfortunately QEMU SPARC decided to break again. Also, keyboard doesn't work yet (forcing me to use the SunView terminal emulator), but probably it's due to the keyboard script.

In any case, SunOS 4.1.4 comes with OpenWindows out of the box.

On comp.windows.news Usenet group and on the NeWS book is reported that a portable codebase (called REF) exists, and Sun ported it on Ultrix (on thr VAXstation) and System V. I read it included a version of PixRect called "Generic PixRect", which should be more portable.

BitSavers put on the net a tape dump of X/NeWS 2.0, and there are some differences: a different graphics library called SHAPES replacing CScript (and it needs the Ace preprocessor to build the device dependent portion of the library), a different memory allocator, support for X11 protocol, support for Folio F3 fonts, and other things.

Fortunately I found a copy of PixRect in the leaked sources of SunOS 4.1.4 , but it's not enough, since that device dependent routines must be rewritten.

I'm slowly porting NeWS 1.1 to NetBSD (since that wscons is easier to work with) as a proof of concept. I managed to execute code and grt my screen turn blue, but the current obstacle is decoding binary fonts: the OG routines fail completely on 64 bit machines, since that the original format assumes 32 bit machine words and big endian order. More work will be needed.

It is pretty much obscure, and all I found is that was made at Kyoto University (who also made Kyoto Common LISP), and it used a virtual machine.

Unfortunately the papers are o ly in japanese. - https://ir.library.osaka-u.ac.jp/repo/ouka/all/65804/oksn_07... - https://ja.m.wikipedia.org/wiki/GMW - https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&activ...

Today I stubled upon a rather obscure window system that was being developed on Linux between 1999 and 2003: Fresco. As far as I've seen it was written in C++ and leveraged CORBA and GGI.

If any of you got the opportunity to try it back in the day, could you describe how it was?

I also stumbled upon these two related projects: KGI and GGI, which dealed with graphic acceleration, drivers, input and rendering.

Whatever happened to all these projects? Did they failed to meet their goals?

Links: - https://web.archive.org/web/20061123090303/http://www.fresco.org/index.html - https://github.com/stefanseefeld/fresco - http://www.ibiblio.org/ggicore/links.html#games - http://www.ibiblio.org/ggicore/index.html - http://www.kgi-project.org/index.html

Comments URL: https://news.ycombinator.com/item?id=34236515

Points: 2

# Comments: 0