 |
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 20.12.2013, 01:11 Titel: |
|
|
TimesChange hat Folgendes geschrieben: | Frage dazu: Kann mir jemand sagen, ob das Grafikformat unter 64-Bit Windows das selbe ist (Palette mit 4 Bits / pixel)?
Sinn und Zweck der ganzen Übung ist ja, dass das Programm auch künftig z.B. unter Windows 7 / 8 /... in 64-Bit-Version läuft.
|
Ja, das hat überhaupt nichts mit der Bittigkeit des Systems zu tun. Die Konsole ist jetzt ja nicht gerade ein Feature, das super toll ausgebaut wird von Version zu Version, sondern bleibt kompatibel mit alten Terminals. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
TimesChange
Anmeldungsdatum: 20.11.2013 Beiträge: 85
|
Verfasst am: 20.12.2013, 01:33 Titel: |
|
|
OK, soweit klar. Jojo hat Folgendes geschrieben: | ... Die Konsole ist jetzt ja nicht gerade ein Feature, das super toll ausgebaut wird von Version zu Version... |
Schade. Ich hatte gehofft, das wird das neue Kernstück von Windows 9, weg mit den blöden Kacheln und Fenstern, back to the roots und so...
Jetzt ganz ernsthaft noch eine Anschlussfrage dazu:
Spricht irgendetwas dagegen, das Programm in Konsolenmodus laufen zu lassen, speziell in Bezug auf die "Zukunftstauglichkeit"?
Das Programm verrichtet bei mir seit mindestens 1993 (und ich habe ganz vergessen, das 20-jährige Jubiläum zu feiern...) seine Dienste, ist im Kern unverändert, und wurde nur gelegentlich bei Bedarf angepasst. Es wäre also schön, wenn es mich auch die nächsten 20 Jahre begleiten könnte
Ich "brauche" nicht mehr als den Konsolenmodus für diese Zwecke, es wäre nur ungeschickt, wenn ich jetzt mein Programm darauf umbaue, und in paar Jahren gibt's keine mehr.
Grüße
Rainer |
|
Nach oben |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1278 Wohnort: Ruhrpott
|
Verfasst am: 20.12.2013, 03:55 Titel: |
|
|
Da meines Wissens selbst die schickste und modernste Bedienoberfläche im Innersten immer noch auf DOS und die Kommandozeile aufsetzt (auch wenn Mickysoft sich alle Mühe gibt, das zu verbergen), dürfte uns die Konsole wohl noch eine ganze Weile erhalten bleiben.
Zitat: | Im Konsolenmodus ist das mit SCREEN erhaltene Farbattribut nur ein 8-Bit-Wert | Du hast tatsächlich Recht! Mir ist das in den ganzen Jahren noch nie aufgefallen, weil ich sowieso einen schwarzen Hintergrund habe. Und die Zeichenfarbe wird ja korrekt dargestellt. Sachen gibt's...
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
 |
Jojo alter Rang

Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 20.12.2013, 10:34 Titel: |
|
|
grindstone hat Folgendes geschrieben: | Da meines Wissens selbst die schickste und modernste Bedienoberfläche im Innersten immer noch auf DOS und die Kommandozeile aufsetzt (auch wenn Mickysoft sich alle Mühe gibt, das zu verbergen), dürfte uns die Konsole wohl noch eine ganze Weile erhalten bleiben. |
Das ist schon seit Windows NT nicht mehr der Fall. Das Terminal wird lediglich emuliert (deshalb der name NTVDM = NT Virtual DOS Machine).
Natürlich kann hier niemand den Trend voraussagen, dem Windows folgend wird, aber als Syadmin-Tool und ähnliches wird es die Konsole natürlich noch für lange Zeit geben, und selbst wenn es sie auf Windows nicht mehr geben soll, kann man immer noch einen beliebigen anderen Terminal-Emulator, auch unter Linux, verwenden. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
Nach oben |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1278 Wohnort: Ruhrpott
|
Verfasst am: 20.12.2013, 12:07 Titel: |
|
|
Jojo hat Folgendes geschrieben: | Das ist schon seit Windows NT nicht mehr der Fall. Das Terminal wird lediglich emuliert (deshalb der name NTVDM = NT Virtual DOS Machine). | OK, ich nehme alles zurück und behaupte das Gegenteil. Ich hatte da wohl noch WinME im Hinterkopf. Aber bist du wirklich ganz sicher, daß nicht doch noch heimlich, versteckt, irgendwo ganz tief im Kernel........? Nein...?
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
 |
