Discussion:
Dec VWS Internals ?
(too old to reply)
ChrisQuayle
2006-12-23 13:30:09 UTC
Permalink
Does anyone know where docs describing dec's early vws windowing system
can be found ?. Am interested in theory, internal design, structure etc.

Thanks in advance - tried google but got loads of car tuning stuff...

Chris
Paul Sture
2006-12-28 01:12:21 UTC
Permalink
Post by ChrisQuayle
Does anyone know where docs describing dec's early vws windowing system
can be found ?. Am interested in theory, internal design, structure etc.
Thanks in advance - tried google but got loads of car tuning stuff...
I had VWS with V5.2, and I'm pretty sure it was in the current doc set then.
FredK
2007-01-04 14:04:44 UTC
Permalink
Post by ChrisQuayle
Does anyone know where docs describing dec's early vws windowing system
can be found ?. Am interested in theory, internal design, structure etc.
Thanks in advance - tried google but got loads of car tuning stuff...
Chris
"Most" of the people involved in VWS have long since left DEC/Compaq/HP, and
the product was sold off to Touch Technologies. VWS was entirely designed
and implemented by engineers in the VMS group - so it had an odd slant since
the original engineers were mostly OS developers and had little or no
graphics backgrounds. The primary inspiration for VWS/UIS can be found by
reading Fundamentals of Computer Graphics (Foley and Van Dam [sp]). In
fact, you can see this clearly in how ths HSV code was incorrectly centered
since they used the *example* from the book (that clearly said it was done
to make the example clearer). One of the guys was learing to fly at the
time, and arcs for example were specified in the wrong way (compass instead
of typical math geometry). The other inspiration was to make it easy to
implement GKS on top of it (the most popular graphics programming library at
the time).

Some random notes:

-It was entirely written in Bliss (with a smattering of Macro-32).
-It was very VMS oriented and AST event driven.
-It provided guaranteed backing store, breaking windows down into chunks
-Applications could not access or affect windows not created by the
application.
-The terminal emulator (written in C) ran entirely in Kernel mode (it was
loaded into paged pool).
-The programming interface was called UIS
-Despite the programming interface using floating point, the code did not
use floating point, but rather scaled integer arithmatic
-Text positioning was represented with a very high precision to allow
sub-pixel positioning for WYSIWYG text editing
-Text could be scaled, rotated, sheared and the path reversed
-Keyboard mapping could be specified per-application programatically
-The UIS calls used a virtual (floating point) coordinate system specified
by the user. UISDC provided an integer pixel addressing.
-UIS calls built a display list, and the user could scale the output and
redraw the output.
-The display list meta-data was also the print output meta-data
-Color was specified in a pseudo-color model

VWS was only implemented on two graphics engines before it was retired - a
monochrome frame buffer, and the GPX graphics engine.

UISX was implemented as a way to migrate VWS applications. UISX implemented
the entire VWS programming model on top of X11. In fact, the application
did not even need to be re-compiled.
Alan Frisbie
2007-01-04 20:02:18 UTC
Permalink
Post by FredK
Post by ChrisQuayle
Does anyone know where docs describing dec's early vws windowing system
can be found ?. Am interested in theory, internal design, structure etc.
"Most" of the people involved in VWS have long since left DEC/Compaq/HP, and
the product was sold off to Touch Technologies. VWS was entirely designed
and implemented by engineers in the VMS group - so it had an odd slant since
the original engineers were mostly OS developers and had little or no
graphics backgrounds.
...
Thanks for these notes, Fred. I have always been a fan of VWS and miss
some of its features that don't exist today.

Alan
JF Mezei
2007-01-04 20:37:40 UTC
Permalink
Post by Alan Frisbie
Thanks for these notes, Fred. I have always been a fan of VWS and miss
some of its features that don't exist today.
I miss the moon lander !!!!!

(and I miss Flight since it no longer works on alpha workstations with
less antique graphic cards).
Michael Moroney
2007-01-07 23:50:42 UTC
Permalink
Post by Alan Frisbie
Thanks for these notes, Fred. I have always been a fan of VWS and miss
some of its features that don't exist today.
One weird one I remember was a font it had that was 1 pixel wide and 2 or
3 pixels high. With it you could make an itty bitty terminal window.
While you couldn't actually read anything when using this font, you could
recognize what was going on, just like viewing a terminal screen from a
distance. There was some sort of magic with this font (only) where
clicking on the terminal window made it switch to a normal font so you
could read it, almost like an icon.

