3 Mar
1999
3 Mar
'99
8:49 a.m.
You want(ed) the console code to be small (so it would
fit into the
EPROMs), reliable (much harder to update than something on disk), and
possibly even to work on defective hardware (so you could do diagnostics).
I hadn't thought about the "defective hardware" angle.
My main
complaint is about the software rather than the hardware, as I think
I pointed out. In DOS, you can DO whatever you want (if you can find the
documentation and if you know the card will handle it) but the OS has no
concept of it. In Windows NT, the OS has a concept but it's VERY limited.
I think the console API only promises 16 colors, which is pretty pathetic
since even the EGA gives you a palette of 64. In my experience, NT just
makes the situation too unreliable.
Hmmm... As soon as you get to multitasking OS's, you really do need a way
for the OS to realise that a particular program is changing screen modes,
etc. Otherwise all hell will break loose. That's why MS-DOS lets you hit
the hardware directly, while NT (and linux for that matter) insist you
use the OS for this I guess, thought, you're moaning that NT
doesn't provide enough
functionality to do what you want. And unlike linux you can't add it in.
Right. :) The published graphics API for console-mode programs is very
weak. (A console program can run in a full-screen text mode or inside a
window on the desktop. It doesn't have to be a DOS program; it can use all
the services of NT.) You get less functionality than a real EGA card under
DOS would give you.
It could have something to do with the multiple-CPU design of NT. Actually,
though, I think MS just doesn't want to deal with the problem. They
probably don't see the irony, which is that they helped _create_ the problem
in the first place.
-- Derek