St_W

Anmeldungsdatum: 22.07.2007 Beiträge: 956 Wohnort: Austria
|
Verfasst am: 20.12.2013, 16:35 Titel: |
|
|
DOS hat mit der NT Reihe von Windows nichts zu tun - wie Jojo schon gesagt hat werden DOS Programme unter Windows NT mit Hilfe der NTDVM ausgeführt.
Die NTDVM hat jedoch wiederrum mit der Konsole nicht wirklich was zu tun. Eine normale 32-Bit FreeBasic Konsolenanwendung braucht keine NTDVM. Die NTDVM wird nur für die Ausführung von 16-Bit DOS Programmen auf einem 32-Bit System benötigt.
Eine Konsolenapplikation ist also meines Erachtens sehr zukunftssicher, was dessen Ausführbarkeit betrifft. Trotzdem würd ich sagen, dass ein Endbenutzer heutzutage eine Grafische Oberfläche erwartet und eine Konsolenoberfläche als nicht mehr zeitgemäß empfindet. _________________ Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
Nach oben |
|
 |
TimesChange
Anmeldungsdatum: 20.11.2013 Beiträge: 85
|
Verfasst am: 20.12.2013, 18:44 Titel: |
|
|
St_W hat Folgendes geschrieben: | ...Trotzdem würd ich sagen, dass ein Endbenutzer heutzutage eine Grafische Oberfläche erwartet und eine Konsolenoberfläche als nicht mehr zeitgemäß empfindet. |
Da gebe ich dir schon recht.
In dem Fall bin aber ich der Hauptbenutzer (und wer aus meiner Familie das sonst noch nutzen will) , mir ist das Programm mit ein paar einfachen Rahmen aus ASCII-Zeichen und farbigem Hintergrund "grafisch genug".
Und es ist halt ungeschlagen schnell: Ich brauche vom Anklicken des Programmsymbols auf dem Desktop rund 3 Sekunden, bis ich die gesuchte Adresse / Tel-Nr. sehe. Gut, vielleicht würde man das auch in "hübsch" so schnell hinbekommen.
Wo ich einen gewissen Nachbesserungsbedarf sehe, ist das etwas umständliche Übernehmen oder Einfügen von Daten in/aus anderen Quellen. Direktes copy and paste geht hier ja nicht (nur umständlich über BEARBEITEN...)
Das würde den praktischen Nutzen erhöhen.
Ich werde mal im Forum suchen, ob ich was dazu finde, wie man Daten aus FB in die Zwischenablage bekommt. Wenn ich nichts finde, frage ich hier nochmal in einem neuen Thema nach.
Grüße
Rainer |
|
Nach oben |
|
 |
dreael Administrator

Anmeldungsdatum: 10.09.2004 Beiträge: 2529 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 20.12.2013, 22:40 Titel: |
|
|
Zum Titelthema: FreeBasic versucht hier aus Rückwärtskompatibilität das Verhalten von SCREEN 9, also damals den EGA-BIOS-Aufruf INT 10h, AH=00, AL=10h möglichst gut nachzubilden, was auch zum besagten Verhalten führt.
Da derartige "Krücken" bei Neuentwicklungen keinen Sinn mehr machen, ist ScreenRes logischerweise sinnvoller, wo COLOR ein logisches und konsistentes Verhalten besitzt.
Logischerweise emuliert FreeBasic auch bei ScreenRes einen Paletten-Videomodus bei niedrigen Farbtiefen, da inzwischen selbst der billigste PCs mit Onboard-VGA schon seit über 10 Jahren eine True Color-Videokarte besitzt. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
 |
TimesChange
Anmeldungsdatum: 20.11.2013 Beiträge: 85
|
Verfasst am: 21.12.2013, 02:49 Titel: |
|
|
Die Variante mit SCREENRES hätte ich auch gerne genommen, aber dort fehlt mir der cursor für meine Eingaberoutine. Mit einem "normalen" cursor konnte mir nemored zwar aushelfen, doch einen Einfüge-Cursor konnte ich so nicht realisieren.
Grüße
Rainer |
|
Nach oben |
|
 |
