Mit der Maus um die Welt - Datenfernübertragung näher beleuchtet

Im Zeitalter des Informationsaustauschs mittels elektronischer Medien gewinnt ein bestimmter im Vergleich zum Radio, Fernsehen und Telefon bislang eher vernachlässigter Bereich immer mehr an Bedeutung. Datenfernübertragung, direkt von Computer zu Computer, oft über tausende von Kilometern hinweg, wird mehr und mehr zur Selbstverständlichkeit.

Bereits im täglichen Lieben werden wir mit diesem relativ neuen Kommunikationsmedium konfrontiert. Das Telefax sei hier nur ein Beispiel. Auch dieses praktische Übertragungsmedium beruht konzeptionell auf der Datenfernübertragung. Dabei werden Texte und Grafiken digitalisiert, die Daten per Telefonleitung verschickt und beim Empfänger wieder zu dem ursprünglichen Dokument zusammengesetzt und ausgedruckt. Das alles geschieht so schnell, daß der Anwender kaum etwas davon merkt. Doch was passiert eigentlich genau? Wie werden die Daten über die Telefonleitung geschickt? Was gibt es sonst noch für Anwendungsmöglichkeiten? Antworten auf diese Fragen werden Sie in dem folgenden Datenfernübertragungs (kurz: DFÜ)-Schwerpunkt bekommen.

Da wir die Anwendung des Fax schon öfter in früheren Ausgaben besprochen haben, wollen wir uns diesmal auf die reine Datenübertragung, also das Versenden von Texten, Programmen und Dateien in ihrer ursprünglichen Form, so, wie sie auf Disketten oder Festplatten vorliegen, beschränken. Was ist dazu notwendig? Zunächst einmal geht nichts ohne die entsprechende Hardware. Die Verbindung vom Computer zur Telefonleitung wird über ein Modem vorgenommen (Modem=MOdulator/DEModulator). Dieses Gerät verwandelt die digitalen Daten des Computers in hörbare Töne und zurück. Damit wird eine Datenübertragung per Telefon überhaupt erst möglich. Wichtig ist natürlich auch die Software. Auf der Anwenderseite sind das in der Regel sogenannte Terminalprogramme. Mit ihnen kann der Benutzer Verbindungen aufbauen, Daten und Texte übertragen und meist sogar eine Telefonnummerndatei verwalten. Über nähere Details wie Übertragungsprotokolle und Terminal-Emulationen informieren Sie sich bitte in den nebenstehenden Info-Kästen. Wir haben zwei der bekanntesten Vertreter der Terminal-Software für Sie herausgesucht und wollen sie einmal näher betrachten.

Rufus

Ein Hund, der nicht bellt, aber beißt!

Auf den eigenwilligen Namen „Rufus“ hört dieses Produkt aus dem Shareware-Bereich. Der Programmierer Michael Bernards arbeitet schon seit einigen Jahren an diesem Programm, und so liegt es mittlerweile in der Version 1.11 vor. Rufus ist ein reines GEM-Programm, benutzt also die üblichen Fenster, Dialoge und Menüleisten. Dies erleichtert den Einstieg in die DFÜ ungemein; ist die Bedienung doch ganz ähnlich wie bei einem GEM-Texteditor, den sicher jeder ATARI-Anwender schon einmal benutzt hat. Nach dem Start öffnet Rufus ein zunächst leeres GEM-Fenster. Hier finden die Ein- und Ausgaben statt. Alles, was vom Modem kommt, wird im GEM-Fenster als Text ausgegeben.

Einstellmöglichkeiten

