@Charlie: Mir gefällt dein Konzept und wenn du ggf. einige ASCII ein anderes aussehen gibst, dann sollte damit schon vieles leichter werden.
Im Zweifelsfall finde ich Konfigurationsdateien recht sinnvoll, wenn man Hand anlegen möchte und es so nicht auf anhieb funktioniert. Alternativ könnte man so auch den Benutzer erlauben einen Zeichensatz seiner Wahl nachzuladen, damit er selber dafür sorgen kann, das es so klappt wie er möchte. Auch ein schon veröffentlichtes und sich im Umlauf befindliches Programm kann später mit einem PATCH/Adddon erweitert und verbessert werden, wenn es schon so vorgesehen wurde um Erweiterungen zu ermöglichen. Der Krativität sind damit quasi keine Grenzen gesetz.

Dirk

"den Befehl *gotoXY* kannte ich unter C so noch nicht ;-) ."

Wie ich bereits sagte: "Das gotoxy gibt es auch in C. Aber eben nur beim Borland-Compiler." Das war eine Antwort darauf, dass es gotoxy in Pascal gab. Damit wollte ich nicht sagen, dass es Teil von Standard-C ist, nur dass Pascal nicht die einzige Sprache ist, der Borland ein gotoxy spendiert hat.


"Du willst dir also eine *Nativ-Library* in C schreiben, welche von jedem C-Compiler, der Standard-C unterstützt, includiert werden kann und auch fehlerfrei geschluckt wird."

Jeder Standard-C-*DOS*-Compiler. Ich spreche natürlich nicht davon, dieselbe Implementierung auch unter Win32-Konsole oder Linux zum Laufen zu bringen.
Und es wird keine Lib mit möglichst umfassenden Funktionen, sondern ich will nur ein einziges Spiel damit programmieren und da kommt dann nur das Zeug rein, was ich brauche. Zum Beispiel brauche ich in meinem Fall gar kein gotoxy oder textcolor, da ich die aktuelle Spielszenerie pro Frame einfach direkt per memcpy in den Grafikspeicher schreibe.

"Daraus folgt dann, daß das fertige Compilat ist dann auch in einer Dos-Umgebung, welche auch nur aus einer nur aus einer *command.com* auf Diskette besteht, lauffähig ist."

Sagen wir mal so: Sofern ein kompiliertes

#include <stdio.h>

int main()
{
printf("Hallo");

return 0;
}

unter der von Dir genannten Umgebung lauffähig ist, soll auch mein Programm lauffähig sein.


"Später sollte man dann damit auch in der Lage sein, einen Snake- bzw. Pong-Klon zu schreiben, welcher auf einem Bootblock einer Diskette Platz findet und von dort gestartet wird ;-) ."

Wenn es Platzprobleme gibt, wird es wohl nicht laufen. :roll: Das ist aber Wortklauberei und hat nichts mit der Intention zu tun, weshalb ich ursprünglich gesagt habe, dass es "überall" laufen soll.


"Ich bin jetzt nicht der Dos-Experte, aber bist du sicher, daß man unter diesen Vorraussetzungen jetzt auch mehr als den ASCII-Standard des Zeichensatzes verwenden problemlos kann?"

Wieso nicht? Gibt es etwa Datentypen, die nur sieben Bit groß sind? Ein char ist doch in C immer ein Byte groß, oder? Wo sollte es also Probleme geben? Das schlimmste, was passieren kann, ist, dass er die Zeichen falsch anzeigt. Und ich sagte ja schon: Da der Zeichensatz von sonstwo geladen wird und nicht überall auf gleiche Weise zur Verfügung steht, muss man neben dem Hauptprogramm sowieso noch für jedes System irgendeine Batch-Datei oder dergleichen mitgeben, die die Codepage umstellt. Das liegt dann nicht mehr in der Verantwortung des Programms.

Hallo Charlie,

den Befehl *gotoXY* kannte ich unter C so noch nicht ;-) .