dreael Administrator

Anmeldungsdatum: 10.09.2004 Beiträge: 2529 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 21.12.2013, 19:21 Titel: |
|
|
Hier musst Du halt ggf. selber eine Cursor-Emulation implementieren, also diesen mit LINE ,BF zeichnen. Dabei SLEEP mit Zeitangabe für die Blinkzeit verwenden. Dabei das "vermalte" Zeichen einfach wieder mit PRINT frisch ausgeben. Tastatur mit Inkey abfragen.
Sinnvollerweise alles in eine SUB hineinpacken.
Siehe dazu auch
http://www.dreael.ch/Deutsch/BASIC-Knowhow-Ecke/BildschirmMasken.html
aus meiner Sammlung. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4699 Wohnort: ~/
|
Verfasst am: 21.12.2013, 20:58 Titel: |
|
|
Ich würde einen Bildpuffer in Größe des Cursors vorschlagen, der mit der Hintergrundfarbe befüllt ist und über PSET gesetzt wird. Dann kannst du, falls gewünscht, auch mit der Methode XOR setzen, um den Buchstaben in umgekehrter Farbe darzustellen. Alternativ kann man statt mit unterschiedlichen Cursor-Höhen auch mit verschiedener Anzeigelänge arbeiten (0.8 sec an, 0.2 sec aus o. ä.) _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1278 Wohnort: Ruhrpott
|
Verfasst am: 22.12.2013, 14:59 Titel: |
|
|
ScreenRes wäre sehr viel schöner, wenn es1. threadsicher wäre und
2. etwas mehr Auswahl an Schriftgröße und -art hätte
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
 |
nemored

Anmeldungsdatum: 22.02.2007 Beiträge: 4699 Wohnort: ~/
|
Verfasst am: 22.12.2013, 17:59 Titel: |
|
|
@Threadsicherheit: da ist ja nicht SCREENRES das Problem, sondern die implementierten Grafikbefehle.
Für mehr implementierte Schriftarten und -größen würde entweder die der Grafikbibliothek mitgelieferte Datenmenge enorm anwachsen oder man müsste (wesentlich praktischer) auf die Systemfonts zurückgreifen. Letzteres sollte über externe Bibliotheken möglich sein (siehe http://www.freebasic-portal.de/befehlsreferenz/externe-bibliotheken-639.html), damit habe ich mich aber noch nicht auseinandergesetzt.
DRAW STRING bietet übrigens auch die Möglichkeit, einen komplett eigenen Schriftsatz einzubinden; Volta hat dazu auch ein ausführliches Beispiel ins Portal gestellt. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
 |
dreael Administrator

Anmeldungsdatum: 10.09.2004 Beiträge: 2529 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 22.12.2013, 18:51 Titel: |
|
|
Lösung bei nicht thread-sicheren Bibliotheken/Befehlen: MUTEXCREATE und die ganze Befehlsfamilie drum herum, d.h. in diesem Fall musst Du halt mit einem Mutex selber einen "Verkehrspolizisten auf die Kreuzung" stellen.
Dazu am besten sämtliche GFX-Aufrufe in eine FreeBasic-Klasse einkapseln, diese ruft dann sämtliche LINEs, CIRLCEs usw. mit vorangehendem MUTEXLOCK und nachfolgendem MUTEXUNLOCK auf.
=> Somit kann die übrige FB-Anwendung dem heutigen 4-Kern-Prozessor gerechtwerdend beliebig parallelisiert werden. :-) _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
 |
TimesChange
Anmeldungsdatum: 20.11.2013 Beiträge: 85
|
Verfasst am: 22.12.2013, 19:05 Titel: |
|
|
Zwischenfrage des "interessierten Laien":
Was bedeutet thread-Sicherheit bei Screenres praktisch für mich?
Kann es schon zu unerwünschten Inkonsistenzen oder sonstigem digitalem Schweinkram kommen, wenn ich mehrere mit FB erzeugte Programme laufen lasse, die SCREENRES und Grafikbefehle benutzen?
Ansonsten bin ich sehr froh, dass ich es nach etlichen Stunden endlich geschafft habe, ein bis jetzt fehlerfrei laufendes Programm zu habe, das nun tut was es soll... auch wenn es derzeit nur der Konsolenmodus ist.
Grüße
Rainer |
|
Nach oben |
|
 |