Über ein Parametermenü lassen sich die hardwareseitigen Einstellungen der seriellen Schnittstelle vornehmen. Hier wurde bereits an die neuen ATARI-TT- und Mega-STE-Computer gedacht. Diese besitzen mehr als eine serielle Schnittstelle. Dadurch kann man beispielsweise ein Modem am Port „Modem 1“ und einen seriellen Drucker am Port „Modem 2“ betreiben oder auch zwei Modems parallel. Natürlich kann man auch auf die Hochgeschwindigkeitsschnittstelle (RS-423) des Mega-STE/TT umschalten, für die allerdings zur Zeit noch keine sinnvolle Anwendung existiert. Ungewöhnlich, aber sehr praktisch, ist allerdings, daß sich die Ein- und Ausgaben auch auf die MIDI-Schnittstelle umleiten lassen. Damit kann man schnell zwei ATARI-Computer zur Datenübertragung verbinden, ohne erst ein spezielles Kabel (Nullmodem) anfertigen zu müssen. Zwei handelsübliche DIN-Überspielkabel genügen.

Unter dem Menüpunkt Terminal verbirgt sich ein Dialog (der wie alle Dialogboxen ein „fliegender“ ist, sich also verschieben läßt), um die Terminal-Emulation auszuwählen. Rufus stellt insgesamt drei Emulationen zur Verfügung: TTY (entspricht den normalen ASCII-Zeichen), VT-52 und VT -100 (siehe Kasten „Terminal-Emulationen“). Unter VT-100 werden auch Grafiksymbole und Farben (auch Hintergrundfarben) korrekt dargestellt, wobei es wichtig ist, den korrekten Zeichensatz zu installieren (Rufus unterstützt GDOS. ein entsprechender ANSI-Zeichensatz ist im Lieferumfang bereits enthalten). Lediglich das Attribut „blinkend“ wird ignoriert. Dies stellt bei ATARI-Computern auch eine gewisse Schwierigkeit dar, da nicht auf eine Hardware-Unterstützung für blinkende Zeichen zurückgegriffen werden kann, wie dies beispielsweise bei DOS-Rechnern der Fall ist. In demselben Dialog können auch die Größe des Ausgabefensters (warum ist das nicht, wie üblich, über das Fenster direkt möglich?) sowie der verwendete Zeichenvorrat (ATARI, IBM, Macintosh, ISO-8859-1) eingestellt werden. Doch kommen wir zu den Übertragungsprotokollen.

Dateitransfer

Um Binärdaten zu senden bzw. zu empfangen, müssen softwareseitig sowohl beim Sender als auch beim Empfänger bestimmte Protokolle vereinbart werden (siehe Kasten „Übertragungsprotokolle“). Rufus ist hierbei mit einem flexiblen System ausgestattet worden, das es erlaubt, beliebige Protokolle auch nachträglich noch zu installieren. Dazu existieren die Typen X-Modem, X-Modem 1K, Y-Modem, Y-Modem-G, Z-Modem und EXTERN. Intern ist Rufus lediglich mit den X- und Y-Modem-Protokollen ausgestattet. Das Z-Modem-Protokoll wird nachgeladen, oder, falls das GEM-Z-Modem von Michael Ziegler als Accessory installiert ist, wird dieses von Rufus aufgerufen. Quasi beliebige Erweiterungen können Sie dabei durch den Typ EXTERN vornehmen. Hier kann der Benutzer, sofern er über die entsprechenden Module verfügt, auch andere Protokolle, beispielsweise Kermit, installieren. Insgesamt stehen zehn Slots zur Verfügung, dies sollte auch anspruchsvollen DFÜ’lern genügen.

Multitasking

Werden die internen Protokolle benutzt, ist sogar eine Art von Multitasking möglich. Es erscheint dabei keine Dialogbox, die den Rechner für andere Aufgaben lahmlegen würde, sondern ein GEM-Fenster. Auch während ein Up-oder Download läuft, kann man die Menüleiste bedienen, um beispielsweise Accessories aufzurufen. Unter der Betriebssystemerweiterung MultiGEM lassen sich sogar beliebige andere GEM-Programme parallel betreiben. Dieses Konzept erweist sich als sehr nützlich, ist doch der Computer während einer längeren Übertragung nicht blockiert. Man kann munter zum Beispiel mit einem Texteditor eine Nachricht schreiben, die man direkt nach dem Filetransfer verschicken möchte.

Telefonnummerndatei

