Gut, das ist schon mal 'ne klare Ansage.
Da Du Windows-Programme schreibst (auch die Konsolapplikationen gehören
dazu), musst Du Dich bei Graphikausgaben auch an Windows orientieren.
Das ist leider deutlich komplizierter als der unter DOS beschrittene
Weg, wo man einfach in den Bildschirmspeicher schreiben konnte ...
Sofern Du wirklich in C (und nicht in C++) programmieren möchtest, lege
ich Dir die Lektüre des Standardwerks von Charles Petzold ("Programming
Windows") nahe, das beschreibt, wie man mit der Windows-API
Windows-Programme schreibt.
Da die Windows-Oberfläche ereignisorientiert arbeitet, sehen solche
Programme komplett anders aus als das, was Du von Konsolapplikationen
her gewöhnt bist - riesige switch/case-Statements, die auf alle
möglichen Nachrichten mit Codefragmenten reagieren und hier und da
etwas tun.
Etwas komfortabler ist da die Programmierung in C++, wenn denn eine
Klassenbibliothek verwendet wird, die die Windows-API abstrahiert.
Microsoft selbst liefert mit VC die MFC aus, die nicht ganz ohne Grund
einen schlechten Ruf hat; sie ist ziemlich lausig dokumentiert, recht
unstrukturiert aufgebaut und man merkt ihr ihr Alter an.
Das heißt nicht, daß man nicht mit MFC programmieren kann; ich mache
das seit annähernd zehn Jahren recht erfolgreich, aber mittlerweile
gibt es auch Alternativen, die lohnenswert sind.
Für MFC lohnenswerte Literatur sind Jeff Prosise, "Programming Windows
with MFC" und der Kruglinski (Titel ist mir im Moment entfallen) sowie
Shepherd/Wingo "MFC Internals".
Alternative Klassenbibliotheken, die sich mit VC einsetzen lassen,
wären Trolltechs QT, das derzeit allerdings nur mit dem Einsatz von
ziemlich viel Geld zu bekommen ist (was sich allerdings in absehbarer
Zeit ändert; Trolltech stellt demnächst auch die Windows-Portierung von
QT unter die GPL) und wxWidgets. Letzteres ist frei verfügbar
(www.wxwidgets.org) und IMHO gar kein so schlechter Ansatz.
Ein auch nicht zu unterschätzender Vorteil sowohl von QT als auch von
wxWidgets ist die Unabhängigkeit vom Compiler und auch vom
Betriebssystem - beide sind auch für Mac OS und Linux verfügbar, so daß
sauber dafür geschriebene Anwendungen leicht portierbar sein sollten.
wxWidgets kann man mit so gut wie jedem für Windows verfügbaren
32-Bit-Compiler einsetzen, auch QT ist nicht an VC gebunden.
Dennoch:
Auch mit so einer Klassenbibliothek ist das
einfach-mal-so-'ne-Graphik-ausgeben ein ganz schön umständlicher
Aufriss, aber das liegt daran, daß die Graphikkarte dem Betriebssystem
und der graphischen Oberfläche "gehört" und obendrein auch eine
adäquate Abstraktionsebene für Devicetreiber erforderlich ist.
Ein alternativer Ansatz wäre die Beschäftigung mit DirectX, das ist die
Spieleprogrammierschnittstelle von Windows, bei der deutlich direkterer
Zugriff auf die Graphikhardware möglich ist.
Ich sehe darin allerdings kein erstrebenswertes Ziel, da einerseits
Portierbarkeit in die weite Ferne rückt und andererseits eine etwaige
Programmoberfläche (Eingabemasken etc.) komplett selbst entwickelt
werden müsste, obwohl Windows sowas ja eigentlich ganz gut unterstützt
...