Sebastian Administrator

Anmeldungsdatum: 10.09.2004 Beiträge: 5969 Wohnort: Deutschland
|
Verfasst am: 22.12.2013, 19:34 Titel: |
|
|
TimesChange hat Folgendes geschrieben: | Was bedeutet thread-Sicherheit bei Screenres praktisch für mich? |
Es dürfen nicht mehrere Threads innerhalb desselben Prozesses gleichzeitig auf den Screen zugreifen bzw. darauf herummalen. Da muss ein Thread auf den anderen warten oder man wickelt alle Grafikfunktionen in einem eigenen Grafikthread ab. Und die anderen Threads greifen dann nicht auf den SCREEN zu.
TimesChange hat Folgendes geschrieben: | Kann es schon zu unerwünschten Inkonsistenzen oder sonstigem digitalem Schweinkram kommen, wenn ich mehrere mit FB erzeugte Programme laufen lasse, die SCREENRES und Grafikbefehle benutzen? |
Nein, da muss man sich keine Sorgen machen, wenn sich die Programme nicht z. B. gemeinsame Dateien wie eine Adressdatenbank-Datei teilen, auf die alle Prozesse gleichzeitig zugreifen wollen.
Wenn du ein Programm mehrmals parallel startest (mehrere Prozesse) oder ganz verschiedene FB-basierte Programme gleichzeitig laufen lässt, laufen sie isoliert voneinander. Jedes hat seinen eigenen Speicherbereich, auf den das jeweils andere nicht zugreifen darf. _________________
Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
Nach oben |
|
 |
dreael Administrator

Anmeldungsdatum: 10.09.2004 Beiträge: 2529 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 22.12.2013, 19:38 Titel: |
|
|
TimesChange hat Folgendes geschrieben: | Was bedeutet thread-Sicherheit bei Screenres praktisch für mich? |
Wikipedia:
http://de.wikipedia.org/wiki/Threadsicherheit
Denke an folgendes ganz einfache Beispiel:
Überlegung: Wenn Thread A die Variable a liest, um a+1 auszuwerten und genau dann vom Multitasking unterbrochen wird, Thread B nun auch genau diese Anweisung ausführt (selbe Variable und damit Speicher!) und danach Thread A fortfährt (=weist nun das Ergebnis von zuvor an a zu), was passiert dann wohl?
Sei a ein Zähler für etwas Erledigtes, Threads A und B möchten sich "rückmelden" und a erhöhen. Sei a = 4 bisher
Vom Programmierer erwartet: a = 6 (jeder Thread hat a um 1 erhöht).
Realität, wenn Thread A genau zwischen Lesen und wieder zuweisen unterbrochen wird und Thread B sein a=a+1 währenddessen ausführt: a = 5! Warum? Thread A hat Zählerstand 4 ausgelesen, Addition ausgeführt und wurde unterbrochen. Thread B liest ebenfalls a aus (besitzt immer noch 4!) und erhöht diese und kann meinetwegen das Ergebnis noch imselben CPU-Zeitschlitz zuweisen => a=5 jetzt. Thread A fährt nun fort: Ergebnis 5 an a zurückschreiben: Bemerkt Veränderung natürlich nicht und prompt steht der Zähler am Schluss entgegen den Absichten vom Programmierer immer noch bei 5!
Lösung: Erhöhung dieses gemeinsamen a = kritischer Abschnitt
http://de.wikipedia.org/wiki/Kritischer_Abschnitt
=> Mutex drumherumbauen. Wenn jetzt Thread A auch wieder mittendrin unterbrochen wird, dann _muss_ Thread B warten (=Betriebssystem beendet CPU-Zeitschlitz vorzeitig), bevor es ebenfalls a=a+1 ausführen kann. => Jetzt kann Thread A sein a=a+1 noch vollständig beenden, d.h. Wert 5 zurückschreiben. Mit dem UNLOCK gibt A den kritischen Abschnitt frei, womit anschliessend Thread B hineinkommt. Weil B nun diesmal den von A geupdateten Wert 5 ausliest und somit 6 zurückschreibt, funktioniert nun unser Zähler wie vom Programmierer erwartet.
Wenn nun eine Bibliothek intern Ressourcen verwendet, auf welche nur ein Thread aufs Mal zugreifen darf und die nötigen LOCKs und UNLOCKs bereits intern selber macht, dann ist die Bibliothek threadsicher. Ist sie dies nicht, verwendet aber entsprechende Ressourcen, dann musst Du als Anwendungsprogrammierer selber die nötigen LOCKs und UNLOCKs machen.
/edit: Kurz ein Herumspiel-Beispiel zusammengeschustert:
Code: | ' Thread-Beispiel
Dim Shared zaehler As Integer, m As Any Ptr
Sub ThreadAufgabeUnsicher(ByVal p As Any Ptr)
Dim i As Integer, j As Integer
For i=1 To 100
j = zaehler + 1
Sleep 20 + 10 * Rnd
zaehler = j
Sleep 1 + 5 * Rnd
Next i
End Sub
Sub ThreadAufgabeSicher(ByVal p As Any Ptr)
Dim i As Integer, j As Integer
For i=1 To 100
MutexLock m
j = zaehler + 1
Sleep 20 + 10 * Rnd
zaehler = j
MutexUnLock m
Sleep 1 + 5 * Rnd
Next i
End Sub
Dim i As Integer, t(9) As Any Ptr
ScreenRes 640, 480
Width 80, 30
zaehler = 0
For i = 0 To 9
t(i) = ThreadCreate(@ThreadAufgabeUnsicher)
Next i
Print "Threads Variante Unsicher gestartet."
For i = 0 To 9
ThreadWait t(i)
Next i
Print !"Ende Thread-Verarbeitung. Z\132hler = "; zaehler
zaehler = 0
m = MutexCreate
For i = 0 To 9
t(i) = ThreadCreate(@ThreadAufgabeSicher)
Next i
Print "Threads Variante Sicher gestartet."
For i = 0 To 9
ThreadWait t(i)
Next i
MutexDestroy m
Print !"Ende Thread-Verarbeitung. Z\132hler = "; zaehler
Sleep |
Hinweis: Man achte auf die Zählerstände am Schluss! _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
 |