Im Gegensatz zu älteren Versionen unterliegt bei Rufus 1.11 die Telefonnummerndatei keinerlei Beschränkungen mehr. Auch hier öffnet sich nun statt einer Dialogbox ein GEM-Fenster, und der Anwender kann beliebig viele Telefonnummern speichern.

Neu ist zudem, daß pro Telefonnummer auch der Modem-Initialisierungs-String und die RS-232 Parameter abgespeichert werden. Lästiges manuelles Umschalten kann daher entfallen. Die Einträge in der Liste lassen sich sortieren, verschieben oder unter Benutzung des GEM-Klemmbrettes aus anderen Programmen importieren. Auch eine Suchfunktion fehlt nicht.

Editor

Als weitere Neuerung hat der Programmierer einen kompletten GEM-Texteditor in Rufus eingebunden. Die Mitschriften einer Mailbox-Sitzung können so direkt, ohne das Programm zu verlassen, nach bearbeitet werden. VT-52- bzw. VT-100-Steuerzeichen werden dabei bereits beim Empfang automatisch herausgefiltert.

Batch-Verarbeitung

In Rufus schlummern aber noch mehr Möglichkeiten. Eine integrierte Batch-Sprache sorgt dafür, daß der Anwender viele sich wiederholende Vorgänge, beispielsweise Login-Sequenzen in Mailboxen, automatisieren kann. Das Besondere dabei ist, daß sich ausnahmslos alle Funktionen, die Rufus bietet, auch über die Batch-Sprache benutzen lassen. Dies geht vom Speichern des Protokoll-Puffers über Datei-Transfers mit beliebigen Übertragungsprotokollen bis hin zum Aufruf von Alertboxen und Abrufen der auf Funktionstasten definierten Texte, in dieser BASIC-ähnlichen Sprache sind Variablen vorhanden und bedingte Sprünge zu Labels möglich. Mit ein wenig Programmiererfahrung lassen sich mächtige Scripte erstellen, die dem Anwender die tägliche Arbeit wesentlich erleichtern können.

BTX

Um die Riege der Features vollzumachen, wird Rufus auch noch inklusive eines einfachen BTX-Software-Dekoders geliefert. Die Firma TKR hat freundlicherweise den BTX-Dekoder Multiterm-Mini für registrierte Rufus-1.11-Benutzer freigegeben. Über einen extra Menüpunkt kann dieser BTX-Modus jederzeit aktiviert werden. Multiterm-Mini reicht in jedem Fall aus, um normale BTX-Sitzungen durchzuführen. Es läßt sich sowohl als Programm als auch als Accessory installieren. Beide Modi werden von Rufus unterstützt. In einem GEM-Fenster finden alle Ausgaben statt. Abgerufene BTX-Seiten lassen sich als Text oder Grafik speichern. Wer über eine Grafikkarte mit mind 640x400 Punkten in 256 Farben verfügt, kann sich auch an der vollen Farbunterstützung von Multiterm-Mini erfreuen.

Zusammenfassung

Rufus macht einen ausgereiften Eindruck. Es gelang uns nicht, einen Absturz zu provozieren, auch bei Fehlbedienung bleibt Rufus standhaft. Die Übertragungsprotokolle sind sehr sicher, Fehler blieben aus. Besonders die Unterstützung eines externen, als Accessory installierten Z-Modems erweist sich als sehr nützlich. Erfreulich ist dabei, daß der Programmierer bereits an Multitasking-Betriebssysteme wie MultiGEM bzw. MultiTOS gedacht und ein offenes Konzept entworfen hat. Rufus-Benutzer sind damit auch für die weitere Zukunft gerüstet. Die Unterstützung von GDOS nimmt zwar einiges an Geschwindigkeit bei der Zeichenausgabe in Anspruch; hat man aber ein schnelles VDI (z.B. NVDI) installiert, macht sich diese Schwäche kaum bemerkbar. Kurz: Rufus 1.11 enthält alles, was ein DFÜ-Herz begehrt, und ist zudem durch das Shareware-Vertriebskonzept extrem preisgünstig. Die Vollversion kostet 50,-DM inkl. Handbuch. Wer sich schon für Rufus 1.0x registrieren ließ, hat bereits automatisch die neueste Version mit Handbuch kostenlos(!) zugeschickt bekommen. Eine Geste, die so langsam auch auf dem kommerziellen Markt Schule machen sollte.

