From: teunis <teunis@computersupportcentre.com>
  To  : Rick Graham <rick@bitflash.com>
  Date: Sun, 7 Mar 1999 02:15:17 -0700 (MST)

Re: A Java VM that uses svgalib?

I'm running (current) snapshot of GGI (reccommend going with snapshots
here for those not following GGI development)

Anyways, if anyone's interested I should have an operational "java"
replacement for GGI sometime soon.

I'm just working on getting some substitute components working + basic
fonts and images.  Events was fun :)

I -can't- release any source yet because as a bit of a workaround while I
was busy trying to decide how to implement code pieces I substituted some
Java-1.2 source bits in.  These -will- be removed before anything is
released!

It's C++ in case that bothers anyone.  I'm also messing about with making
it both Java-1.1 and Java-1.2 complient (I -really- like Java 1.2 - it's
just not operational under Linux yet *sigh*)

If anyone else out there has attacked this PLEASE let me know!  I wouldn't
mind comparing notes...

G'day, eh? :)
	- Teunis

PS: *le really deep sigh*.  If Java-1.2 -were- operational under Linux,
this whole project would be done by now!

On Wed, 3 Mar 1999, Rick Graham wrote:

> {NOTE:this is a thread from the java-linux list, I'm cross posting it to
> ggi-develop because it's more relevant there.}
> 
> Jason Gilbert wrote:
> 
> > > > Do you think it would be a prohibitivly enormous undertaking to make the
> > > > vm work with svgalib?
> >
> > Maybe a better move would be to implement it using libggi?
> 
> I took a look at ggi, prominently displayed at metalab in /pub/ggi.  It seems
> like exactly the right animal.
> 
> I browsed the faq, I see it supports my Matrox card, svgalib doesn't, out of the
> box, anyway.
> 
> Getting it to function seems to be another matter...
> It doesn't seem to want to work with a 2.2.1 kernel. The README.INSTALL insists
> that the kernel be patched, but it refuses to deal with a 2.2 kernel.
> If I look in the patches directory, I see that there isn't one for a
> 2.2.anything.
> 
> This does seem like the way to go, but I don't particularily want to go back to
> a development kernel.
> 
> Any suggestions?