Subject:
RE: nano-X 0.6
From:
Greg Haerr ####@####.####
Date:
17 Jun 1999 20:10:56 -0000
Message-Id: <01BEB8C9.BD414060.greg@censoft.com>
: > * created new win32 api: Micro-Win
:
: Does that mean that the win32 API is integrated into Nano-X? How does it
: work? Can you compile out Win32 support if you don't want it?
There's two makefiles, one for nano-X, one for micro-windows. Both
share the same dev*.c files, which is the nano-engine. The nano-engine Gd*() api
runs is device-independent and runs on top of the device-dependent screen, kbd
and mouse drivers.
The srv*.c code (4 files) implements the mini-x api. The win*.c code
implements the win32 api. You can build an executable that supports mini-x
or win32, but not both. The demo programs are linked in to the exe as well,
using the public header for the api (nano-X.h for mini-x, windows.h for win32).
:
: > * created window manager and overlapped window border drawcode
:
: How does the window manager API work? Is it along the lines of the spec I
: posted a few weeks ago or more like the way X11 does it?
The window manager is implemented underneath the win32 CreateWindow,
DestroyWindow, MoveWindow and BeginPaint routines. In the win32 model,
window management is ever-present in the system. the mini-x api
has no window manager as of yet. I wrote the micro-windows implementation
first since I happen to know win32 inside and out, and wanted to test the underlying
windows engine, and found quite a few problems.
:
: > * fixed console refresh bug for BOGL
:
: Are you still using the original Bogl version with only 8Bpp support?
Yes, but I moved all the upper-level bogl dependencies like
screen refresh and vt switching out of any common dev*.c code. This can
be handled totally at the driver level, which is how svgalib does it. (we run
on that now, too) I didn't do too much work with bogl because I knew
that you were working on it, and that nano uses less and less entry points
in bogl. For instance, we don't use any text or cursor output routines anymore.
This changed when the decision was made to perform clipping at the mid level,
a big architectural change.
Unfortunately, I can't get the damned 32 or 24 bpp framebuffers to work
on my mach64 card... Any help here would be *greatly* appreciated.
I would love to integrate the truecolor bogl drivers.
Another change is that I took the "VGA planar" stuff from the original
vga bogl driver and placed it into another file, since it really isn't framebuffer oriented,
but vga oriented. As a result, we now have bare vga hardware drivers for DOS and ELKS.
The same thing needs to happen with the current bogl stuff, if we want to use the drivers
to run on bare hardware, which I think is a good idea. Let me know if you want more info on
this idea.
: > * Added pc, microsoft and logitech direct serial driver mouse support
:
: How does your mouse driver system work? Is it table based like GPM and
: GII? I wonder whether it's worth me carrying on with the GII based one
: I've been working on or not if you've written one too...
No - keep going with your work too. Mine's not table based, but is a
quick put-together that implements PC, MS and logitech protocols, but doesn't
require GPM or fifos, or any OS, for that matter. It was written to run on
almost bare hardware (it needs a serial port from the os, but I'm going to throw in
a serial driver for pc's as well, so that nano can boot from floppy and run without
an os...)
:
: > Version 0.5 - 18th May 1999 - ####@####.####
:
: As I've said at least four times, the one you submitted as your 0.5
: candidate got released almost exactly as 0.5pre1.
:
Thanks - I agree with everybody that it's hard to keep these versions straight!
My work doesn't include your directory and file renaming that occurred afterwards.