TimesChange
Anmeldungsdatum: 20.11.2013 Beiträge: 85
|
Verfasst am: 22.12.2013, 21:08 Titel: |
|
|
Danke für eure Erläuterungen dazu (in Wiki habe ich natürlich auch schon nachgesehen, um überhaupt zu wissen was damit gemeint sein könnte).
Interessantes Code-Beispiel, es ist immer leichter, wenn man etwas in der Praxis sehen kann, als es sich nur vorzustellen.
In meinem Fall muss ich mir also keine Sorgen machen, da meine Programme wirklich sehr "basic" im wahrsten Wortsinne sind, und 'sequentiell' abgearbeitet werden.
Grüße
Rainer
P.S. Zur Zwischenablage habe ich etwas gefunden und eingebaut. Jetzt kann ich auch einen Adressensatz mit CTRL-C in die Zwischenablage kopieren. |
|
Nach oben |
|
 |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1278 Wohnort: Ruhrpott
|
Verfasst am: 22.12.2013, 21:38 Titel: |
|
|
@nemored: Man müsste einen Dreh finden, TrueType-Fonts einzubinden. Aber da dürfte es wohl weniger Arbeit sein, sich eine "richtige" GUI zu basteln.
@dreael: Danke für den Tip, ich werde es mal versuchen. Ich hatte bei dem Colochessum (vormals "engine_vs_engine"), an dem ich gerade schreibe, einmal versucht, eine Mausabfrage mit eigenem Thread zu programmieren - mit dem Erfolg, daß das Programm nach spätestens 20 Sekunden abgestürzt ist. Wenn ich jetzt wenigstens die Tastaturabfrage auf "Chr(255,107)" (X) zum Programmbeenden in einen Thread packen könnte, wäre das schon eine große Erleichterung.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
 |
ThePuppetMaster

Anmeldungsdatum: 18.02.2007 Beiträge: 1839 Wohnort: [JN58JR]
|
Verfasst am: 23.12.2013, 00:52 Titel: |
|
|
PS: threadproblematische befehle sind gfx, io und sleep! .. Sprich, alle zusammen dürfen nicht aus mehreren threads heraus wechselseitig aufgerufen werden! (AUCH SLEEP!!!)
MfG
TPM _________________ [ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
Nach oben |
|
 |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|