[C] Win7: Console in Vollbildmodus - SetConsoleDisplayMode not implemented

ARGGHHHHH! Gibts doch nicht! Ich brauche 80 x 50 Zeichen (horizontal x 
vertikal) und das möglichst bildschirmfüllend, lässt sich da was machen? 
Ich hab wie gesagt kein W7 zur Hand und kenne das OS nicht (bei mir 
läuft XP).

Jetzt habe ich ein großes Problem. :-(

kriegt man das nicht ggf. mit einem XP-Mode/Kompatbilität hin?!

MS bietet im Inet Testversionen von Win7 an

raketenfred schrieb:
> kriegt man das nicht ggf. mit einem XP-Mode/Kompatbilität hin?!
Die Antwort von Rufus klingt irgendwie nicht so.

> MS bietet im Inet Testversionen von Win7 an
Hm, zum Testen wäre das ganz gut. Kann man die auch in irgendeinem 
virtuellen Dingsda ausführen? Ich hab da keine Ahnung und eine direkte 
Installation von W7 auf eine freie Partition ist mir nichts...

Vielleicht lässt sich ja irgendwie das Fenster "aufblasen" (Schriftgröße 
erhöhen) ohne gleich in den Vollbildmodus zu gehen, ohne Testsystem ist 
das aber verlorene Zeit.

Was hat sich MS da nur wieder gedacht???

Rufus Τ. Firefly schrieb:
> Die Größe des Konsolenfensters lässt sich per Software auf die
> gewünschte 80x50-Darstellung einstellen, und die verwendete Schriftart
> lässt sich auch innerhalb gewisser Grenzen beeinflussen.
>
> Sieh Dir mal die Dokumentation der folgenden Funktionen an:
> GetCurrentConsoleFont
> SetCurrentConsoleFontEx
> GetLargestConsoleWindowSize
Werde ich machen.

> In so einem Fall aber wäre ein Verzicht auf die Konsolennutzung
> sinnvoller, ein richtiges Fenster aufmachen und darin den Text so
> darstellen, wie er dargestellt werden soll, das ist etwas, was in
> üblichen Programmiersprachen keine unüberwindbare Hürde darstellt.
Nu ja... Ich bin nur Hobbyprogrammierer und bisher konnte ich alle 
Probleme mit bzw. in der Konsole lösen. Mit ein paar API-Aufrufen lässt 
sich der Text auch ziemlich einfach an beliebige Positionen schreiben, 
falls nötig sogar in Farbe, unter XP läuft alles prima und außerdem - 
ich mag diesen "Retro-Look". :-) Ich hatte mir mal GTK angeschaut aber 
irgendwie, was soll ich mir Arbeit machen wenn sich >90% der Probleme 
mit printf und getch erschlagen lassen?
Im konkreten Fall wäre das mit dem Fenster sowieso schwierig, ist eine 
Art Spiel und dieser Konsolenlook gehört irgendwie dazu. Das ganze ist 
ein rein privates Spaßprojekt, der Spaß geht aber gerade gegen Null. Ich 
glaub ich leg die W7-Unterstützung erstmal auf Eis, schade drum. Das 
heisst nämlich auch das noch mindestens ein weiteres Programm welches 
sich in der Entwicklungsphase befindet erstmal in den Winterschlaf 
versetzt wird. :-(

Warum haben die bloss den Vollbildmodus entfernt?

Die Sache mit der W7-Demo scheint auch nicht gewonnen, Google lieferte 
mir Virtualbox um einen virtuellen PC zu simulieren aber laut Wiki läuft 
da kein W7 drin. :-(

MS immer für eine Überraschung gut, ach ich liebe es einfach. :-(

xpler schrieb:
> Warum haben die bloss den Vollbildmodus entfernt?

weil er keinen Sinn mehr Macht. Es gibt leute die Arbeiten z.b. mit 
RemoteDesktop oder Terminalserver dort hat der Server keine Kontrolle 
über die Bildschirmauflösung.

Es hindert dich niemand daran eine richtiges Windowsprogramm zu 
schreiben was im Vollbild läuft und dort das alte Design hat.

Peter II schrieb:
> Es hindert dich niemand daran eine richtiges Windowsprogramm zu
> schreiben was im Vollbild läuft und dort das alte Design hat.
Meine nicht vorhandenen Kenntnisse in Sachen "Fensterprogrammierung" 
hindern mich dran. OK, kann man natürlich nachlesen und lernen, aber für 
ein Spaßprojekt mit vielleicht 1k LOC hab ich keine Lust nochmal 500 
Zeilen API-Gemurkse produzieren zu müssen.

xpler schrieb:
> 500 Zeilen API-Gemurkse produzieren zu müssen.
bzw. Code für GTK oder sonst irgendwas.

Ist dein Programm nur im Dos Design oder reicht dir auch ein Dos 
darunter? Wenn ja könntest du es ja mal mit DosBox versuchen.

Gib dir nen Ruck und schau dir Fensterzeugs an - Je nach Framework sinds 
nur wenige Zeilen ;D

Peter II schrieb:
> Ist dein Programm nur im Dos Design oder reicht dir auch ein Dos
> darunter?
Das verstehe ich nicht, was meinst du?

bluppdidupp schrieb:
> Gib dir nen Ruck und schau dir Fensterzeugs an - Je nach Framework sinds
> nur wenige Zeilen ;D
Vielleicht später, für heute ists gut.

xpler schrieb:
>> Ist dein Programm nur im Dos Design oder reicht dir auch ein Dos
>> darunter?
> Das verstehe ich nicht, was meinst du?

ist es ein 16bit Programm was unter Dos noch läuft?

Peter II schrieb:
> xpler schrieb:
>>> Ist dein Programm nur im Dos Design oder reicht dir auch ein Dos
>>> darunter?
>> Das verstehe ich nicht, was meinst du?
>
> ist es ein 16bit Programm was unter Dos noch läuft?
Äh - wie findet man das raus? Ist eine "ganz normale" exe welche von gcc 
erzeugt wurde.

OK, hab die Datei gerade durch File Analyzer geschoben, die Antwort 
steckt wohl im Hex Dump:

> This Programm cannot be run in DOS mode.

und unter PE-Header steht:
> Characteristics: 030F - Relocs Stripped, Executable, Line Numbers
> Stripped, Local Symbols Stripped, 32bit Machine Expected , Debug Data
> Stripped

Also lautet die Antwort wohl: Nein.

Äh sorry, das Programm heißt "File Alyzer". 
http://www.safer-networking.org/en/filealyzer/index.html

Lustig. Heutzutage wissen die Programmierer nicht mal, was sie da 
eigentlich für Programme schreiben. Spiegelt wohl den allgemeinen 
Bildungsstand in D wieder...

xpler schrieb:
> Die Sache mit der W7-Demo scheint auch nicht gewonnen, Google lieferte
> mir Virtualbox um einen virtuellen PC zu simulieren aber laut Wiki läuft
> da kein W7 drin. :-(
Merke: Wer lesen kann ist klar im Vorteil.

Wikipedia schrieb:
> Außer den unterstützten Wirtsystemen können noch zusätzlich folgende
> Systeme virtualisiert werden:
> Microsoft Windows NT, 2000

> Folgende Wirtsysteme (engl. host system) werden von der aktuellen Version
> unterstützt:
> *Microsoft Windows 7*
http://de.wikipedia.org/wiki/Virtualbox#Unterst.C3.BCtzte_Betriebssysteme

Ich hab das ganze mal ausprobiert, die W7-Demo läuft prima. Ist ein 
bisschen haarig mit nur 1GB RAM aber es klappt. Mal gucken was man mit 
den von Rufus empfohlenen Funktionen machen kann, dazu muss ich erstmal 
eine Toolchain unter W7 einrichten. Ich wollte zunächst erstmal unter XP 
basteln aber SetCurrentConsoleFontEx() gibts erst ab Vista und 
GetCurrentConsoleFont() ist (obwohl es laut MSDN unter XP existiert) 
auch unbekannt und erzeugt einen Linkerfehler...

xpler schrieb:
> Peter II schrieb:
>> Es hindert dich niemand daran eine richtiges Windowsprogramm zu
>> schreiben was im Vollbild läuft und dort das alte Design hat.
> Meine nicht vorhandenen Kenntnisse in Sachen "Fensterprogrammierung"
> hindern mich dran. OK, kann man natürlich nachlesen und lernen, aber für
> ein Spaßprojekt mit vielleicht 1k LOC hab ich keine Lust nochmal 500
> Zeilen API-Gemurkse produzieren zu müssen.

Das kenne ich :-)

Besorg dir eine vernünftige Bibliothek für VT100 oder sowas (ncurses 
z.B.) und schreib damit den Programm. Benutze dann einen gescheiten 
Terminal-Emulator.

Jetzt ist aber gut!

Kann mir mal jemand sagen warum das unter W7 nicht funktioniert?

1

#include <stdlib.h>

2

#include <stdio.h>

3

#define _WIN32_WINNT 0x05000

4

#include <windows.h>

5

6

int main (int argc __attribute__((unused)), char *argv[] __attribute__((unused)))

7

{

8

  HANDLE konsole;

9

  CONSOLE_FONT_INFO cfi;

10

11

  konsole=GetStdHandle(STD_OUTPUT_HANDLE);

12

  if(!GetCurrentConsoleFont(konsole,TRUE,&cfi))

13

    exit(44);

14

15

  return 0;

16

}

1

C:\Users\abc\Desktop\test\main.c||In function 'main':|

2

C:\Users\abc\Desktop\test\main.c|29|warning: implicit declaration of function 'GetCurrentConsoleFont'|

3

obj\Debug\main.o||In function `main':|

4

C:\Users\abc\Desktop\test\main.c|29|undefined reference to `GetCurrentConsoleFont|

5

||=== Build finished: 1 errors, 1 warnings ===|

Funktion: 
http://msdn.microsoft.com/en-us/library/ms683176%28v=vs.85%29.aspx

Nichts als Ärger mit dieser Windows-Sch***!

Sven P. schrieb:
> Besorg dir eine vernünftige Bibliothek für VT100 oder sowas (ncurses
> z.B.) und schreib damit den Programm. Benutze dann einen gescheiten
> Terminal-Emulator.
Äh... Ich bin nur dummer Hobbyprogrammierer, langsam bitte... Dieses 
ncurses dient dazu unter Linux die Ausgaben in/für die Konsole (also 
das schwarzweiße Fenster wo die Hacker ihre Zaubersprüche eingeben) 
unabhängig von der genauen Linuxversion oder irgendwas anderem (was?) zu 
formatieren, richtig? In wie fern hilft mir das unter Windows und was 
genau ist ein "Terminalemulator"? Bei Wikipedia gehts da um Großrechner 
und unter "Terminal" findet man Technik aus dem letzten Jahrtausend. Hä?

xpler schrieb:
> Jetzt ist aber gut!
> Kann mir mal jemand sagen warum das unter W7 nicht funktioniert?

nein, bei mir geht es. Aber du verwendest ja den GCC ich vermute mal 
deine Header Dateien sind zu alt.
Wo hast du die Windows-header Dateien überhaupt her, sind bei beim gcc 
für windows dabei?

Unter windows würde ich aber auch nicht den gcc verwenden, immerhin hat 
ms ja auch eine recht guten kostenlosen compieler. Du braucht dafür 
nicht mal das VisualStudio wenn du nicht willst. Man kann sich auch das 
Platform SDK laden. Damit müsste alles gehen was du brauchst.

xpler schrieb:
> Sven P. schrieb:
>> Besorg dir eine vernünftige Bibliothek für VT100 oder sowas (ncurses
>> z.B.) und schreib damit den Programm. Benutze dann einen gescheiten
>> Terminal-Emulator.
> Äh... Ich bin nur dummer Hobbyprogrammierer, langsam bitte...
Nunja, viele Programmierer haben ein völlig falsches Verständnis zu 
ihrem 'Konsolen'-Programm. Vorallem diejenigen, die sich mit Visual 
Studio quälen.

Ein Konsolenprogramm nimmt Eingaben entgegen und erzeugt Ausgaben, 
Punkt. Wo erstere herkommen und wo leztere hingehen, ist völlig wurscht. 
Entsprechend erübrigen sich auch solche Hirnkrämpfe wie 
'system("pause")' und 'getch(); getch();' und anderweitige Funktionen, 
um irgendwie am 'Konsolenfenster' herumzudoktorn. Ein Konsolenprogramm 
kennt all das nicht! Es hat einen Grund, warum derartige Funktionen 
nicht im Standard-C verankert sind.

In aller Regel aber kommen die Eingaben vom Benutzer, also von der 
Tastatur oder vom Fernschreiber, und die Ausgaben gehen wieder an den 
Benutzer, meistens über den Bildschirm oder aber auch auf dem Drucker. 
Davon aber bekommt ein Konsolenprogramm garnichts mit. Und da siehst du 
es: Versuche mal, das Papierformat im Drucker umzuprogrammieren. Eben. 
Wie der Drucker die Ausgabe zu Papier bringt, ist seine Sache. Davon 
bekommt das Konsolenprogramm garnichts mit. Vielleicht läuft dein 
Konsolenprogramm ja in einem Rechenzentrum weit weg, und du stehst 
lediglich über eine Telefonleitung damit in Verbindung.

Für dich als Benutzer heißt das: Um ein Konsolenprogramm zu benutzen, 
musst du irgendwie Daten von der Tastatur in das Programm hineinbekommen 
und die Ausgabe des Programmes musst du irgendwie lesbar machen. Du 
könntest z.B. die Eingabe mit einem Texteditor in eine Datei tippen und 
die Ausgabe des Programmes in einer anderen Datei auffangen und dir 
diese anschließend im Editor anschauen.

Oder aber du benutzt ein weiteres Hilfsprogramm, welches gewissermaßen 
deine Eingabe liest, durch das Konsolenprogramm durchreicht und die 
Ausgabe auffängt und anzeigt. Das ist dann ein Terminalemulator.

Es sollte sich dir jetzt erschließen, warum 'system("pause")' so 
überflüssig ist: Auf ein Konsolenprogramm doppelklickt man nicht und 
wundert sich dann, warum man nur kurz ein schwarzes Fenster aufblitzen 
sieht. Das wäre in etwa so, wie wenn du einen Haufen Lochkarten in den 
Briefkasten des Rechenzentrums schaufelst.

Viel sinnvoller wäre doch: Erst Fernschreiber (Tastatur) und Drucker 
(Bildschirm) einschalten/einwählen, DANN das Programm starten und zum 
Schluss alles wieder abschalten. Ebenso gehört sich das: Einen 
Terminalemulator starten, das Programm damit ('darin') starten, und den 
Emulator wieder schließen.
Das Programm redet mit dir, druckt seine Ausgaben an den 
Terminalemulator (der sie wiederum auf den Bildschirm malt) und nichts 
verschwindet plötzlich.



VT100 ist jetzt ein Satz von Steuerzeichen, die so ein Terminalemulator 
verstehen kann. Leitest du die Programmausgabe einfach in eine Datei, 
tauchen dort halt komische Steuerzeichen auf. Der Terminalemulator aber 
filtert die heraus und stellt was Gescheites damit an (Cursor bewegen, 
Farben etc.).
ncurses war jetzt für Linux, für Windows gibts gewiss auch ähnliche 
Bibliotheken.

Dann gibts natürlich noch die Lösung für die ganz harten:

Einfach einen alten XPDM Grafiktreiber installieren, dann klappts zwar 
mit Aero nicht mehr, dafür ist aber der Vollbildmodus wieder da.

Siehe auch: http://support.microsoft.com/kb/926657/de

Arghhh!

Peter II schrieb:
> xpler schrieb:
>> Jetzt ist aber gut!
>> Kann mir mal jemand sagen warum das unter W7 nicht funktioniert?
>
> nein, bei mir geht es. Aber du verwendest ja den GCC ich vermute mal
> deine Header Dateien sind zu alt.
> Wo hast du die Windows-header Dateien überhaupt her, sind bei beim gcc
> für windows dabei?
Dass die Headerdateien zu alt sind ist möglich.

Ich habe CodeBlocks mit integriertem minGW runtergeladen 
(codeblocks-10.05mingw-setup.exe von 
http://www.codeblocks.org/downloads/26), das ist "all-inclusive". Wie 
ich festgestellt habe ist diese angeblich aktuelle Version allerdings 
uralt, Mai 2010 bzw. Juli 2009(!) für minGW ("gcc (TDM-2 mingw32) 
4.4.1"). In den Nightly Builds ist kein minGW enthalten, also hab ich 
versucht das ganze nach dieser Anleitung [1] manuell zu aktualisieren. 
Ich hab jeweils das aktuellste genommen was ich dort [2] gefunden habe, 
die ganzen Dateien wurden nach C:\Program Files\CodeBlocks\MinGW 
entpackt und alle Anfragen bezügl. des Überschreibens von Dateien 
bejaht. (Die ganzen Probleme mit Zugriffsrechten und Besitz erwähne ich 
mal nicht.)

GCC meldet jetzt Version 4.5.1, laut [3] ist das aber auch schon ein 
knappes Jahr alt und aktuell ist 4.5.3. Verstehe ich nicht. :-(

Gebracht hat es überhaupt nichts! In der wincon.h aus 
w32api-3.17-2-mingw32-dev.tar.lzma gibt es weiterhin keinen Prototypen 
und der Linker beschwert sich auch noch.

> Unter windows würde ich aber auch nicht den gcc verwenden, immerhin hat
> ms ja auch eine recht guten kostenlosen compieler.
Mit dem MS-Compiler und der dazugehörigen IDE habe ich so meine 
Erfahrungen gemacht, das möchte ich mir eigentlich nicht antun. Außerdem 
hab ich nur knappe 500MB RAM für die VM, das ist schon hart an der 
Grenze. Für W7+VisualStudio reicht das bestimmt nicht, wie es mit dem 
SDK aussieht weiß ich jetzt nicht. Ich will eigentlich beim GCC bleiben, 
ging (bisher) immer.

Frage an die Profis die sich mit diesem ganzen GCC-Kram auskennen: Was 
muss ich wo installieren um diese dämlichen Funktionen nutzen zu können? 
Das kann doch nicht so kompliziert sein, dämlicher Krempel. Sorry wegen 
der Flucherei, aber am Anfang wollte ich nur ein recht simples Programm 
auf W7 zum Laufen kriegen und jetzt wird wieder eine Großbaustelle 
draus.

[1] http://www.mingw.org/wiki/InstallationHOWTOforMinGW
[2] http://sourceforge.net/projects/mingw/files/MinGW/
[3] http://gcc.gnu.org/releases.html

xpler schrieb:
> Mit dem MS-Compiler und der dazugehörigen IDE habe ich so meine
> Erfahrungen gemacht, das möchte ich mir eigentlich nicht antun. Außerdem
> hab ich nur knappe 500MB RAM für die VM, das ist schon hart an der
> Grenze. Für W7+VisualStudio reicht das bestimmt nicht, wie es mit dem
> SDK aussieht weiß ich jetzt nicht. Ich will eigentlich beim GCC bleiben,
> ging (bisher) immer.
scheinbar ja nicht, du kannst nicht auf MS schimpfen und dir irgendwo 
entwas herunterladen. Die Version von GCC ist ziemlich egal. Wichtig ist 
das du die aktuellen header und libs hast und die bekommen man nun mal 
von MS. Lade dir mal das Platform-SDK runter eventuell kann man dort 
auch nur die header und libs installieren. Muss ja nicht den compiler 
verwenden.

Hier mal die übersicht
http://msdn.microsoft.com/de-de/windows/ff851942.aspx

es ist immer nur der webinstaller, dort steht auch immer das man 2GB HDD 
braucht. Ich glaube man konnte aber bei der installation wählen was man 
alles haben will.

Kannst ja wenigstens mal das Setup starten, dann sieht du ja ob man nur 
die header und libs auswählen kann. Eventuell nicht das neuste nehmen, 
wegen ganzen .net zeug was dabei ist.

Das müsste die Version 6.1 sein, damit hatte ich zumindest mal gute 
erfahrung gemacht.
http://www.microsoft.com/downloads/en/details.aspx?familyid=e6e1c3df-a74f-4207-8586-711ebe331cdc&displaylang=en

Ich habe gerade mal das Setup gestartet, nur header und libs sind 185MB 
(man muss noch IA64 und x64 abwählen)

GEHT DOCH! Es compiliert. :-)
Ich ess was und melde mich dann. (Dies nur als Hinweis damit niemand 
rumsucht obwohl das Problem gelöst ist.)

So, nach längerer Mittagspause gehts weiter mit der Beschreibung was ich 
gemacht habe um den Testcode compilieren zu können. Als erstes das 
manuelle Update auf Version 4.5.1 rückgängig gemacht (Schon toll so eine 
VM!), dann das Orakel mit GetCurrentConsoleFont belästigt und diese 
Seite [1] gefunden. Keine Ahnung um was es da eigentlich geht, aber es 
findet sich ein Header welcher einen Prototypen für 
GetCurrentConsoleFont enthält, mit folgendem Hinweis:
>Well, here's the wincon.h file in the stable 1.0 of MinGW 64
Bei Sourceforge [2] lässt sich die Datei aber nicht finden und das ist 
normal - es handelt sich um ein anderes Projekt! MinGW-w64: [3]
Dort die Datei mingw-w32-1.0-bin_i686-mingw_20110516.zip [4] runterladen 
(Vorsicht, 200MB!) und entpacken. Dann alle Dateien aus dem Ordner 
mingw\include nach C:\Program Files\CodeBlocks\MinGW\include kopieren 
(bereits vorhandene Dateien ersetzen) und es läuft.

Ich blick zwischen C::B, GCC, minGW, minGW64 usw. nicht richtig durch, 
es scheint als wäre da irgendwas nicht ganz up-to-date, daher der 
Fehler.

Jetzt kann ich mich endlich um das eigentliche Problem kümmern, 
nämlich diese Konsole zu vergrößern!

[1] http://irrlicht.sourceforge.net/phpBB2/viewtopic.php?p=246803
[2] http://sourceforge.net/projects/mingw/files/
[3] http://sourceforge.net/projects/mingw-w64/
[4] 
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Automated%20Builds/mingw-w32-1.0-bin_i686-mingw_20110516.zip/download

Um noch kurz auf die anderen Posts einzugehen:

Sven P. schrieb:
> xpler schrieb:
>> Sven P. schrieb:
>>> Besorg dir eine vernünftige Bibliothek für VT100 oder sowas (ncurses
>>> z.B.) und schreib damit den Programm. Benutze dann einen gescheiten
>>> Terminal-Emulator.
>> Äh... Ich bin nur dummer Hobbyprogrammierer, langsam bitte...
> Nunja, viele Programmierer haben ein völlig falsches Verständnis [...]
Danke für den ausführlichen Beitrag, ich werde in den nächsten Tagen 
darauf zurückkommen!! Aktuell bastele ich mit WinAPI+GCC, ich will nicht 
alles vermischen.

Theodor schrieb:
> Dann gibts natürlich noch die Lösung für die ganz harten:
> Einfach einen alten XPDM Grafiktreiber installieren, dann klappts zwar
> mit Aero nicht mehr, dafür ist aber der Vollbildmodus wieder da.
Das ist leider nicht möglich, der PC wo die ganze Sache laufen soll 
gehört nicht mir.

Peter II schrieb:
> [...]
Die Header habe ich mittlerweile aus anderer Quelle bekommen (s.o.), der 
Ausflug in MS's-Entwicklungstools bleibt mir also erspart. :-) Und 
Webinstaller kommen mir eh nicht auf die Festplatte! Trotzdem Danke für 
die Hilfe.

Zu früh gefreut, selbes Problem mit CONSOLE_FONT_INFOEX (struct) und 
SetCurrentConsoleFontEx(). Ich gebs auf. :-(

Sven P. schrieb:
> Ein Konsolenprogramm nimmt Eingaben entgegen und erzeugt Ausgaben,
> Punkt. Wo erstere herkommen und wo leztere hingehen, ist völlig wurscht.
> Entsprechend erübrigen sich auch solche Hirnkrämpfe wie
> 'system("pause")' und 'getch(); getch();' und anderweitige Funktionen,
> um irgendwie am 'Konsolenfenster' herumzudoktorn.
Warum? Meine Programme enden fast immer mit getch(), funktioniert prima. 
Da Quelle+Ziel der Daten immer gleich sind (Tastatur+Monitor) sehe ich 
da irgendwie das Problem nicht.

> Oder aber du benutzt ein weiteres Hilfsprogramm, welches gewissermaßen
> deine Eingabe liest, durch das Konsolenprogramm durchreicht und die
> Ausgabe auffängt und anzeigt. Das ist dann ein Terminalemulator.
Demnach ist das schwarze Fenster was Windows mir bei einem Klick auf 
mein Programm aufmacht nicht das eigentliche Konsolenprogramm sondern 
ein Terminalemulator? Hä?

> VT100 ist jetzt ein Satz von Steuerzeichen, die so ein Terminalemulator
> verstehen kann. Leitest du die Programmausgabe einfach in eine Datei,
> tauchen dort halt komische Steuerzeichen auf. Der Terminalemulator aber
> filtert die heraus und stellt was Gescheites damit an (Cursor bewegen,
> Farben etc.).
Ja, ich habe mal danach gegoogelt. Wenn ich das richtig verstehe sind 
das "nur" ein paar Zeichen die man zusätzlich ausgibt, da brauche ich im 
konkreten Fall keine Library zu.

Nur: Gibt es einen brauchbaren Terminalemulator für Windows welcher 
eben diese VT100-Sequenzen versteht? Ich würde da gerne mal rumspielen 
aber Google findet nichts.

xpler schrieb:
> Zu früh gefreut, selbes Problem mit CONSOLE_FONT_INFOEX (struct) und
> SetCurrentConsoleFontEx(). Ich gebs auf. :-(
wer nicht hören will muss fühlen.

mit dem SDK würde es (vermutlich) sofort gehen.

xpler schrieb:
> Warum? Meine Programme enden fast immer mit getch(), funktioniert prima.
Warum? Möchtest du immer noch ein Zeichen lesen, bevor das Programm 
beendet? Sicherlich nicht.

> Da Quelle+Ziel der Daten immer gleich sind (Tastatur+Monitor) sehe ich
> da irgendwie das Problem nicht.
Du liest ein Zeichen zu viel aus dem Eingabestrom, das ist schon genug. 
Hast du früher mal mit DOS o.ä. gearbeitet? Dein 'getch()' ist so in 
etwa, als wenn du 'dir' eintippst und Enter drückst. Es kommt dann das 
Verzeichnislisting. Und jetzt musst du nochmal Enter drücken, damit 
'dir' beendet und du wieder neue Befehle eintippen kannst.

>> Oder aber du benutzt ein weiteres Hilfsprogramm, welches gewissermaßen
>> deine Eingabe liest, durch das Konsolenprogramm durchreicht und die
>> Ausgabe auffängt und anzeigt. Das ist dann ein Terminalemulator.
> Demnach ist das schwarze Fenster was Windows mir bei einem Klick auf
> mein Programm aufmacht nicht das eigentliche Konsolenprogramm sondern
> ein Terminalemulator? Hä?
Vollkommen korrekt. Windows startet den Emulator, bringt dein Programm 
darin zur Ausführung und beendet den Emulator anschließend. Dabei geht 
das Fenster wieder zu.


>> VT100 ist jetzt ein Satz von Steuerzeichen, die so ein Terminalemulator
>> verstehen kann. Leitest du die Programmausgabe einfach in eine Datei,
>> tauchen dort halt komische Steuerzeichen auf. Der Terminalemulator aber
>> filtert die heraus und stellt was Gescheites damit an (Cursor bewegen,
>> Farben etc.).
> Ja, ich habe mal danach gegoogelt. Wenn ich das richtig verstehe sind
> das "nur" ein paar Zeichen die man zusätzlich ausgibt, da brauche ich im
> konkreten Fall keine Library zu.
>
> Nur: Gibt es einen brauchbaren Terminalemulator für Windows welcher
> eben diese VT100-Sequenzen versteht? Ich würde da gerne mal rumspielen
> aber Google findet nichts.
Gibt sicherlich tausende, PuTTY ist zum Beispiel recht populär.

Auch mit VT100 aber wirst du Probleme haben, das Bildschirmformat zu 
ändern. Was ich sagen möchte ist, dass du dringend deinen Ansatz 
umdenken musst: Nicht dein Programm ändert das Bildschirmformat. Viel 
mehr sollte sich dein Programm an der gegebenen Bildschirmgröße 
orientieren und z.B. Tabellen entsprechend kleiner/größer darstellen 
oder den Zeilenumbruch anpassen. Notfalls auch abbrechen mit einer 
Meldung, dass der Bilschirm zu klein ist.

Peter II schrieb:
> xpler schrieb:
>> Zu früh gefreut, selbes Problem mit CONSOLE_FONT_INFOEX (struct) und
>> SetCurrentConsoleFontEx(). Ich gebs auf. :-(
> wer nicht hören will muss fühlen.
>
> mit dem SDK würde es (vermutlich) sofort gehen.
Ist ja gut. Mit dem SDK könnte ich zwar wahrscheinlich die 
API-Funktionen benutzen, aber nachdem was ich so an Problemen mit 
VisualStudio hatte will ich mir das mindestens heute nicht mehr antun. 
Außerdem weiß ich gar nicht ob die API-Funktionen mir überhaupt helfen, 
irgendwie ist das (wenn überhaupt) auch nur eine Murkslösung.

Sven P. schrieb:
> xpler schrieb:
>> Warum? Meine Programme enden fast immer mit getch(), funktioniert prima.
> Warum? Möchtest du immer noch ein Zeichen lesen, bevor das Programm
> beendet? Sicherlich nicht.
Eigentlich nicht, aber das Zeichen stört mich nicht und das Fenster 
bleibt offen. Ansonsten müsste man jedes Programm aus der Konsole bzw. 
dem Konsolenemulator (also das Fenster was sich beim Aufruf von cmd 
öffnet) heraus ausführen, nicht sehr praktisch.

> Hast du früher mal mit DOS o.ä. gearbeitet?
'dir' und Co. nutze ich heute noch ab und zu. :-)

> Dein 'getch()' ist so in
> etwa, als wenn du 'dir' eintippst und Enter drückst. Es kommt dann das
> Verzeichnislisting. Und jetzt musst du nochmal Enter drücken, damit
> 'dir' beendet und du wieder neue Befehle eintippen kannst.
Ich will halt das Fenster offen halten, s.o.

>>> Oder aber du benutzt ein weiteres Hilfsprogramm, welches gewissermaßen
>>> deine Eingabe liest, durch das Konsolenprogramm durchreicht und die
>>> Ausgabe auffängt und anzeigt. Das ist dann ein Terminalemulator.
>> Demnach ist das schwarze Fenster was Windows mir bei einem Klick auf
>> mein Programm aufmacht nicht das eigentliche Konsolenprogramm sondern
>> ein Terminalemulator? Hä?
> Vollkommen korrekt. Windows startet den Emulator, bringt dein Programm
> darin zur Ausführung und beendet den Emulator anschließend. Dabei geht
> das Fenster wieder zu.
Okay...

> Gibt sicherlich tausende, PuTTY ist zum Beispiel recht populär.
OK, das werde ich mal runterladen.

> Was ich sagen möchte ist, dass du dringend deinen Ansatz
> umdenken musst: Nicht dein Programm ändert das Bildschirmformat. Viel
> mehr sollte sich dein Programm an der gegebenen Bildschirmgröße
> orientieren und z.B. Tabellen entsprechend kleiner/größer darstellen
> oder den Zeilenumbruch anpassen. Notfalls auch abbrechen mit einer
> Meldung, dass der Bilschirm zu klein ist.
Du hast ja vollkommen recht, aber... Warum zum Teufel ist dieser ganze 
Schrott so kompliziert? Mal ehrlich, ich brauche einen schwarzen 
Hintergrund, weiße Buchstaben, 80x50 Zeichen und fertig. Sowas gab es 
schon vor 30 Jahren, warum ist das heute so ein Krampf? Ich will doch 
verflucht nochmal nur eine kleine Bastelei unter W7 zum Laufen bringen. 
Da ist der Vollbildmodus verschwunden, dann kriege ich die API-Aufrufe 
nicht durch den GCC, man braucht einen Konsolenemulator, das ist aber 
auch wieder keine gute Lösung und und und. Hallo????

getch() und Co. mögen noch so großer Murks sein, aber es ist die 
einfachste Methode die funktioniert und mehr soll es nicht . Ich will 
Programme schreiben und Probleme lösen und mich nicht mit irgendwelchen 
Eigenheiten von irgendwelchen Betriebssystemen und weiß der Teufel 
beschäftigen. Es kann doch nicht sein das jede Kleinigkeit immer in eine 
tierische Frickelei ausartet. Da gibt es hochkomplexe Computersysteme 
die sonstewas berechnen und simulieren können, man kann die halbe Welt 
mit 5000x5000 Pixeln und 100FPS nachbauen aber ein simples Fenster mit 
80x50 Zeichen S/W wird zum Problem?

Meine Fresse, ich glaub wir sind in der Steinzeit. Irgendwie fühle ich 
mich gerade ganz doof. :-(

Sorry, mir platzt gerade der Kragen. Nehmt es nicht persönlich. Zig 
Stunden Gebastel für so ein einfaches Problem, solche Sachen vertrage 
ich nicht. Wenn es eine Demo von XP geben würde würde ich dem DAU (per 
Fernwartung) Virtualbox auf den Rechner packen und gut ist!

xpler schrieb:
> was ich so an Problemen mit
> VisualStudio hatte will ich mir das mindestens heute nicht mehr antun.

Wieso? Mit VsualStudio ist das nicht mehr als ein Dreizeiler.

xpler schrieb:
> aber ein simples Fenster mit
> 80x50 Zeichen S/W wird zum Problem?

Nö. Das Problem ist deine Herangehensweise.

Tina schrieb:
> xpler schrieb:
>> aber ein simples Fenster mit
>> 80x50 Zeichen S/W wird zum Problem?
>
> Nö. Das Problem ist deine Herangehensweise.
Ach machs doch besser! plonk

xpler schrieb:
> Tina schrieb:
>> xpler schrieb:
>>> aber ein simples Fenster mit
>>> 80x50 Zeichen S/W wird zum Problem?
>>
>> Nö. Das Problem ist deine Herangehensweise.
> Ach machs doch besser! *plonk*

Naja, ganz Unrecht hat sie ja nicht. Warum machst du dir so einen Krampf 
darum, auf Biegen und Brechen irgendwelche Fenster offen zu halten oder 
gar deren Größe zu verändern?

Kümmer dich doch ganz um dein Programm. Frag zu Beginn die aktuelle 
Konsolengröße ab und arbeite dann damit oder brech das Programm ab, 
falls sie zu klein ist.

Wie du dann für eine geeignete Konsole sorgst, ist erstmal zweitrangig. 
Dein Programm aber steht solide und braucht sich nicht um solchen 
Firlefanz zu kümmern.
Schlimmstenfalls legst du halt so ein Verknüpfungs-PIF-Dingens an und 
stellst vorher alles richtig ein.

Wass das Vollbild angeht: Naja, that's Windows.

Um diese unerfreuliche Sache abzuschließen:

Sven P. schrieb:
> Kümmer dich doch ganz um dein Programm. Frag zu Beginn die aktuelle
> Konsolengröße ab und arbeite dann damit oder brech das Programm ab,
> falls sie zu klein ist.
Davon hab ich nichts wenn ein DAU nicht die Größe (in Zeichen) passend 
einstellen kann. Davon abgesehen: Die Größe IN ZEICHEN kann ich 
problemlos mittels API-Aufruf ändern. Da es unter W7 aber keinen 
Vollbildmodus mehr gibt ist das Ergebnis halt nicht bildschirmfüllend. 
Um das Fenster größer (also mehr Pixel) zu machen wollte ich die 
Schriftgröße ändern und das geht nicht.

Anyway: Das Projekt (bzw. die Projekte, es sind mindestens zwei) 
ist/sind erstmal gestorben, ob für immer oder nur für längere Zeit wird 
sich zeigen. Ich hab aktuell echt keine Lust mich damit rumzuschlagen.

Schade drum. :-(

Trotzdem Danke für die Hilfe...

xpler schrieb:
> Da es unter W7 aber keinen
> Vollbildmodus mehr gibt

Ach. Alle Spiele laufen dann seit Windows 7 in Fenstern?

Klar gibts nen Vollbildmodus; du musst halt DirectX benutzen.
Das deine Kenntnisse nicht ausreichen um ihn zu benutzen bedeutet noch 
lange nicht das es keinen Vollbildmodus mehr gibt.

Rufus Τ. Firefly schrieb:
> Es geht um den Textmodus, den gibt es nicht mehr.

Das wurde ja wohl hier schon oft genug gesagt.

Hier geht es um die Aussage:

xpler schrieb:
> Da es unter W7 aber keinen
> Vollbildmodus mehr gibt

welche schlicht und einfach falsch ist.
Textmodus != Vollbildmodus.

Textausgabe im Vollbildmodus, gibt es natürlich mit DirectX. Ist fast so 
einfach und sieht auch genauso aus wie die alte DOS-Konsole.

Whaaaa!

Moin,

ich grabe die Leiche nochmal aus.

Gesucht wird irgendwas (Programm, Library, C-Code oder weißderteufel) 
was mir unter Windows XP und Windows7 ein "Vollbilddosfenster" erzeugt. 
Ich brauche nur eine fixe Größe, eine Funktion "male Zeichen an Position 
xy" und sonst nichts. Die Details sind egal, hauptsache das ganze ist 
EINFACH!

Meine Versuche aus GTK was passendes zu basteln sind hiermit beendet, 
das Dingen ist so umfangreich dass man wahnsinnig wird.

xpler schrieb:
> Ich brauche nur eine fixe Größe, eine Funktion "male Zeichen an Position
> xy" und sonst nichts.
dann mach doch einfach ein schwarzen vollbild fenster und zeichen die 
Zeichen mit den normalen Windows funktionnen.

Peter II schrieb:
> xpler schrieb:
>> Ich brauche nur eine fixe Größe, eine Funktion "male Zeichen an Position
>> xy" und sonst nichts.
> dann mach doch einfach ein schwarzen vollbild fenster und zeichen die
> Zeichen mit den normalen Windows funktionnen.
Das ist leider alles andere als "einfach"...

Achso, ich brauche Double Buffering. Wenn es eine Funktion "kompletten 
Buffer kopieren" bzw. umschalten gibt kann ich das aber selber machen.

Rufus Τ. Firefly schrieb:
> Sieh Dir mal das hier näher an:
> http://sourceforge.net/projects/console/

Das sieht schon ziemlich gut aus, leider stürzt 5 Sekunden nachdem ich 
mein Programm gestartet habe cmd.exe ab, reproduzierbar unter XP und 
7... Wenn ich das Programm unter XP direkt starte funktioniert alles 
prima.

Schade! Danke trotzdem.

xpler schrieb:
> cmd.exe
wahlweise auch console.exe wie ich gerade feststelle. Offensichtlich mag 
das Dingen es nicht wenn man den Buffer umschaltet 
(SetConsoleActiveScreenBuffer()). Könnte aber auch was anderes sein, nur 
kurz angetestet.

Also den Fullscreen hab ich bisher nicht unter Win7 einstellen können, 
aber Zeilen/Spalten des Fensters:

1

bool setWindowSize(short x, short y)

2

{

3

  SMALL_RECT srWindow;

4

5

  srWindow.Left  = 0;

6

  srWindow.Top  = 0;

7

  srWindow.Right  = x;

8

  srWindow.Bottom  = y;

9

10

  return SetConsoleWindowInfo(out, true, &srWindow);

11

12

}

Sorry... von jeweils x und y noch 1 abziehen...

und nochmal :)

1

bool set_window_size(short y, short x)

2

{

3

  if(x < 1 || y < 1) return false;

4

5

  SMALL_RECT  srWindow;

6

  COORD    coord;

7

8

  srWindow.Left  = 0;

9

  srWindow.Top  = 0;

10

  srWindow.Right  = x - 1;

11

  srWindow.Bottom  = y - 1;

12

13

  coord.X = x;

14

  coord.Y = y;

15

16

  return (SetConsoleWindowInfo(out, true, &srWindow) && SetConsoleScreenBufferSize(out, coord));

17

}

mit

1

// Globale Variablen

2

const HANDLE out = GetStdHandle(STD_OUTPUT_HANDLE); // Screenbuffer der Konsole