Die PDCurses kann sogar noch mehr, steht aber dann für dein Projekt außer Frage.

Wenn ich es jetzt richtig verstehe und ein wenig übertreiben darf:

Du willst dir also eine *Nativ-Library* in C schreiben, welche von jedem C-Compiler, der Standard-C unterstützt, includiert werden kann und auch fehlerfrei geschluckt wird.
Naturgemäß will man dann natürlich auch so viele Funktionen wie nur möglich sind, darin vereinen.

Daraus folgt dann, daß das fertige Compilat ist dann auch in einer Dos-Umgebung, welche auch nur aus einer nur aus einer *command.com* auf Diskette besteht, lauffähig ist.

Später sollte man dann damit auch in der Lage sein, einen Snake- bzw. Pong-Klon zu schreiben, welcher auf einem Bootblock einer Diskette Platz findet und von dort gestartet wird ;-) .

Ich bin jetzt nicht der Dos-Experte, aber bist du sicher, daß man unter diesen Vorraussetzungen jetzt auch mehr als den ASCII-Standard des Zeichensatzes verwenden problemlos kann?

Das gotoxy gibt es auch in C. Aber eben nur beim Borland-Compiler. Und genau das ist das Problem: Versuch mal, so einen Code mit Visual C++ 1.52c oder DJGPP zu kompilieren. Das geht nicht, weil dafür die Bibliothek fehlt. Also sollte man von vornherein das gotoxy selbst implementieren, und zwar mit int86 und union REGS. Dann kann das nämlich auch jeder DOS-Compiler.

Was nun generelle externe Bibliotheken angeht, die möglichwerweise sogar Open Source sind: Ich verstehe ja, dass man sich OpenGL nimmt, wenn man ein 3D-Spiel programmieren will. Aber wenn ich eine kleine Konsolenanwendung mit vielleicht 20 Codedateien habe, dann muss es ja echt nicht sein, dass ich die dann von irgendeiner X-beliebigen NoName-Lib abhängig mache, statt die besagten Punkte, die ja nun auch nicht *so* schwer sind, mit Standard-C und der dos.h selbst zu programmieren und somit ein in sich völlig geschlossenes Quellcodeprojekt zu besitzen. Erst recht nicht, wenn ich nur ein winzig kleines Feature aus dieser Bibliothek benutzen will. (Und ich bin mir nicht mal sicher, ob PDCurses *überhaupt* eine Funktion besitzt, um die Codepage zu ändern. Das Ding sieht mir eher danach aus, als wenn man damit Konsolengröße, Farben, gotoxy etc. realisieren kann, und das brauch ich gar nicht, weil ich bereits weiß, wie das geht.)

[quote="Charlie"]Hallo,
Und freecrac hat recht: Mein Programm soll weder externe Programme aufrufen, noch will ich in meinem Code Fremdbibliotheken verwenden.
Ersteres ist so, weil man sich dann nie sicher sein kann, dass es auch funktioniert. Es gibt ja keine Garantie, dass eine bestimmte Exe-Datei auf dem System des Anwenders vorhanden ist. Er kann das Spiel in MS-DOS 5 ausführen oder im Windows 98-DOS-Modus oder von einer Startdiskette oder in DOSBox oder sonst wo. Deshalb soll mein Programm unabhängig von jeglichen Dateien auf der Festplatte sein, die nicht selbst zum Spiel gehören.
Zweiteres ist einfach so, weil ich möglichst unabhängig bleiben will. Es macht ja Sinn, sich für ein großes 3D-Spiel auch ein großes externes Framework zu nehmen, aber so ein kleines Textgrafikspiel sollte auch möglich sein, ohne dass ich mich gleich von einer Drittanbieterbibliothek abhängig mache. In meinem Programm will ich also nur Funktionen benutzen, die in Standard-C und in der dos.h vorhanden sind. Selbst die conio.h ist tabu.
[/quote]


