| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 141.1 | as I remember it... | XUI::VANNOY | Jake VanNoy | Tue Feb 07 1989 12:28 | 29 |
| There is a spec in VMSKIT::DECW$PUBLIC:[SPECS]DECW$PSEUDO_DEVICE.[LN03 ! POST].
There were multiple problems.
One problem was that we foresaw a need to provide more information than the
MIT formatted string would allow. Being able to specify more transports
than DECnet and TCP was one such example.
Another problem was the multi-head, multi-user workstation. In UIS, the
system-wide logical name SYS$WORKSTATION caused more problems with respect
to solving this problem than almost any other aspect. We knew from experience
that system-wide logicals were bad news.
Getting logical names defined in a newly created process context isn't possible
with $CREPRC unless you want one of (SYS$INPUT, SYS$OUTPUT and SYS$ERROR).
This is why the notion of a device that is essentially a information pool
got invented.
I don't think I remember all of the details, the spec has some goals and
rationalization.
It really doesn't buy much in VMS for V1 over NODE::server.screen, but there
are futures planned that will make it more valuable. It makes setting up
remote sessions to X-terminals easier, for example.
The big problem with them now is there isn't any choice over how long they
persist. Fixing this is on the VMS DECW V2 list, I believe.
jake
|
| 141.2 | | MU::PORTER | Exiled in Cyberia | Tue Feb 07 1989 13:32 | 6 |
| (I'll get the spec, thanks)
So you're saying that no X traffic actually flows through the WSAx unit,
it's just a box of information?
|
| 141.3 | | XUI::VANNOY | Jake VanNoy | Tue Feb 07 1989 13:59 | 10 |
| Yes, if you do reads/writes to a WSA device, you'll get the same
behavior as the null device (NLA0). (Except for a bug that prevents RMS
from talking to the device.)
When your application calls XOpenDisplay, that routine does essentially
what SHOW DISPLAY does to get the information about what to connect to and
what transport to use. After the call to XOpenDisplay, the device never
gets involved again.
|
| 141.4 | hmm, you find out useful things when you ask questions... | MU::PORTER | Exiled in Cyberia | Tue Feb 07 1989 14:33 | 16 |
| Ha! Now I have read your spec, I have discovered the happy news that
XOpenDisplay(0) doesn't necessarily need DECW$DISPLAY. It will fall back
to SYS$OUTPUT.
Thus, when running applications as detached processes rather than subprocesses,
it is not usually necessary to go through the contortions of running
LOGINOUT as an image with a .COM file as input and defining DECW$DISPLAY
in the .COM file and finally running the application.
The following works just as nicely:
$ RUN/DET/INP=_NLA0:/OUT=_WSAn:/PROC=appl SYS$SYSTEM:DECW$appl
(note, this assumes the application has no requirements to be run
under a CLI, which is necessarily application-dependent).
|
| 141.5 | | PRNSYS::LOMICKAJ | Jeff Lomicka | Tue Feb 07 1989 20:08 | 3 |
| Wow! That's great news!
|