Bezugsquelle:

Michael Bernards, Bussardweg 1, W-5204 Lohmar/Geber

Übertragungsprotokolle

Bei einer Datenübertragung per Telefonleitung entstehen prinzipbedingt des öfteren Fehler. Dafür können kurzzeitige Ausfälle der Leitung dafür verantwortlich sein, aber auch Knackser. Rauschen, Brummen und andere Nebengeräusche führen immer wieder dazu, daß die zu Tönen modulierten Daten nicht mehr korrekt zurückverwandelt werden können. Überträgt man reine Textdateien, wäre das nicht so gravierend, da man die Fehler leicht selbst korrigieren kann. Bei Programmen und nicht-ASCII-Dateien wirken sich solche Fehler aber sofort fatal aus. Es mußte eine Möglichkeit geschaffen werden, um Übertragungsfehler wirkungsvoll zu eliminieren. Findige Leute dachten sich schon vor etlichen Jahren ein Verfahren aus, das diese Fehler fast gänzlich ausschließt.

X-Modem

Eines der bekanntesten und wohl am weitesten verbreiten Übertragungsprotokolle ist das sogenannte X-Modem. Bei diesem einfachen Verfahren zerlegt der Sender die zu sendende Datei in 128-Byte große Blöcke und berechnet für jeden Block eine Checksumme, welche mit dem Block verschickt wird. Der Empfänger nimmt den Block und die Checksumme entgegen und berechnet seinerseits nach demselben Verfahren eine Checksumme. Stimmen beide überein, ist der Block fehlerfrei übertragen worden. Das quittiert der Empfänger mit einem bestirnten Steuerzeichen, worauf der Sender den nächsten Block absendet. Sind die Checksummen nicht identisch, liegt ein Fehler vor. und der Empfänger fordert den letzten Block noch einmal an. Durch dieses System ist einigermaßen sichergestellt, daß auch längere Dateien ohne Fehler übertragen werden können. Einige Nachteile hat X-Modem allerdings, zum einen führt die Blocklänge von nur 128 Bytes zu einem ziemlich großen Geschwindigkeitsverlust. Immerhin muß der Sender jedesmal auf eine Bestätigung des Empfängers warten und das alle 128 Bytes. Außerdem werden zusätzliche Bytes für die Checksumme und die Steuerzeichen übertragen. Das kostet alles Zeit. Bei Dateigrößen, die heutzutage nicht selten mehr als 100-KB betragen tritt hier schon eine deutliche Verzögerung ein Zeit ist Geld, gerade bei so kostspieligen Angelegenheiten wie Telefonverbindungen Als Modifizierung des X-Modem-Verfahrens setzte sich auch bald X-Modem-1K durch. Die einzigen Änderungen hierbei sind, daß die Blocklänge auf 1024 Bytes vergrößert und ein anderes Checksummenverfahren (CRC) angewendet wird. Aber auch damit sind die Anwender nicht zufrieden gewesen. Der Originalname der Datei sowie deren Länge wird bei diesem Verfahren nicht mit übertragen. Der Empfänger kann also immer nur ganze 1024-Bytes-Blöcke empfangen und so muß der Sender bei Dateilängen die nicht ohne Rest durch 1024 teilbar sind, den letzten Block mit Füll-Bytes auffüllen Das führt natürlich dazu, daß die Datei beim Empfänger länger wird als ursprünglich. Der Anwender muß sich selber darum kümmern, die überschüssigen Bytes wieder zu entfernen, genauso wie er den Dateinamen selbst angeben muß.

Y-Modem

