| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1839.1 | Transport programming doc now available | STAR::ORGOVAN | Vince Orgovan | Mon Dec 04 1989 18:18 | 5 |
| The transport programming interface, which was a private interface
in DW V1, was extensively changed in DW V2. User-written transports
are now supported, and the interface is documented in a new manual:
the VMS DECwindows Transport Manual. It is contained in the
DECwindows programming documentation kit for VMS V5.3.
|
| 1839.2 | Can we use the VMS manual for ULTRIX? | SICVAX::GRAHAM | if ya want home cookin, stay home | Tue Dec 05 1989 23:05 | 15 |
|
>The transport programming interface, which was a private interface
>in DW V1, was extensively changed in DW V2. User-written transports
>are now supported, and the interface is documented in a new manual:
>the VMS DECwindows Transport Manual. It is contained in the
>DECwindows programming documentation kit for VMS V5.3.
Is this *supported* for ULTRIX too?
My group is modifying an OSI/FDDI transport for a big phone comapny
to leverage a big RISC systems sale. Much of the stuff already
works...something to compare notes with will be very helpful.
Kris...
|
| 1839.3 | Didn't see Ultrix mentioned once | MOSAIC::HARRIS | Repeal the law of gravity: Juggle! | Wed Dec 06 1989 08:36 | 10 |
| Having read the manual in question, I can tell you that there is
nothing in there about Ultrix. It is 100% VMS oriented. The user
written transport is a VMS Sharable image, that is loaded dynamically
via the LIB$FIND_IMAGE_SYMBOL run-time library call.
On the other hand, I haven't seen any of the code that relates to how
Ultrix implements its TCP/IP and DECnet transports, so maybe there is
some commonality (but I wouldn't hold my breath :-).
Bob Harris
|
| 1839.4 | | DECWIN::FISHER | Burns Fisher 381-1466, ZKO3-4/W23 | Wed Dec 06 1989 11:56 | 3 |
| There is essentially nothing in common here.
Burns
|
| 1839.5 | | CRLMAX::jg | Jim Gettys, Cambridge Research Lab | Wed Dec 06 1989 15:15 | 15 |
| Currently, Ultrix supports 3 forms of transport. TCP/IP, Unix domain (on
machine IPC), and DECnet (if DECnet has been installed). Adding another is
simple, though right now you need sources.
There is no current way for a customer to add support for a different transport
in the server/X library (though the code is simple to add; it generally
affects only two files in the entire X system).
Your first mission, is to get OSI for Unix, tho Unix folks essentially all use
TCP/IP at the present time.... That is the big problem issue, not the X
support, which is a much easier problem.
I know of at least one FDDI thing underway for
certain future RISC workstations.
- Jim
|
| 1839.6 | medical imaging.... | SICVAX::GRAHAM | if ya want home cookin, stay home | Thu Dec 07 1989 00:19 | 19 |
|
Thanx for all the answers. Our customer wrote a transport
that works with OSI/FDDI networks....we were asked to modify
it - to make it work with X on multiple displays. The phone
company was interested in selling 'networks'(a la OSI/FDDI..)
to the medical imaging market (read hospitals, etc). In one
demo, digital had to show x-ray photos displayed across several
'networked' displays...all the doctors could interactively
diagnose a photo, make 'live' comments, be able to 'edit'
files associated with a particular patient (a la notes),
save the 'session', and more.
X, as we sell it today, does not have the capability required
to support this effort; the X transport and primitives had to
be modified to support applications requiring very high bandwidth;
usually not obtainable with regular ethernet and state-of-the-shelf
phone lines.
Kris..
|