Leserbriefe
Restaurierung eines Fensterinhaltes
In bezug auf den Artikel „Windows unter GEM“ aus der ST-Computer 9/89 habe ich folgende Frage: Warum ist GEM nicht in der Lage, einen Fensterausschnitt selbständig zu restaurieren, zum Beispiel nach einer Objektbearbeitung? Die selbständige Restauration ist nach dem Herunterklappen eines PulLDown-Menüs laut Literatur ebenso möglich wie die des Desktop-Fensters (Fenster 0). Glaubt man der Literatur, ist die Applikation für die Restauration anderer Windows selbst verantwortlich. Betrachtet man aber zum Beispiel die Restauration eines Fensters bei SIGNUM!2, etwa nach dem Aufruf des Info-Objektes im „Desk“-Menü unter Punkt „SIGNUM!“ kann es sich hier nicht um eine Routine handeln, die den Bereich löscht und dann mit VDI-Routinen neu zeichnet. Gerade bei der Darstellung von aufwendigen mathematischen Routinen wäre so ein Vorgehen zu langsam. Es wäre sehr hilfreich, wenn Sie mir hier eine Lösung vorschlagen könnten. In allen von mir gefunden Literaturwerken über die GEM-Programmierung unter C wird diesem Problem elegant ausgewichen, indem der Arbeitsbereich des Fensters ein Objekt ist, oder alles mit VDI-Routinen neugezeichnet wird (unglaublich langsam).
Tim N., 7303 Neuhausen/ Tilder
Red.: Sie haben mit der Behauptung recht, das GEM könne das Neuzeichnen der Fenster 1 bis n nicht selbst übernehmen, was auch sinnvoll ist, wenn ich mich am Anfang zugegebenermaßen auch geärgert habe. Stellen Sie sich ein kleines Fenster vor, daß einen Ausschnitt eines Bildes darstellt. Dieses Fenster stellt je nach Position auf dem Bildschirm einen Teil des Bildes dar. Eine anderer Methode wäre aber, auch den Ausschnitt des Bildes, wie es normalerweise der Fall ist, unabhängig von der Position und abhängig von benutzbaren Fensterpfeilen zu machen. Sicherlich fallen Ihnen selbst genug Beispiele ein, bei denen man sich vorstellen kann, daß die Aufgaben zu speziell beim Restaurieren des Bildschirms währen, als daß das GEM diese automatisch selbst übernehmen könnte.
Zunächst gehe ich einmal an dieser Stelle davon aus, daß das Restaurieren von Fenstern mit Hilfe der Rechteckliste bekannt ist, was man ansonsten in den ST-Ecken ST-Computer 5/87 und 6/87 nachlesen kann. Sollten Sie den Anwendungsfall haben, daß entweder Fenster nur verschoben werden. so daß sich deren Inhalt nicht verändert oder Sie kurzzeitig beispielsweise den Hintergrund. der aus mehreren Fenstern bestehen könnte, mit einer Dialogbox verdecken, so schlage ich Ihnen vor. daß Sie die Inhalte der Fenster oder sogar den Gesamthintergrund mit vro_cpyfm() speichern. Sollen später die Fenster neugezeichnet werden, kann man auf einen Schlag die gesamte (Hintergrund-)Grafik, die vor der Zerstörung gesichert worden ist, wieder restaurieren. Sie werden sicherlich erkennen, daß bei den wenigsten Programmen der Inhalt eines Fensters beim Verschieben des selben tatsächlich neugezeichnet wird. Beachten Sie aber bitte, daß beim Verschieben eines Fensters auf ein anderes Überlappungen der einzelnen Fenster stattfinden, so daß man den Gesamtinhalt der Fenster im Speicher haben und bei der Restaurierung mit der Rechteckliste arbeiten muß. Zusammenfassend kommt man meist mit dem Abspeichern des Hintergrundes aus, da viele Programme mit nur einem Fenster arbeiten. Bitte führen Sie das Abspeichern des Hintergrundes aber mit vro_cpyfm() und nicht mit einem normalen Speicherkopieren durch. Eine Erklärung von vro_cpyfm() findet man in der ST-Ecke der ST-Computer 11/87.
XModem-Protokoll
Nach mehreren vergeblichen Versuchen, ausführliche Informationen über DFÜ-Protokolle zu erhalten, wende ich mich jetzt an Sie. Ich benötige genaue Spezifikationen über die DFÜ-Protokolle „Kermit“ und „XModem“. Können Sie mir vielleicht Literaturhinweise geben, wo die erforderlichen Protokollspezifikationen getroffen sind?
Stefan R., Aachen
Red.: Das XModem-Protokoll nach Ward Christensen ist tatsächlich nur spärlich beschrieben worden. Eine genaue Erklärung würde den Rahmen der Leserbriefseite sprengen. Es existieren jedoch zwei sehr gute Beschreibungen. Eine wurde von Chuck Forsberg verfaßt, kann in vielen Mailboxen (z.B. im Brett ‚Dokumentationen“ in der MILLIWAYS-Mailbox Essen) nachgelesen werden und ist sicherlich die beste in jeder Hinsicht. Ein leicht verständlicher Artikel ist auch in der Zeitschrift „Computer Persönlich“, Ausgabe 11/85 (M&T) erschienen. Im Rahmen unserer DFÜ-Ecke werden wir auch noch näher auf solche Protokolle eingehen.
Kein Erfolg ohne ROM-TOS
Ich besitze einen ATARI 520ST+ mit einem neuerworbenen Disketten TOS (6.2.1986). Seit kurzer Zeit betreibe ich einen Fernseher am ST, und somit bot sich mir die Möglichkeit, ein Farbspiel zu erwerben. Da ich das Spiel „FALCON F 16“ aber nicht zum Laufen brachte, wurde mir auf meine Anfrage hin erklärt, daß man dazu ein ROM-TOS benötige. Gibt es keine andere Möglichkeit, solch ein Spiel mit einem Disketten-TOS zum Laufen zu bringen, außer einem nachträglichen ROM-TOS-Einbau? Benötigen die meisten Spiele ROM-TOS? Aus welchen Grundfunktionieren die meisten Spiele nur mit ROM-TOS? Da in der der Anleitung auch ein 520ST/FM angeführt ist, meine ich, daß die Größe des Speichers nicht ausschlaggebend ist.
Holger H., 8856 Harburg
Red.: Im allgemeinen gibt es drei Gründe, warum ein Spiel nicht laufen kann. Das ist zum einen ein nicht ausreichender Speicher. Bedenkt man, daß beim Laden eines RAM-TOS bis zu 250 kB verlorengehen, ist ein Spiel, das nur unter ROM-TOS (welches im Vergleich viel weniger Speicher verbraucht) läuft, unter RAM-TOS nicht lauffähig. Der zweite Punkt kann sein, daß das fragliche Spiel Wert auf ein bestimmtes TOS legt. Dazu ist zu sagen, daß dann dieses Spiel unsauber programmiert ist, diese Tatsache auf der Verpackung angegeben sein oder die entsprechende Firma eine neuere Version liefern sollte. Es scheint bei Ihnen so zu sein, daß das Spiel eine bestimme TOS-Version benötigt (die Version, die Sie als RAM TOS vorliegen haben). Da das Spiel aber wahrscheinlich gebootet werden muß, ist es nicht möglich, das TOS vorher von der Diskette zu booten und danach das Spiel zu laden - zwei Applikationen nacheinander lassen sich nun einmal nicht booten.
Line-A bei Turbo-C
Ich habe Ihren Artikel über das Line-A interessiert gelesen, habe da aber ein kleines Problem: Da ich mit Turbo-C arbeite und Sie die Routinen nur für MEGAMAX LASER C vorgesehen haben, hatte ich einige Anpassungsschwierigkeiten. Wie realisiere ich die Assemblerroutinen für die Aufrufe der Line-A-Routinen (an dieser Stelle zeigt der Compiler viele Fehlermeldungen an)? Falls Sie sich mit Turbo-C auskennen und die nötigen Umänderungen kennen. wäre ich Ihnen sehr dankbar, wenn Sie mir entspre chend Antwort geben könnten.
Daniel S., 6054 Rodgau 1
Red.: Leider sind Sie meines Erachtens genau auf DEN Schwachpunkt von Turbo-C gestoßen, der so oft sogar als Vorteil dargestellt wurde (Kompatibilitätsgründe zu anderen Rechnern etc.). Nämlich den, daß es die Möglichkeit bietet, Assemblerroutinen mit einem externen Assembler zu linken. Dadurch hat man sich die Arbeit erspart, einen Inline-Assembler zu implementieren, der während des Compilierens auch Assemblercode umsetzen kann. Leider sind dadurch so elegante Methoden, wie ich sie unter LASER C verwenden konnte, nicht möglich. Daher bleibt Ihnen, wollen Sie Turbo-C verwenden, nichts anderes übrig, als die entsprechenden Teile mit einem Assembler zu implementieren, später als eigene Unterroutinen zu linken und aufzurufen. Dies haben wir in der ST-Computer 1/89 an einem (nicht vollständigen und einfachen) Line-Binding gezeigt. Hier wurde das Binding vollständig in Assembler durchgeführt.
SIGNUM!-Texte auf MS-DOS
Können Sie mir bitte einen Tip geben, wie ich einen mit einem ATARI 1040ST (Programm Signum!2) geschriebenen Text einer wissenschaftlichen Arbeit in ein von einem Verlag vorgegebenes MS-DOS-Diskettenformat (720k-3.5“) umwandeln kann.
Bernhard G., HOOO München
Red.: Das Abspeichern der Daten auf einer Diskette, die von MS-DOS lesbar ist, ist relativ einfach. Zur Formatierung dieser Diskette können Sie auf dem ATARI beispielsweise das Programm HYPER-FORMAT verwenden, welches bei dem Buch Scheibenkleister dabei ist. Auf eine so formatierte Diskette kann der ATARI ST wie auch ein MS-DOS-Rechner ohne Probleme zugreifen, da dieses Diskettenformat praktisch identisch ist. Das größere Problem, das Sie aber haben dürften, ist, daß es auf dem MS-DOS-Rechner kein Programm gibt, welches das Format eines SIGNUM-Dokumentes verstehen kann (.SDO), zumal in einer solchen Datei nicht nur der eigentliche Text sondern auch Formatierungskennzeichnungen, Buchstabenpositionen, Bilder und vieles mehr zu finden sind. Das bedeutet, daß Sie Formeln, die Sie in Signum! fein säuberlich zusammengebastelt haben, so nicht auf einem MS-DOS-Rechner verwenden können. SIGNUM!2 bietet aber die Ausgabe des Textes (!) als ASCII-Datei, die jede andere Textverarbeitung verstehen wird, die aber weder Formatierungskennzeichnungen (fett, kursiv etc.) noch Bilder enthält; Formeln werden in einzelne Zeilen auseinandergezogen ausgeben. Achten Sie dabei darauf, daß Sie die Funktionen Seitenumerierung und Randausgleich vor dem Abspeichern ausschalten, da Sie ansonsten mühsam die Seitenzahlen und doppelte Leerstellen von Hand entfernen müssen. Sie werden außerdem auf der MS-DOS-Seite die gesamte Layout-Bearbeitung sowie eventuelle Bilder neu gestalten müssen!