Als Nachfolger des X-Modem-Protokoll wurde Y-Modem eingeführt. Auch hier arbeitet man mit 1024-Bytes großen Blöcken und einer CRC-Checksumme. Zu Beginn einer Übertragung wird zudem der Dateiname und die Dateilänge dem Empfänger mitgeteilt, so daß dieser die Datei korrekt anlegen kann. Mit der Y-Modem-Batch-Erweiterung lassen sich zudem auch mehrere Dateien übertragen, ohne daß der Anwender das Übertragungprotokoll jedesmal neu anwählen muß.

Z-Modem

Die Krönung der Übertragunsprotokolle stellt allerdings zur Zeit das Z-Modem-Verfahren dar. Dieses intelligente Protokoll hat neben allen Möglichkeiten, die auch Y-Modem-Batch zur Verfügung stellt, noch wesentlich mehr zu bieten. Um zusätzliche Geschwindigkeit zu erzielen, hat man das Blockverfahren modifiziert. Der Sender braucht nicht mehr nach jedem Block auf eine Bestätigung des Empfängers zu warten, sondern greift erst ein, wenn der Empfänger meldet, daß wirklich ein Fehler aufgetreten ist. Hierbei spielen auch variable Blocklängen eine große Rolle. Die Blockgröße ist nicht mehr starr auf 128- oder 1024 Bytes festgelegt, sondern variiert je nach Qualität der Telefonverbindung. Treten viele Fehler auf, schaltet Z-Modem die Blocklängen herunter auf (im Extremfall) bis zu 64 Bytes Wird die Verbindung wieder besser, werden auch die Blocklängen wieder hochgeschraubt. Bei sehr guten Leitungen, oder Verbindungen mit Hardware-Protokollen (MNP, V42) kann die Blocklänge bis auf 2048 Bytes oder mehr hochgesetzt werden Doch damit nicht genug Man stelle sich folgende Situation vor: Es soll eine 200KB-Datei übertragen werden. Bei 194-KB bricht die Verbindung aus unbekannten Gründen zusammen (soll es auch bei der Telekom geben). Was tun? Argem und den Download neu ansetzen! Nicht so beim Z-Modem-Protokoll. Nach dem Motto „was man hat, da hat man“ merkt der Empfänger beim folgenden Versuch, daß schon eine Datei gleichen Namens existiert. Ist diese kleiner als beim Sender, kann der Empfänger einen „Resume“ auslösen. Hierbei wird dem Sender automatisch mitgeteilt, wieviel von der Datei bereits vorhanden ist, und exakt an dieser Stelle die Übertragung wieder aufgenommen Wer unbedingt zwei Megabyte große Dateien downloaden will, aber nicht die Zeit für eine kompletten Übertragung „in einem Rutsch“ aufbringt, kann dies also getrost in 100-KB-Häppchen jeden Sonntag (zum Billigtarif) erledigen. Kein Byte geht dabei verloren.

Das externe GEM-Z-Modem-Protokoll sorgt für schnellen und sicheren File-Transfer.

Vorreiter auf dem Gebiet der Übertragungsprotokolle ist in Deutschland der Shareware-Programmierer Michael Ziegler. Er hat in einigen Jahren arbeit ein Z-Modem-Programm entwickelt, daß alle oben angeführten Eigenschaften beherrscht und darüberhinaus auch automatisch X- und Y-Modem Übertragungen erkennen und durchführen kann Eine im Leistungsumfang eingeschränkte Version liegt dem Terminalprogramm Rufus bei. Für 30,-DM kann jeder interessierte eine Vollverson erwerben

CM

Bezugsquelle: Michael Ziegler, Jagdfeldring 16, W-8013 Haar

STalker - der gesprächige DFÜ-Freund

