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.)
Probleme beim Codepage ändern mit Programm
-
Charlie
Re: Probleme beim Codepage ändern mit Programm
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.
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.
Re: Probleme beim Codepage ändern mit Programm
Aha.DOSferatu hat geschrieben: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.)
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 NVIDIA-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
Re: Probleme beim Codepage ändern mit Programm
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.)Charlie hat geschrieben: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.
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.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?
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: Alles auswählen
--------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
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.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.
Dirk
-
Gast
Re: Probleme beim Codepage ändern mit Programm
[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.
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.
-
Charlie
Re: Probleme beim Codepage ändern mit Programm
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.)
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.)
-
Deadsoft
Re: Probleme beim Codepage ändern mit Programm
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?
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?
-
Charlie
Re: Probleme beim Codepage ändern mit Programm
"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.
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.
."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.
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.
Re: Probleme beim Codepage ändern mit Programm
@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
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