Hallo, ich habe hier ein C-Programm für die Win32-Konsole welches auf den Vollbildmodus angewiesen ist. Um letzteren einzuschalten nutze ich die SetConsoleDisplayMode()-Funktion der Win-API. Unter Win XP funktioniert das auch prima. Jetzt soll das Programm auch auf einem anderen PC unter Windows 7 laufen und da wird es kompliziert: Der Aufruf von SetConsoleDisplayMode() erzeugt einen Fehler, GetLastError liefert ERROR_CALL_NOT_IMPLEMENTED --> This function is not supported on this system. Arghh!!! Einigen Google-Ergebnissen nach lässt sich die Konsole manuell nicht ohne Weiteres in den Vollbildmodus schalten, ob es per API geht konnte ich nicht rausfinden. Kennt sich da jemand aus? Zusammengefasst : Ich suche eine Möglichkeit das Konsolenfenster unter Windows 7 mittels C-Code in den Vollbildmodus zu versetzen. Das Dumme ist dass ich selber kein W7 zum testen habe und der PC steht viele Kilometer entfernt bei einem DAU. :-(
Es gibt unter Windows 7 keinen Konsolenvollbildmodus mehr, der wurde bereits mit "Vista" abgeschafft.
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???
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 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.
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
xpler schrieb: >> 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. Nein, ein DOS-Programm ist Dein Programm natürlich nicht. Du hast eine Win32-Konsolenapplikation geschrieben, denn sonst könntest Du gar nicht die verschiedenen Konsolfunktionen aufrufen.
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.
Es geht um den Textmodus, den gibt es nicht mehr. Mit irgendwelchem DirectX-Geraffel hat der rein gar nichts zu tun.
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.
Verzeihung, du bist aber auch verdammt schwer von Begriff. 1. Was ist denn so schwer daran das Platform SDK herunterzuladen? Nur weil es von Microsoft ist? Das ist dein Betriebssystem auch! Das PSDK hat nichts mit Visual Studio zu tun, sondern ist nur eine Ansammlung von Headern/Libs und noch ein wenig Kleinkram. 2. Hier haben mehrere Leute erklärt, was eine Konsole ist, was sie kann und was sie nicht können muss. Auch wenn Windows diese Features durch die Windows-API etwas erweitert, ist und bleibt die Konsole eine Konsole. Wie schon erwähnt gibt es nur Eingabe- und Ausgabestreams. So ein Konsolenprogramm muss nicht an dieses schwarze Fensterchen mit weißer Schrift gebunden sein, sondern kann von anderen Anwendungen angesprochen werden. Da werden dann Ein- & Ausgabestreams in den Speicher oder sonstwas umgeleitet. So kann man beispielsweise eine Software mit GUI machen, die ein Textfenster besitzt, wo ein Konsolenprogramm drin gestartet werden kann, dessen Text-Output wieder in das Textfenster gelangt. Ganz ohne schwarzes Fenster mit weißer Schrift! 3. Ist es heutzutage einfacher denn je eine Software mit grafischer Oberfläche zu erstellen. Schau dir beispielsweise QT an. Da gibt es sogar eine extrem einfach gehaltene IDE von Nokia (QT Creator), die out of the box funktioniert. Ohne Rumgebastel an der Windows API. Bei der GUI Applikation klickt man dann oben auf das Vollbild-Symbol und ist damit sogar auf dem neuesten Stand der Technik! xpler schrieb: > 1k LOC Hauptsache man hat die Script-Kiddy Abkürzungen drauf, nech?
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 |
Schmunzeln muß: Schade dass der Thread so alt ist, ich glaube ich hätte für xpler DIE Lösung (da er ja scheinbar keine Windowsprogramme erzeugen mag )...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.