Some people used terminal windows with that font to monitor OPCOM messages.
FredK
2007-01-08 14:56:57 UTC
Permalink
Post by Michael Moroney
Post by Alan Frisbie
Thanks for these notes, Fred. I have always been a fan of VWS and miss
some of its features that don't exist today.
One weird one I remember was a font it had that was 1 pixel wide and 2 or
3 pixels high. With it you could make an itty bitty terminal window.
While you couldn't actually read anything when using this font, you could
recognize what was going on, just like viewing a terminal screen from a
distance. There was some sort of magic with this font (only) where
clicking on the terminal window made it switch to a normal font so you
could read it, almost like an icon.
Some people used terminal windows with that font to monitor OPCOM messages.
Not quite sure what system that was on. On VWS I implemented a 2-pixel
high/1-pixel wide font that was used when you shrank the terminal window to
an icon, I essentially continued to run the terminal emulator in the icon
using this font. I (and others) found it useful - since you could tell when
there was activity on the terminal.
Michael Moroney
2007-01-08 21:12:14 UTC
Permalink
Post by FredK
Post by Michael Moroney
One weird one I remember was a font it had that was 1 pixel wide and 2 or
3 pixels high. With it you could make an itty bitty terminal window.
While you couldn't actually read anything when using this font, you could
recognize what was going on, just like viewing a terminal screen from a
distance. There was some sort of magic with this font (only) where
clicking on the terminal window made it switch to a normal font so you
could read it, almost like an icon.
Not quite sure what system that was on. On VWS I implemented a 2-pixel
high/1-pixel wide font that was used when you shrank the terminal window to
an icon, I essentially continued to run the terminal emulator in the icon
using this font. I (and others) found it useful - since you could tell when
there was activity on the terminal.
I think that was it. It was this (real) icon that used the tiny font, and
the normal uniconizing that switched to the normal font. There have been
a few times when I wished DECWindows had that.
FredK
2007-01-09 01:10:16 UTC
Permalink
This post might be inappropriate. Click to display it.
JF Mezei
2007-01-09 11:59:59 UTC
Permalink
This post might be inappropriate. Click to display it.
Michael Moroney
2007-01-09 14:26:14 UTC
Permalink
Post by FredK
Post by Michael Moroney
I think that was it. It was this (real) icon that used the tiny font, and
the normal uniconizing that switched to the normal font. There have been
a few times when I wished DECWindows had that.
There were a few times I thought about doing it... but if I did that, then
I'd feel compelled to add things back in like the window control OSC
sequences, and before you know it I'd be spending all my free time on
DECterm.
Actually all that would be necessary would be the font itself and a way
to select a font, window by window from one of the pulldown menus window
by window. Actually, I see it's there, I can just change the "little font"
in the options/window menu. Although the OSC sequence would be nice :-)

Aside, is there a way to convert Windoze fonts to be usable by DECwindows?
Probably in the FAQ, off to look...

