window implementation summary
cn...@kiet.uucp
1.Maryland Window System
The window package in the form of a C loadable library.
This flexible package allows convenient management of multiple contexts on the screen and runs on ordinary character display terminals as well as bit-mapped displays. Included is a Frantz lisp interface to the window library, a window shell for executing shell processes in windows, and a menu package(also a C loadable library). The basic Maryland Window System subroutine package is approximately 7000 lines of C, and runs under Berkeley 4.1 and 4.2 Unix.
Contact : Diane Miller
{seismo,allegra}!umcp-cs!despina
(301) 454-7690
2.WM , window manager program for Unix
WM runs as a collection of user processes, connected by pipes.
There are 3 1/2 versions of the program. Source for each is about 80K bytes.
wm.v6 runs on vanilla v6 Unix, a relic from the ancient past.
wm.v7 runs on vanilla v7 Unix on a PDP-11, also on 2.8bsd, on a VAX on 4.1bsd and (probably) 4.2bsd, and on a SUN on 4.1c, but it does'nt exploit the later Unixes. Uses TERMCAP if you have it, but can also run without it. This is the most robust and portable version, but it lacks some of the neat features of the later ones.
wm.v7c runs on v7 Unix systems that have CURSES. This has been tested only on 4.1bsd on a VAX, but should work on v7 or 2.8bsd on a PDP-11 if it will fit. It runs faster ans has some extra features, but is a little less robust and less portable than wm.v7.
wm.v42 (this is the 1/2 version) completely redesigned to use features available only in 4.2bsd Unix, namely non-blocking i/o and PTY's. HOWEVER, I have not been able to test it properly on 4.2, so I suspect it needs a little hacking to mak it run.
Finally , this is a brief description of what the program does:
WM manages a collection of windows on a display terminal. Each window has its ownshell, running in parallel with those in the other window. This permits a user t conduct several interactions in parallel, each in its own window.
The user can move from one window to another, re-position a window, or create or delete a window at any time without losing his or her place in any of the window. Windows can overlap or completely obscure one another; obscured windows can be lifted up and placed on top of the other windows.
Contact: Robert Jacob
{decvax, linus}!nrl-css!jacob
3.windows for BLIT terminal
Rob Pike of Bell Labs implemented windows for the BLIT terminal.
It uses a segmented bitmap approach.
See The ACM Transactions on Graphics, Vol 2, No 2, Apr 83 ,pp.135-160
4.Nunix window system
Jack Test of MIT LCS may be distributing the Nunix window system source code.
5.WINDX - Windows for the UNIX Environment
Peter E. Collins of Ithaca Intersystems, Inc has implemented WINDX to GRAPHOS graphics terminal.
SEE: WINDX-windows for the Unix environment
1984 summer conference proceedings, Usenix, pp.159-165
6.BRUWIN
The BRUWIN system implements a window environment for general text terminls as described in termcap. It is implemented as a collection of programs communcating via pipes. A display manager maintains windows on each terminal, keeping track of window priority and overlap. A virtual terminal emulator task is used t provide programs with a uniform terminal interface by making all terminals behave as if they were a VT-52. Finally a tasking controller arbitrates application program access to window input and output.
SEE : Norman Meyrowitz and Margaret Moser, "BRUWIN : An Adaptable Design Strategy for Window Manager/Virtual Terminal Systems", Proc.8th Symp. Operating Systems Principles Vol.15(5),pp.180-189,ACM(Dec.1981)
-------------------------------------------------------------------------------
All above is what I received and found, if there are missing information or incorect, Please let me know that.
Good Luck!
Choong Nyun, Kim
..!hplabs!kaist!kiet!cnkim
Bruce Cohen
I would not class BRUWIN as an existing implementation, unless work has been
done on it recently. I obtained an early version of it from Meyrowitz in
1982. It had no documentation, not even on building it, and the make files
had pathname dependencies which were totally different from the directories
on the tape I got, so putting it together was fun. The release I got was
buggy and incomplete, and after six months of being told "The next release is
coming soon!" I was told "It's a low priority project which will probably
never be finished."
Too bad, it looked like a neat idea.
Bruce Cohen
UUCP: ...!tektronix!orca!brucec
CSNET: orca!brucec@tektronix
ARPA: orca!brucec.tektronix@rand-relay
USMail: M/S 61-183
Tektronix, Inc.
P.O. Box 1000
Wilsonville, OR 97070