Aus dem Geburtsland der DFÜ, Amerika, kommt ein Terminalprogramm, das in Deutschland unter dem Namen STalker von der Firma Computerware vertrieben wird. Zum Test lag uns die Version 3.0ld vor. Sie ist komplett ins Deutsche übersetzt. Auch die zwei, je 150 Seiten starke Handbücher sind in deutscher Sprache gehalten. Auch bei STalker wurde auf das GEM-Konzept, das der ATARI von Haus aus bietet, eingegangen. Ein lobenswerter Entschluß, denn dadurch ist das Programm auf allen Betriebssystem Versionen und mit verschiedener zusätzlicher Hardware (z B. Grafikkarten) einsetzbar. Während unseres Tests zeigten sich auch keine Unverträglichkeiten in Zusammenhang mit MultiGEM bzw. MultiTOS. Auch hier macht sich die saubere GEM-Programmierung vorteilhaft bemerkbar, wenn auch die Oberflächengestaltung nicht ganz dem zur Zeit aufkommenden Standard entspricht.

Parameterwust

Das erste, was an STalker auffällt, sind die äußerst umfangreichen Einstellmöglichkeiten. Neben den üblichen Parametern zu serieller Schnittstelle, Modem, Terminal-Emulation und Übertragunsprotokollen kann noch eine Vielzahl tiefergehender bzw. STalker-interner Vorbelegungen verändert werden. Doch immer der Reihe nach ... Der kanadische Programmierer von STalker war sich offensichtlich be wußt, was eine moderne Terminal-Software heutzutage leisten muß. VT-100/ ANSI-Terminal-Emulation und Z-Modem-Protokoll sind vorhanden. Aber auch die etwas älteren Standards wie VT-52 und X-/X1K-/Y- sowie Y-Modem/Batch-Protokoll werden unterstützt. Damit ist man mit STalker in den meisten Mailboxen gut bedient. Alle Übertragungsprotokolle sind intern fest in STalker verankert. Externe Übertragungsprotokolle lassen sich nicht einbinden. Allerdings wurde auch hier Wert auf Multitasking gelegt. Es gelang uns während der Testphase ohne Probleme einen Dateitransfer zu starten und gleichzeitig, ohne größere Behinderungen mit Accessories weiterzuarbeiten. In Sachen Terminal-Emulation wurden auch Nägel mit Köpfen gemacht. Der volle VT-100/ANSI-Standard wird unter stützt. Im praktischen Betrieb viel allerdings auf. daß die VT-100-Emulation mit einem spürbaren Geschwindigkeitsverlust bezahlt werden muß. Besonders das Scrolling ist so langsam, daß bei High-Speed-Verbindungen (v32/HST) mit Nachlaufzeiten bei der Textausgabe gerechnet werden muß. In Farbe sind zudem noch andere Einschränkungen gegeben. Zum einen entspricht die Farbbelegung nicht ganz dem ANSI-Standard (was sich allerdings durch Anpassen der Farbpalette ändern läßt), zum anderen werden Hintergrundfarben überhaupt nicht gesetzt. Eine Nachfrage bei Computerware ergab, daß letzteres Problem bekannt sei und man aus Geschwindigkeitsgründen auf Hintergrundfarben verzichten mußte.

Wahlkampf

Das Wählverzeichnis bietet Platz für maximal 30 Mailbox-Nummern. Für den Normalanwender ist dies mehr als ausreichend. Beachtenswert ist, daß zu jedem einzelnen Eintrag in der Nummernliste alle (wirklich alle!) einstellbaren Parameter mit gespeichert werden. Dazu existieren pro Eintrag 5 kleine Buttons, die mit den Buchstaben K, T, X, L, B bezeichnet sind. Darunter verbergen sich Parameterdialoge für „Kommunikations"-, „Terminal“-, „Protokoll“-, „Login“- und „Backtalk“-Parameter. Dadurch kann jede Mailbox mit einer individuellen Einstellung belegt werden. Selbst der Telefontarif pro Stunde und ein maximales Limit lassen sich angeben. Dies bewahrt den Anwender davor, die Zeit zu vergessen, während der Gebührenzähler bei der Telekom fleißig weiter tickt. Besonders bei Fernzonenverbindungen kann dies sehr schnell zu Überraschungseffekten bei Erhalt der nächsten Telefonrechnung führen.

