From: Salvador Eduardo Tropea (SET) <salvador@inti.gov.ar>
  To  : James A Simmons , ggi-develop@eskimo.com
  Date: Fri, 10 Jul 1998 12:28:22 +0000

Re: Out of the chaos

James A Simmons <jsimmons@acsu.buffalo.edu> wrote:

> IV. KGI.
> 
>    YAH HO !!!!. Its going into the kernel. We won the battle with the
> kernel guys now to win the war with the companies. I love the idea of a
> kgi core that is OS indepenent. All you need to do is link a wrapper for a
> particular OS. We need to remove pcibios_dword etc from KGI's core. This
> is linux specific. I like to thank the companies that are helping us out.
> Unfortunely their are alot of companies that are not like this. Please
> don't send me hate mail about this but we need to write windows 95, 98 and
> NT wrappers for kgi.

Avoid using these words directly, they have a big "negative power", 
use Winblows or similars ;-)))

> If companies are every going to consider to use what
> we are doing we have to convert their current drivers to kgi. Unfortunely
> most companies make only windows drivers. Writing a driver for windows is
> essential like a module so for companies that don't want to give out their
> source could develope a kgicore.o and link to to various OS wrappers.
> Also this shouldn't conflict with the license. Correct me if I am wrong. 
> We would also need wrappers for macOS. Alot of companies support these
> guys even though their are alot more linux users than macOS. Figure that
> one out. Then for linux drivers we could download the kgicore.o and link
> it with the fb-kgi.c wrapper and wha la or if the companies are nice they
> could ship the linux drivers. Some points to make about KGI:
> 
>     one:
> 	kgicore.o will be OS indepenent, 

What do you mean with a .o OS independent? I don't understand it. 
Isn't .o files object files? Then: how do you plan to link the same 
.o with a Win32 linker and with ld? The companies must supply more 
than one ... that's too much for the lazy people. I think plain 
binaries are more suitable for that ... and that's make me remmember 
the VBE/AF drivers (relocatable binaries).

>    based only on the cards hardware
>         right. Now take this from the companies perspective. Say I am a
>         company that makes high end expensive graphics cards that can do
>    	amazing things. This is where my marketing is. Now I look at these
> 	kgi drivers and say. Their niece but I can't use the advance
>         features of my card. Why should I use teh kgi driver if teh kgi
>         driver makes my $500 card use the same features as a cheap $50
>         card. Point is we need to add all the advance features of a card
>         into kgi.

Hmmm ... I agree in some points but: To make a driver specification 
for advanced features you must know a lot about these advanced 
features and they are normally "secrets" the companies doesn't want 
to release. I know about only two that can do such a thing: Micro$oft 
(ugh!) and VESA. The first because the companies know that the market 
is there, the second because they are the companies. I think you'll 
never have a general specification without the help of the 
company leaders (read without the help of the people that makes 
Voodoo chips, etc) or not at least just-in-time. You'll be 1 or 2 
steps behind and then will be very difficult to atract companies. 
Just an opinion, not much.

>  Make a OS indepenent interface to these features and let
> 	the OS wrapper take care of turing that OS indepenent feature into
> 	a OS API. 

Yes.

SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft@usa.net set@computer.org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013