teunis <[EMAIL PROTECTED]> writes:
> I'm just remembering that GGI -> svgalib emu -> GGI isn't allowed...
That should work:
App does ggiOpen("svga", NULL), gets svgalib target which uses
svgalib emu.
Svgalib emu does ggiOpen(NULL), which returns another target.
What does not work is:
SVGAlib app -> svgalib emu -> GGI -> real svgalib
Which has obvious reasons:
App wants vgaFoo.
svgalib wrapper provides:
vgaFoo()
{
ggiFoo();
}
LibGGI svgalib target provides:
ggiFoo()
{
vgaFoo();
}
Real svgalib provides:
vgaFoo()
{
bang_vga_hardware();
}
Two things can happen:
a) vgaFoo is resolved to real svgalib - no LibGGI functions are
ever called.
b) vgaFoo is resolved to svgalib wrapper - infinite loop (well,
actually we detect this condition and terminate the app before
it eats up all the stack)
Technically this could be made to work with symbol versioning, if
you link the app against the svgalib wrapper at compile time.
Then we'd have:
App wants vgaFoo@@LIBVGA_WRAP_1_0
svgalib wrapper provides:
vgaFoo@@LIBVGA_WRAP_1_0()
{
ggiFoo();
}
LibGGI svgalib target provides:
ggiFoo()
{
vgaFoo();
}
Real svgalib provides:
vgaFoo()
{
bang_vga_hardware();
}
But it's hardly worth the effort.
> but XGGI -> XGGI -> ... -> oh, fbdev
> works.
XGGI is a separate program, different thing.
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