Natürlich kann man auch mehrere Nummern anwählen, die dann nacheinander durchgewählt werden, bis eine Verbindung zustande kommt. Das Wählverzeichnis wird in einer separaten Datei abgelegt. Man kann derer mehrere anlegen und nachladen, um so die Begrenzung auf 30 Einträge zu umgehen.

Verstecken spielen

Besonders praktisch erweist sich die Möglichkeit, für jede eingetragene Mailbox eine individuelle Login-Phase ("L“-Button) anzulegen. Dazu kann man acht kurze Texte eingeben, auf die beim Login gewartet wird, und acht entsprechende Antworten, die STalker automatisch sendet. Dies reicht für die meisten Mailboxen aus, um den Login zu automatisieren. Als durchdacht erweist sich dabei, daß die Antwortzeilen auch „versteckt“ werden können. Sie werden dann beim nächsten Aufruf des Dialogs nicht mehr angezeigt und können nur komplett editiert, also neu eingegeben werden. Dies ist für Paßwörter besonders wichtig.

Editor

In STalker selbst ist kein Texteditor integriert. Es existiert allerdings eine Software-Schnittstelle, die den direkten Aufruf des aus dem selben Hause stammenden Texteditors „STeno“ ermöglicht. Ist dieser als Accessory installiert, können Texte direkt an ihn übergeben und weiterverarbeitet werden, ohne daß STalker dazu verlassen werden muß.

Das Bonbon

Auch STalker hat ein echtes Bonbon zu bieten. Gemeint ist die Batch-Sprache "BackTalk“. Der Ausdruck „Batch-Sprache“ ist für BackTalk eine glatte Untertreibung. Vielmehr handelt es sich hier um eine komplette, sehr stark an C angelehnte Programmiersprache, mit deren Hilfe ganze DFÜ-Applikationen erstellt werden können. Fast alle Strukturen und Möglichkeiten, die C bietet, sind auch unter BackTalk verfügbar. Variablen, allgemeine Funktionen, Ein- und Ausgabebefehle fehlen ebensowenig wie spezielle Unterprogramme und Funktionen, um Texte auf die von STalker konfigurierte Schnittstelle auszugeben und zu empfangen.

Es gehl sogar soweit, daß dem Programmierer einige GEM-Funktionen zur Verfügung stehen, um seine BackTalk-Programme leichter bedienbar zu gestalten. BackTalk ist eine „Compreter-Sprache“, also ein Zwischending zwischen Compiler und Interpreter. Das ASCII-Listing eines BackTalk-Programmes kann nicht direkt ausgeführt, sondern muß zunächst vom Compiler in einen Zwischen-Code übersetzt werden. Dieser wird dann von STalker interpretiert und das Programm ausgeführt.

Ein Stand-alone-Programm läßt sich also nicht damit erzeugen. STalker ist immer zwingend notwendig um BackTalk-Skripte auszuführen. Einige nützliche Beispiele werden mitgeliefert. Auch die fest in STalker integrierte Mailbox-Funktion ist nichts weiter als ein compiliertes Back-Talk-Skript. Es liegt erfreulicherweise auch im Source-Code bei, so daß der Anwender die Mailbox-Funktion beliebig erweitern oder verändern kann. Einen Nachteil hat diese komplexe Programmiersprache allerdings. Nichtprogrammierern fällt der Einstieg in BackTalk recht schwer. Grundkenntnisse der Programmiersprache C sind auf jeden Fall notwendig, auch wenn man nur kleine Skripte erstellen will. Für den erfahrenen Programmierer allerdings stellt BackTalk ein Paradies dar.

Fazit

STalker besticht, von einigen kleinen optischen Mängeln einmal abgesehen, durch stabile Funktionalität. Die komplexen Einstellmöglichkeiten schrecken den Neuling zunächst ab, bieten aber DFÜ-Profis für alle nur erdenklichen Probleme eine Lösung an. So richtig entfalten kann sich STalker aber erst in Verbindung mit der Batch-Sprache BackTalk. Hier wurde das Augenmerk ganz klar auf die Programmierer gesetzt. Wer Erfahrungen in der Programmiersprache C hat, dem sind Tür und Tor geöffnet. Für diesen Anwendungsfall ist STalker auch sein Geld wert.

Bezugsquelle:
Computerware Gerd Sender Weißer Straße 76 W 5000 Köln 50

Schlußbemerkung

Natürlich gibt es noch mehr als diese beiden Terminal Programme auf dem hart umkämpften ST-Markt. Besonders in der PD-Szene tummeln sich noch etliche Konkurrenten. ZurZeit stellen aber Rufus und STalker das Optimum dar. Zum einen wegen der sauberen GEM-Programmierung, die für Zukunftssicherheit bürgt, zum anderen durch die konsequente Berücksichtigung der DFÜ-Standards. Rufus ist dabei wegen der Überschaubarkeit der Funktionen und Einstellmöglichkeiten besser für den DFÜ-Neuling und Hob-byisten geeignet. Wer DFÜ professionell betreiben will und sich dazu seine eigene Spezialanwendung selbst programmieren kann, bekommt mit STalker und der Sprache BackTalk ein mächtiges Werkzeug an die Hand.

CM

Bildschirmemulationen

ASCII

Die Darstellung von Informationen auf dem Bildschirm eines Computers fand lange Zeit nur in reiner Textform statt Über sogenannte Video-Terminals (VT) waren die Benutzer mit einem Hauptrechner verbunden, der seine Informationen in Form von ASCII-Zeichen (ASCII = American Standard Code for Information Interchange) preisgab. Diese Zeichen stellen neben einigen wenigen Steuerzeichen nur die normalen alphanumerischen Schriftzeichen dar. Keine Spur von Grafik, oder Farbe. Auch heute ist dieses Verfahren noch üblich, wenngleich der Bedienungkomfort dadurch spürbare Einbußen erleidet.

VT-52

ATARI hat seinen ST-Rechnern bei der Textausgabe (TOS/TTP-Programmen) von Haus aus, neben dem normalen ASCII-Code auch einen VT-52-Emulator mitgegeben. Mithilfe bestimmter Steuerzeichen können damit schon einige Operationen, wie beliebiges Positionieren von Text, inverse Schrift, Löschen von einzelnen Zeilen oder eine Cursorsteuerung durchgeführt werden. Es ist verständlich, daß alle bekannten Terminalprogramme für ATARI-Computer diesen VT-52 Emulator nutzen. Leider erfreut sich dieser Standard in der DFÜ nur sehr weniger Beliebtheit...

VT-100

... hier ist man mit einer anderen Norm vertrauter. VT-100 heißt die Devise. Auch hier werden Steuerzeichen, bzw. ganze Steuersequenzen dazu benutzt, um auf dem Bildschirm verschiedene Aktionen auszulösen. Neben dem schon von VT-52 her bekannten Inversschalten der Schrift, gibt es unter VT-100 sogar Schriftattribute wie unterstrichen, hell, kursiv und blinkend. Zeichen oder Zeilen können eingefügt werden und als besonderer Leckerbissen kann man eine Scroll-Region definieren. Die Textausgabe findet dann nur noch innerhalb eines bestimmten Bereichs statt, in dem auch gescrollt wird. Der Rest des Bildschirms bleibt davon unberührt. Damit lassen sich beispielsweise Tabellen realisieren, deren Kopfzeilen immer sichtbar bleiben und deren Inhalte darunter hinweg scrollen. Bei der VT-100-ANSI-Norm kommt auch Farbe ins Spiel. Insgesamt 16 Farben sind möglich. In Verbindung mit Blockgrafikzeichen lassen sich damit schon recht anschauliche Grafiken erstellen. Es gibt heute kaum noch ein Mailboxsystem, daß es sich leisten kann, auf VT-100 Unterstützung zu verzichten. Es ist ganz klar ein Standard.

CM

---

---