Hallo,
so habe ich auch in Zeiten gedacht, wo ich noch Assembler-Fanatiker war, was aber nicht abwertend gemeint ist. Im Gegenteil, der Lernfaktor ist dabei enorm hoch ;-) .

Da du aber in C und auch verd....t nahe an der Hardware programmieren willst, würde ich an deiner Stelle unter anderem sogar die Quellcodes der Bibliotheken ansehen und untersuchen, wie es dort klappt, denn irgendwie muss es ja dort auch gelöst sein.

100%ige Lauffähigkeit auf jeder PC-Architektur ohne Hilfe von Fremdbibliotheken oder Treibern, halte ich persönlich für fast unmöglich dann auch nur in einem sehr engem Kreis der Möglichkeiten.
Dies soll aber jetzt niemanden von etwas abhalten, ist hier wirklich nur meine ganz persönliche Meinung dazu.

Als Tip von mir dazu:
Ich glaube mich daran zu Erinnern, daß es standardmäßig in Pascal einen Befehl gab, der sich "gotoXY()" oder so ähnlich nannte und zumindes Cursor-Positionierungen in Dos, wie auch in Linux auf der Konsole möglich machte. Keine Ahnung, wie es dort geklappt hatte, aber ich habe mir dort auch noch nie die Frage nach dem Wie gestellt, war ja nicht Assembler ;-).

Vielleicht konnte ich dir damit ein wenig helfen und wünsche dir noch viel Erfolg.

Grüße.