ChrisQuayle
2007-01-04 21:14:42 UTC
Permalink
Post by FredK
"Most" of the people involved in VWS have long since left DEC/Compaq/HP, and
the product was sold off to Touch Technologies. VWS was entirely designed
and implemented by engineers in the VMS group - so it had an odd slant since
the original engineers were mostly OS developers and had little or no
graphics backgrounds. The primary inspiration for VWS/UIS can be found by
reading Fundamentals of Computer Graphics (Foley and Van Dam [sp]). In
fact, you can see this clearly in how ths HSV code was incorrectly centered
since they used the *example* from the book (that clearly said it was done
to make the example clearer). One of the guys was learing to fly at the
time, and arcs for example were specified in the wrong way (compass instead
of typical math geometry). The other inspiration was to make it easy to
implement GKS on top of it (the most popular graphics programming library at
the time).
Thanks very much, a very valuable introduction. Have been writing a
small windowing gui system for embedded projects and part of the effort
has been to get a historical perspective on early ws windowing systems,
which were similarly constrained by low throughput cpu's and small
memory sizes. The two dec wrl reports on dumb colour frame buffer
programming have also been very valuable. Have a bit of info as on Sun's
NeWs system, but am still digging for info on others. It was really
quite difficult to get decent graphics response and the use of (for
example) scaled integer arithmetic, rather than floats, must have
contributed quite a bit, especially if the data could be organised to
enable the use of shifts, rather than multiply and divide instructions.
Post by FredK
VWS was only implemented on two graphics engines before it was retired - a
monochrome frame buffer, and the GPX graphics engine.
I think vws was available on the uVax II/GPX and the monochrome frame
buffer variant. around the vms 4.7 to 5.4 timeframe and was faster than
Decwindows on X, which really needed more memory and cpu throughput.
Decwindows ran far better on the later KA650 series.
Post by FredK
UISX was implemented as a way to migrate VWS applications. UISX implemented
the entire VWS programming model on top of X11. In fact, the application
did not even need to be re-compiled.
That sounds like typical dec foresight :-)...

Chris
FredK
2007-01-05 16:35:55 UTC
Permalink
Thanks very much, a very valuable introduction. Have been writing a small
windowing gui system for embedded projects and part of the effort has been
to get a historical perspective on early ws windowing systems, which were
similarly constrained by low throughput cpu's and small memory sizes. The
two dec wrl reports on dumb colour frame buffer programming have also been
very valuable. Have a bit of info as on Sun's NeWs system, but am still
digging for info on others. It was really quite difficult to get decent
graphics response and the use of (for example) scaled integer arithmetic,
rather than floats, must have contributed quite a bit, especially if the
data could be organised to enable the use of shifts, rather than multiply
and divide instructions.
The VWS footprint was fairly small. The most complex part of VWS was due to
the decision to provide guaranteed backing store. Each application created
a viewport and then could map one or more windows into the viewport. From
the applications point of view - nothing else was running on the graphics
screen.

Overlapping windows and backing store were in the early days the toughest
thing to get right. Remember that the original MS Windows design supported
tiled windows only.

The real speed limiter between VWS and X11 was that the UIS interface was
procedural and did direct rendering (in the case of the MFB) and a "near"
direct rendering on the GLX engine (packets queued to a device driver
drawing queue). X11 generates protocol packets that are processed by
another process (adding a context switch, scheduler delays, and protocol
parsing). Microsoft found out the hard way just how much of a performance
hit this was when NT implemented it's GDI originally in the same manner.
Even with assists like the LPC interface it was much slower.

Also VWS was tightly coupled to VMS. Taking advantage of AST's for example.
You could make UIS calls from any mode. The terminal emulator ran as an AST
driven extension to a terminal port driver. Etc.
Post by FredK
VWS was only implemented on two graphics engines before it was retired -
a monochrome frame buffer, and the GPX graphics engine.
I think vws was available on the uVax II/GPX and the monochrome frame
buffer variant. around the vms 4.7 to 5.4 timeframe and was faster than
Decwindows on X, which really needed more memory and cpu throughput.
Decwindows ran far better on the later KA650 series.
It was known at the time that DW was being written that it would be slower
than VWS on existing HW. But that as HW got faster, it would not matter.
Post by FredK
UISX was implemented as a way to migrate VWS applications. UISX
implemented the entire VWS programming model on top of X11. In fact, the
application did not even need to be re-compiled.
That sounds like typical dec foresight :-)...
It only sounds like foresight. In reality, the DW program manager believed
that VWS use would ramp to zero in a linear ramp over a calendar year once
DW became available. This proved not to be true, and I proposed UISX as one
of a group of porting/migration tools.

I was amazed UISX worked as well as it did, but I'm not sure how much use it
ever saw. I ported it to Alpha (and even fixed the VAX version so that it
did not link against the system image to allow it to be VESTed) - but I'm
not sure Touch ever shipped the Alpha version.

Trivia note. UISX was originally named XUIS - but it had to be changed
because the X11 people wanted the name "XUI" and the copyright/trademark
people don't like things that end with "S" because you can't always tell if
the "S" is part of the name - or a plural, or posessive, etc.
Loading...