Mail Archives: djgpp/1994/10/28/19:06:10
> (1) To avoid having to keep writing and updating a mass of graphics driver
> files to find how to map Gnu C graphics modes onto VGA or VESA screen modes
> for each new sort of PC monitor, why not someone write a function that
> automatically finds what modes there are and maps accordingly? Such a function
> is possible (e.g. I recently got a package called C:\CLUTIL\*.* (by Cirrus
> Logic) which seems to automatically find what modes are possible and all about
> each mode and displays a menu for the user to choose which).
That's if you already know what kind of card you have. The detection
logic could, in theory, cause problems if it tries to detect the wrong
card.
> (2) The Great Enemy of Gnu and of Gnu-users seems to be things loaded high.
I've never seen that. Lack of memory, yes, but it doesn't use high
memory anyway (well, for go32 it doesn't).
> (3) When go32 finds that the PC is in V86 (or whatever is it) mode instead
> of in real mode, why can't it simply change the mode to real?
Because being in V86 mode keeps you from running the opcodes required
to switch back. If I could do that, I wouldn't need the error
messages.
> (4) How much work would it involve to give djgpp a mode that compiled and
> assembled and linked to make an .EXE file (not needing go32 to run it) in
> non-paged mode like Turbo C does? That is e.g. so that people developing Gnu C
> don't have to clutter their hard disks up with Turbo C as well as Gnu C,
> simply to be able to compile go32. And for other purposes where compilation
> into non-paged mode is needed.
It would be like porting gcc to an entirely new CPU almost from
scratch.
In V2.0, there is no go32 any more, so you won't need turbo c to
bootstrap yourself. You will, however, need a DPMI server, and we've
been able to mutate go32 into a standalone DPMI server which does need
tcc to compile, but you could use qdpmi, 386max, or windows instead.
- Raw text -