--------V-101130-----------------------------
INT 10 - VIDEO - GET FONT INFORMATION (EGA, MCGA, VGA)
	AX = 1130h
	BH = pointer specifier
	    00h INT 1Fh pointer
	    01h INT 43h pointer
	    02h ROM 8x14 character font pointer
	    03h ROM 8x8 double dot font pointer
	    04h ROM 8x8 double dot font (high 128 characters)
	    05h ROM alpha alternate (9 by 14) pointer (EGA,VGA)
	    06h ROM 8x16 font (MCGA, VGA)
	    07h ROM alternate 9x16 font (VGA only) (see #00021)
	    11h (UltraVision v2+) 8x20 font (VGA) or 8x19 font (autosync EGA)
	    12h (UltraVision v2+) 8x10 font (VGA) or 8x11 font (autosync EGA)
Return: ES:BP = specified pointer
	CX    = bytes/character of on-screen font (not the requested font!)
	DL    = highest character row on screen
Note:	for UltraVision v2+, the 9xN alternate fonts follow the corresponding
	  8xN font at ES:BP+256N
BUG:	the IBM EGA and some other EGA cards return in DL the number of rows on
	  screen rather than the highest row number (which is one less).
SeeAlso: AX=1100h,AX=1103h,AX=1120h,INT 1F"SYSTEM DATA",INT 43"VIDEO DATA"

Format of alternate font table [array]:
Offset	Size	Description	(Table 00021)
 00h	BYTE	character to be replaced (00h = end of table)
 01h  N BYTEs	graphics data for character, one byte per scan line

[quote="Charlie"]Hallo,
vielen Dank erst einmal für die vielen Antworten. Gehen wir die einzelnen Punkte mal durch:

Zum Thema eigene Zeichensätze benutzen: Ich glaube, das wäre Overkill. Ich möchte schon die Zeichen benutzen, die das jeweilige System mitbringt und nicht meine eigenen Zeichengrafiken in den Speicher laden.

Die Frage, wie es sich in Windows im Fenstermodus verhält, ist erstmal nebensächlich. Da es ja tatsächlich ein DOS-Programm wird und keine Win32-Konsolenanwendung, ist die Behandlung der Darstellung im Windows-Konsolenfenster auch nicht Aufgabe des Programms. Dieses Problem kann hier also ignoriert werden. Es geht wirklich nur darum, dass es in DOS funktioniert.

Und freecrac hat recht: Mein Programm soll weder externe Programme aufrufen, noch will ich in meinem Code Fremdbibliotheken verwenden.
Ersteres ist so, weil man sich dann nie sicher sein kann, dass es auch funktioniert. Es gibt ja keine Garantie, dass eine bestimmte Exe-Datei auf dem System des Anwenders vorhanden ist. Er kann das Spiel in MS-DOS 5 ausführen oder im Windows 98-DOS-Modus oder von einer Startdiskette oder in DOSBox oder sonst wo.[/quote]
Wenn die Anwendung in der DOSBox aber nicht im Fenstermode laufen soll, dann muss man aber das Fenster in den Vollbildmode umschalten können. Ich vermute mal das ein kurzzeitiges Umschalten in den MCGA-Mode und zurück in den Textmode auf jeden Fall unser Fenster in den Vollbildmode zwingt. Denn mit dem alleinigen Schalten in den Textmode geht es bei mir unter XP nicht. (Ich habe leider kein W98 installiert um es damit auszuprobieren.)

[quote]Deshalb soll mein Programm unabhängig von jeglichen Dateien auf der Festplatte sein, die nicht selbst zum Spiel gehören.
Zweiteres ist einfach so, weil ich möglichst unabhängig bleiben will. Es macht ja Sinn, sich für ein großes 3D-Spiel auch ein großes externes Framework zu nehmen, aber so ein kleines Textgrafikspiel sollte auch möglich sein, ohne dass ich mich gleich von einer Drittanbieterbibliothek abhängig mache. In meinem Programm will ich also nur Funktionen benutzen, die in Standard-C und in der dos.h vorhanden sind. Selbst die conio.h ist tabu.

Nun zum eigentlichen Thema: Soweit ich das jetzt mitbekommen habe, muss DOS die Codepages selbst erstmal aus Dateien lesen, stimmt's?[/quote]
Einige Charaktertabellen mit deutschen Umlauten sind im ROM bei den hier bei uns erhältlicher GraKas bereits enthalten und man kann auch ohne einen Treiber(unter purem DOS) darauf zugreifen.
Beispielsweise auf die 8x8-Charaktertabelle auf die der Pointer in 1Fh * 4 zeigt, bzw. dessen Pointer wir uns mit folgender Biosfunktion in die Register nach ES:BP holen können:
(Bei dieser Adresse beginnt die Charaktertabelle: Bei 8x8 für jedes Zeichen 8 Bytes.)

RBIL->inter61a.zip->Interrup.a
[code]
--------V-101130-----------------------------
INT 10 - VIDEO - GET FONT INFORMATION (EGA, MCGA, VGA)
AX = 1130h
BH = pointer specifier
00h INT 1Fh pointer
01h INT 43h pointer
02h ROM 8x14 character font pointer
03h ROM 8x8 double dot font pointer
04h ROM 8x8 double dot font (high 128 characters)
05h ROM alpha alternate (9 by 14) pointer (EGA,VGA)
06h ROM 8x16 font (MCGA, VGA)
07h ROM alternate 9x16 font (VGA only) (see #00021)
11h (UltraVision v2+) 8x20 font (VGA) or 8x19 font (autosync EGA)
12h (UltraVision v2+) 8x10 font (VGA) or 8x11 font (autosync EGA)
Return: ES:BP = specified pointer
CX = bytes/character of on-screen font (not the requested font!)
DL = highest character row on screen
Note: for UltraVision v2+, the 9xN alternate fonts follow the corresponding
8xN font at ES:BP+256N
BUG: the IBM EGA and some other EGA cards return in DL the number of rows on
screen rather than the highest row number (which is one less).
SeeAlso: AX=1100h,AX=1103h,AX=1120h,INT 1F"SYSTEM DATA",INT 43"VIDEO DATA"

Format of alternate font table [array]:
Offset Size Description (Table 00021)
00h BYTE character to be replaced (00h = end of table)
01h N BYTEs graphics data for character, one byte per scan line
[/code]
Im DOS-Fenster unter XP bekomme ich aber Umlaute wenn ich auf eine entsprechende Umlaut-Taste drücke. Um unter purem DOS ohne Treiber ein Umlaut beim Drücken von Tasten zu bekommen, muss man aber ganz andere Tasten drücken, da hier die Zuordnung auch anders ist, wenn kein Treiber geladen wurde.

[quote]Ich hatte gehofft, dass die beim Start alle irgendwo in den Speicher gelegt werden und ich dann entweder mit union REGS und int86 oder durch direkte Speicherbearbeitung mit MK_FP den Verweis im Speicher von der einen auf die andere Codepage umsetzen kann. Oder dass es zumindest eine Funktion gibt, die selbst in den richtigen Dateien nachsieht, ohne dass ich den Pfad angeben muss. Aber solange es wirklich IMMER nötig ist, dass man beim Umschalten der Codepage erstmal explizit eine Datei, wie zum Beispiel C:\<WasAuchImmer>\ega.cpi, angeben muss, hat sich das Thema wahrscheinlich erledigt. Dann ist das Umschalten der Codepage nämlich ebenfalls nicht Aufgabe des Programms. Ich hatte gehofft, dass es in DOS etwas analoges zur Windows-Funktion SetConsoleOutputCP gibt. Wenn dem doch so ist, wäre ich über weitere Hilfe sehr dankbar.[/quote]
Ich vermute welche Chartakter-Tabellen im Bios der GraKa vorhanden sind hängt ganz davon ab, wo man die GraKa kauft. So vermute ich das auf japanischen GraKas keine deutschen Umlaute im Bios vorhanden sein, so das man für deutsche Umlaute dann auf jeden Fall Codepage-Dateien verwenden muss. Also mit universell einsetzbar wird es ohne externe Daten gar nicht gehen, da sich das ROM der Graka und auch die Tastaturen hierbei wesentlich voneinander unterscheiden.

Dirk

[quote="DOSferatu"]Ich schalte immer kurz in den MCGA-Mode:
MOV AX,13h
INT 10h

Das muß ich auch übrigens machen, wenn ich testen will, ob VESA-Modi vorhanden sind, bzw diese benutzen. Denn komischerweise meldet Windows kein VESA, wenn man's im Fenstermode macht. (Den Trick hab ich irgendwann selbst mal rausgefunden.)[/quote]
Aha.

Frisch nach der Installation von Windows XP, wenn noch kein GraKa-Treiber installiert ist, dann wird auch noch kein VESA emuliert. Das funktioniert erst wenn ein GraKa-Treiber installiert wurde.

Wenn ich nach der Installation des [i]NVIDIA[/i]-GraKa-Treibers im DOS-Fenster(kein Vollbildmode) "mov ax, 4F00h + mov di, OFFSET Buffer + int 10h" ausführen lasse, dann wechselt das Fenster in den Vollbildmode und der Buffer wird mit dem Vesa-Info gefüllt.
Mit ALT+Enter wechsel ich nun wieder zurück in den Fenstermode. Nun lasse ich "mov ax, 4F01h + mov cx, Vesamode + mov di, OFFSET Buffer + int 10h" ausführen und dabei wird wieder in den Vollbildmode gewelchselt und der Buffer mit dem Mode-Info gefüllt.
Mit welcher GraKa und welchem GraKa-Treiber geht das so nicht im Fenstermode?

Dirk

Hallo,
vielen Dank erst einmal für die vielen Antworten. Gehen wir die einzelnen Punkte mal durch:

Zum Thema eigene Zeichensätze benutzen: Ich glaube, das wäre Overkill. Ich möchte schon die Zeichen benutzen, die das jeweilige System mitbringt und nicht meine eigenen Zeichengrafiken in den Speicher laden.

Die Frage, wie es sich in Windows im Fenstermodus verhält, ist erstmal nebensächlich. Da es ja tatsächlich ein DOS-Programm wird und keine Win32-Konsolenanwendung, ist die Behandlung der Darstellung im Windows-Konsolenfenster auch nicht Aufgabe des Programms. Dieses Problem kann hier also ignoriert werden. Es geht wirklich nur darum, dass es in DOS funktioniert.

Und freecrac hat recht: Mein Programm soll weder externe Programme aufrufen, noch will ich in meinem Code Fremdbibliotheken verwenden.
Ersteres ist so, weil man sich dann nie sicher sein kann, dass es auch funktioniert. Es gibt ja keine Garantie, dass eine bestimmte Exe-Datei auf dem System des Anwenders vorhanden ist. Er kann das Spiel in MS-DOS 5 ausführen oder im Windows 98-DOS-Modus oder von einer Startdiskette oder in DOSBox oder sonst wo. Deshalb soll mein Programm unabhängig von jeglichen Dateien auf der Festplatte sein, die nicht selbst zum Spiel gehören.
Zweiteres ist einfach so, weil ich möglichst unabhängig bleiben will. Es macht ja Sinn, sich für ein großes 3D-Spiel auch ein großes externes Framework zu nehmen, aber so ein kleines Textgrafikspiel sollte auch möglich sein, ohne dass ich mich gleich von einer Drittanbieterbibliothek abhängig mache. In meinem Programm will ich also nur Funktionen benutzen, die in Standard-C und in der dos.h vorhanden sind. Selbst die conio.h ist tabu.

Nun zum eigentlichen Thema: Soweit ich das jetzt mitbekommen habe, muss DOS die Codepages selbst erstmal aus Dateien lesen, stimmt's? Ich hatte gehofft, dass die beim Start alle irgendwo in den Speicher gelegt werden und ich dann entweder mit union REGS und int86 oder durch direkte Speicherbearbeitung mit MK_FP den Verweis im Speicher von der einen auf die andere Codepage umsetzen kann. Oder dass es zumindest eine Funktion gibt, die selbst in den richtigen Dateien nachsieht, ohne dass ich den Pfad angeben muss. Aber solange es wirklich IMMER nötig ist, dass man beim Umschalten der Codepage erstmal explizit eine Datei, wie zum Beispiel C:\<WasAuchImmer>\ega.cpi, angeben muss, hat sich das Thema wahrscheinlich erledigt. Dann ist das Umschalten der Codepage nämlich ebenfalls nicht Aufgabe des Programms. Ich hatte gehofft, dass es in DOS etwas analoges zur Windows-Funktion SetConsoleOutputCP gibt. Wenn dem doch so ist, wäre ich über weitere Hilfe sehr dankbar.

Ich schalte immer kurz in den MCGA-Mode:
MOV AX,13h
INT 10h

Das muß ich auch übrigens machen, wenn ich testen will, ob VESA-Modi vorhanden sind, bzw diese benutzen. Denn komischerweise meldet Windows kein VESA, wenn man's im Fenstermode macht. (Den Trick hab ich irgendwann selbst mal rausgefunden.)

[quote="Gast"]Für Linux neben Curses:
http://www.faqs.org/docs/Linux-HOWTO/NCURSES-Programming-HOWTO.html

Für DOS:
http://pdcurses.sourceforge.net/[/quote]
Das ist sicherlich ein guter Tip. Doch Charlie möchte ja nicht einmal "nlsfunc.exe" verwenden, mit dem es ja auch schon funktionieren würde.
Es sollen also nur Möglichkeiten genutzt werden die man in einer Anwendung unmittelbar selber integrieren kann, so dass externe Anwendungen dafür nicht benutzt werden brauchen.

Dirk

Ist es eine sichere Methode eine DOS-Anwendung (welches man in der DOS-Box startet) in den Vollbildmode zu zwingen, wenn man bespielsweise folgende Befehle verwendet?:
"mov ax, 4F00h + mov si, 0F800h + int 10h"

Gibt es noch andere Möglichkeiten in den Vollbildmode zu wechseln ohne Windows-Funktionen zu benutzen?
(Mit "mov ax, 3" und "int 10h" komme ich nicht in den Vollbildmode.)

Dirk

Ja, das ist alles richtig, das sind die Einstellungen des "DOS-Fensters" von Windows.
Wie man leicht sieht, fangen auch ab 176 die "Grafikzeichen" an, die eben bei Codepage 850 "durchsetzt" sind mit Buchstaben. Will sagen: in CP437 sind von 176 bis 219 ausschließlich Grafikzeichen (Raster, Klötze, Halbklötze und vor allem alle möglichen einfachen und doppelten Linien, auch als Ecken oder Kreuz), in CP852 sind dort NUR noch Buchstaben, diese entsprechen auch den Codes im Unicode. Der CP850 ist ein Hybrid aus CP437 und CP852, in dem einige Grafikzeichen aus CP437 erhalten wurden und die, die eine Kombination aus Doppel- und Einfachlinien bilden, sowie die beiden senkrechten Halbklötze wurden durch die Zeichen aus CP852 ersetzt. Und ja, richtig gesehen: Die Umlaute kommen doppelt vor (einmal an der Stelle, an der sie in CP437 liegen und einmal an der Stelle von CP852).

ABER:
Was Charlie wahrscheinlich will, ist ein Spiel in Textmode zu schreiben, bei dem er die Buchstaben, aber vor allem die für so etwas recht nützlichen Grafikzeichen verwendet - und CP437 (der "DOS-Zeichensatz") hat eben die meisten davon. Für das "DOS-Fenster" kann man da nichts machen, das wird immer CP850 benutzen. Aber im Vollbild geht das schon.
Erklärung: Diese Zeichensatz-Codepage-Einstellung bewirkt NUR, daß bei NEUSETZEN eines Textmodes der entspechende Zeichensatz in die Grafikkarte geladen wird. Es ist nicht verboten, danach einen ANDEREN Zeichensatz in die Grafikkarte zu laden (man kann sogar völlig eigene generieren, die NUR aus Grafikzeichen bestehen, damit könnte man ein noch cooler aussehendes Textmode-Spiel machen. Allerdings geht das nur im Vollbild-Mode. Der Fenster-Mode von Windows emuliert das alles nur, die Zeichen sind auch nicht immer 8x16 (bzw eigentlich 9x16), indem er einfach einen monospaced Zeichensatz (alle Zeichen gleiche Breite) benutzt und in einem Fenster darstellt. Hier ist es NICHT möglich, den Zeichensatz zu ändern - bzw: Es ist möglich, intern wird das dann gemacht, aber es wird eben nicht angezeigt (dran denken: Das "DOS", vor allem die Hardware, wird im Windows-Fenster nur emuliert).
Unter reinem DOS ist das alles natürlich keine Frage.

@Charlie: Wie genau hast Du Dir das vorgestellt?
Wenn Du ein Textmode-Spiel machen willst, das auch diese "Grafikzeichen" benutzt UND auch im FENSTER von Windows läuft, dann mußt Du mit den Zeichensätzen, die Windows dazu bietet, vorlieb nehmen (die alle der Codepage850 entsprechen). Wenn Du Vollbild willst, dann kannst Du auch den Zeichensatz nach eigenen Wünschen beliebig ändern, da das Vollbild direkt anzeigt, was die Grafikkarte macht.
Achja: Notebook-Grafikchips sind manchmal nicht ganz so kompatibel zu "VGA", wie man es sich wünschen würde und mitunter sehen die Textmodi auf solchen Notebooks echt besch...eiden aus...

Achja, noch eine Anmerkung: Die Zeichen 0 bis 127 (ASCII-7) haben sich zum weltweiten Standard etabliert - was bedeutet: Egal, welche Codepage, welchen Unicode oder sonstwas man verwendet: Die Zeichen 0 bis 127 sind überall die gleichen! (Was natürlich nicht bedeutet, daß man sie nicht selbst ändern darf/kann, wenn man die Zeichen im Grafikkartenspeicher softwareseitig ändert.)

Falls also Fragen, wie man den Zeichensatz ändert, kann ich gerne weiterhelfen. (Achja: Auch im Textmode ist man nicht auf diese 16 Standardfarben angewiesen - da kann man ebenfalls 16 eigene definieren - kann ich auch gern erklären...)
Anmerkung: Die Farben im "DOS-Fenster" von Windows entsprechen nicht 100% den Textmode (EGA) Farben in DOS. Der auffälligste Unterschied ist die Farbe 6, die in Windows dunkelgelb ist, in DOS aber orange/braun. aber auch die anderen Farben (mit Ausnahme von schwarz/weiß) sind leicht anders, sie haben aber denselben Farbton, nur die Helligkeiten unterscheiden sich.

Ich kenne mich mit diesem ganzen Kram sehr gut aus, habe mich jahre/jahrzehntelang mit Programmierung unter DOS und einigen Besonderheiten der Hardware (vor allem im Grafikbereich) befaßt. Für Fragen dazu wäre ich also wohl nicht die schlechteste Wahl.

Status von Gerät CON:
--------------------------
   Zeilen: 300
   Spalten: 80
   Wiederholrate: 31
   Verzögerungszeit: 1
   Codepage:  850

[quote="Charlie"]Also die Tastatur ist völlig egal. (Auf der Tastatur gibt man in der Regel sowieso keine Zeichen jenseits der 127 ein, das ist also ohnehin relativ codepageunabhängig, oder irre ich mich?)
[/quote]
In der DOS-Box von XP kann ich im Editor mit AltGr (gedrückt halten) und mit einer (max drei stelligen) Zahl auf dem Ziffernblock getippt (AltGr wieder loslassen) alle diese Zeichen ausgeben lassen:
[img]http://www.tcp-ip-info.de/tcp_ip_und_internet/ascii.gif[/img]

Bei der Eingabe von Mode wird mir folgender Text ausgegeben:
[code]
Status von Gerät CON:
--------------------------
Zeilen: 300
Spalten: 80
Wiederholrate: 31
Verzögerungszeit: 1
Codepage: 850
[/code]
Dirk

Für Linux neben Curses:
http://www.faqs.org/docs/Linux-HOWTO/NCURSES-Programming-HOWTO.html

Für DOS:
http://pdcurses.sourceforge.net/

Tja, und schon ist klar, daß es gar nicht darum geht!
Es geht darum, den Zeichensatz zu setzen. Man kann Zeichensätze auch selbst setzen - dazu hab es hier im Forum mal vor einer Weile einen Thread (Suchfunktion benutzen), mit Programmbeispielen.
Zeichensätze Codepage 437 gibts z.B. auf meiner Webseite:
http://www.imperial-games.de/z/char8x16.rar
Wenn man beim Beenden des Programms einfach wieder den normalen 80x25 Mode einschaltet (egal, ob der sowieso schon da ist), wird wieder vom BIOS der Standard-Zeichensatz laut Codepage geladen.
Wenn man also einfach am Anfang seines Spiels einen 437er Zeichensatz setzt, ist das Problem gelöst.
Achtung! Unter Windows funktioniert das natürlich nur im Vollbild! Das DOS-Textfenster wird mit einem von WIndows standardmäßig benutzten Zeichensatz gesetzt (entspricht Codepage 850, der ein Hybrid aus CP437 und CP852 ist, d.h. er hat noch einige der Grafikzeichen, aber andere sind ersetzt durch Buchstaben). Den Zeichensatz im Windows-DOS-Fenster kann man meines Wissens nur von Windows aus ändern (bei Eigenschaften und so)...
Aber es gibt auch Tricks, damit das Programm ins Vollbild schaltet.