Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 / ST 1.0; site saber.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!zehntel!vlsvax1!qantel!intelca!t4test!saber!skinner
From: skinner@saber.UUCP (Robert Skinner)
Newsgroups: net.micro,net.micro.pc,net.graphics
Subject: Re: VDI Graphics Info
Message-ID: <1629@saber.UUCP>
Date: Mon, 20-May-85 13:53:53 EDT
Article-I.D.: saber.1629
Posted: Mon May 20 13:53:53 1985
Date-Received: Thu, 23-May-85 02:09:36 EDT
References: <58@drux1.UUCP>
Organization: Saber Technology, San Jose, CA
Lines: 69
Xref: watmath net.micro:10458 net.micro.pc:4019 net.graphics:786

> I'm in need of the following information about graphics drivers and
> libraries for VDI (Virtual Device Interface):
> 

Here's some info about what I learned working with DRI's VDI package
(no GEM) last year at another company:

> 	1.1. Can you break up DRI's package and just use the device
> 		interface and 'C' bindings or must you OEM the whole
> 		package just to use the VDI for graphics?
>
DRI's VDI package is available seperately.  I wish I could remember the
product name, but I just went completely blank.

> 	2. Are the 'C' bindings libraries included and the VDI driver
> 		the same as or compatable with GSS's?  DRI once did
> 		business with GSS.
> 
C bindings are not included with DRI's product, they are a separate package.
I would not recommend DRI's "bindings", I think they are a complete rip-off
and virtually useless, here's why:  The VDI interface is just a pointer to
an array of five pointers.  These five pointers point to a control array,
and integer and real arrays for input and output.  All of the information for
the function wanted is in the control array, and info for, say a polyline is
in the integer input array.  The ONLY thing in DRI's binding is ONE 'C'
routine with the first pointer as an arguement.  In other words, the programmer
is still faced with building up the structures needed for the DOS call.
The really iritating thing about this is that there is a BDOS call builtin
to DRI's 'C' language, which does exactly the same thing, no less.  What you
really want 'C' call for each function that looks something like:
v_pline( number_of_points, x_array, y_array ) to do a polyline.  Then let
the binding set up the silly data sturcture I know you don't want to worry 
about.  This is what GSS's bindings do.
	A word about the DRI-GSS relationship:  As I understand the folklore,
DRI's VDI was done by GSS for DRI.  The two companies parted ways when the
product was barely done.  To my knowledge, DRI has not expanded or fleshed
out the product, because they are in the operating systems business.  GSS on
the other hand has evolved the product, since it is the foundation for their
entire product line.  For example, there is absolutely no error checking in
DRI's VDI, whereas GSS does have error checking, at least at the binding level.
And, GSS has a real binding.

> 
> 	4. Phone number and address for GSS.

	25117 SW Parkway
	PO Box 673
	Wilsonville, OR 97070
	503-682-1606
> 
> 	5. Does anyone know of a VDI which is upgradable from [MS|PC]DOS
> 		to Unix and Xenix for graphics, plotters, printers and
> 		mice?

	GSS runs under Unix
> 
> 
> 	8. Do any of these do 3D and or rotation of objects?

	Not to my knowledge, but I know that GSS is working on 3D-GKS (3KS).

> 
> 	9. Ohhhhhhhhhh yeh! how about that nasty word ..... documentation!
>
	GSS gets my strong vote here too.

Robert Skinner
Saber Technology
San Jose, CA