Aus Raunheim und den USA: Programmiertips aus den Staaten und ein Interview mit Ataris Software-Support

Auch diesen Monat gibt es wieder den gewohnten Mix von Programmiertips und Gerüchteküche. Wir beginnen allerdings mit zwei Nachträgen in eigener Sache.

Im Begleitartikel zum Listing von »BigScreen« hat sich ein bedauerlicher Fehler eingeschlichen: BigScreen ist selbstverständlich nicht in C, sondern in Assembler geschrieben! Auch bei den Bildern im Artikel »Der weiche Großbildschirm« ging es nicht mit rechten Dingen zu: Natürlich läuft 1st Word plus bislang nicht fehlerfrei bei größeren Auflösungen! Die Iconleiste wird falsch plaziert, und Windows dürfen nicht mehr als etwa 30 Zeilen Text umfassen. Genau dies und ein Paket vom Großbildschirm-Entwickler Matrix war ja auch der Anlaß für GST, endlich wieder die Arbeit an »1st Word plus« aufzunehmen. Hoffentlich gibt es das neue 1st Word plus 3.0 bald!

Und nun zum Leserbrief von Herrn Eichholz in derselben Ausgabe: Der Fehler beruht auf einem Mißverständnis, an dem ich selbst auch mitschuldig bin. Selbstverständlich darf ein Accessory nicht auf den Stack zugreifen, um seine Basepage zu inspizieren, schließlich hat es gar keinen Stack. Lösung: Man ignoriert den Stackpointer und greift direkt auf den Speicher unmittelbar vor dem Programmstart zu: Dort sollte die Basepage zu finden sein. Leider ist auch diese Methode nicht ganz sauber, schließlich ist dies keine dokumentierte Eigenschaft von TOS — aber immerhin funktioniert es so auf allen mir bekannten TOS- und GEM-Konfigurationen. Eine kleine Bemerkung am Rande: Durch Inspektion der direkt vor dem Programmanfang liegenden Speicherseite überprüft ein Programm natürlich leicht, ob es von einem Link-Virus befallen wurde — dann ist nämlich garantiert die Basepage nicht mehr da, wo man sie vermutet.

Und noch eine abschließende Bemerkung in eigener Sache: Auch mein Hard-Disk-Cacheprogramm »HaBoo« unterstützt mittlerweile das »XBRA«-Verfahren und ist auf der aktuellen Leserservice-Diskette erhältlich.

Allan Pratt, Programmierer der aktuellen GEMDOS-Version, ist glücklicherweise nach wie vor auf USENET hochaktiv und gibt wichtige Programmiertips — besonders wertvoll deshalb, weil Atari ja nach wie vor in Sachen Entwicklerrichtlinien nicht gerade mitteilsam ist... Zur Sache: Wer schon einmal versucht hat, den »Volume Name« (Diskettenname) einer Diskette oder einer Hard-Disk zu ändern, ist vermutlich auf erhebliche Schwierigkeiten gestoßen. Der im Kästchen abgedruckte Algorithmus (in »informativer Schreibweise«) zeigt die »offizielle« Atari-Methode.

Ein anderes bisher schlecht dokumentiertes Gebiet ist die Gattung der Resetresidenten Programme. Den meisten Programmierern dürfte es mittlerweile bekannt sein, daß man Speicherbereiche durch Herabsetzen von »__memtop« vor Resets schützt. Auch die Installation residenter Programme wurde bereits beschrieben, ist aber leider noch immer nicht offiziell dokumentiert. Zumindest für das »Abzweigen« von Speicherplatz unterhalb von »__memtop« gibt es jetzt eine offiziell abgesegnete Methode.

Bei der ersten Installation wird »__memtop« um die Speichergröße vermindert, die anschließend Reset-fest bleiben soll. Nach dem Ändern von »__memtop« ist ein Warmstart notwendig, um die Speicherverwaltung von GEMDOS nicht zu verwirren (dazu am besten über »__sysbase->os_start« (Offset 4 im Betriebssystemheader) springen).

Damit ein Programm beim folgenden Hochfahren des Systems feststellen kann, ob es sich bereits installiert hat, muß es im reservierten Speicher eine »Spur« hinterlassen. Hier setzt Pratts Vorschlag an: Als ersten Long-Wert legt man am Beginn des reservierten Bereichs einen Pointer auf den Anfang eben dieses Bereichs ab, also einen Pointer auf sich selbst. Direkt (also 4 Byte) dahinter kommt eine »Magic Number«, die sich von Programm zu Programm unterscheiden soll, genau wie beim XBRA-Verfahren. Beim erneuten Programmstart durchsucht man dann den Programm-Speicher ab »__membot« aufwärts bis zum Ende des Speichers nach der eben beschriebenen Fährte. Das Speicherende erkennt man nach Pratt am besten durch das Auftreten eines Bus-Fehlers beim Lesezugriff. Er denkt offenbar schon an den TT, bei dem der Speicher nicht zwingend bei 4 MByte Schluß ist. Dazu legt man also temporär einen eigenen Bus-Fehler-Handler (Adresse 8) an. Auch wenn das vorgeschlagene Verfahren nicht unbedingt durch Eleganz und Effizienz glänzt, haben wir jetzt zumindest eine von Atari unterstützte Methode.

Fragen bleiben offen: Beispielsweise nach der Dokumentation von RAM-residenten Programmen, der neuen Systemvariablen des Blitter-TOS, der Unterstützung des XBRA-und XARG-Verfahrens sowie des Scrap-Directory, verbindlichen Programmier-Richtlinien oder auch ab wann GDOS allen STs beiliegt?

Einige dieser Fragen stellten wir dem zuständigen Mitarbeiter des Software-Supports in Raunheim, Harald Müller.

ST-Magazin: Herr Müller, seit Sommer haben Sie den bisherigen Aufgabenbereich von Alfred Scherff übernommen und sind seitdem für die Systemsoftware beim ST zuständig — was haben Sie vorher beruflich gemacht?

Harald Müller: Zwei Wochen vor meinem Eintritt bei Atari (1. Juni 1988) hatte ich mein Studium der Elektrotechnik an der TH Darmstadt (Fachbereich Datentechnik, Schwerpunkte VLSI und Informatik; Studienarbeit: Bau eines Hardwarewörterbuchs zur redundanzfreien Speicherung von Texten; Diplomarbeit: Simulation eines Wortzellennetzes auf der Basis von Silben, assoziative Speicher) nach 13 Semestern erfolgreich beendet.

ST-Magazin: Im letzten Jahr hat Atari mit »MadMac«, »aln« und jetzt dem Debugger »DB« das Atari-Entwicklungspaket modernisiert. Ist es geplant, diese neuen Programme auch einer breiteren Anwenderschicht zugänglich zu machen?

Harald Müller: Es ist geplant den MadMac, aln, DB und eine Shell als Assembler-Entwicklungspaket in den Vertrieb aufzunehmen.

ST-Magazin: Was kostet das Entwicklungspaket heute und was bekommt man dafür?

Harald Müller: Das »C«-Entwicklungssystem wird in der Bundesrepublik nicht mehr vertrieben.

ST-Magazin: Seit Sommer hat Atari Lizenzrechte für den völlig neu programmierten GDOS-Ersatz »AMC-GDOS«. Wie erhält man das Programm als Privatmann? Welche Gebühren werden bei einer kommerziellen Nutzung fällig?

Harald Müller: AMC-GDOS läßt sich aus der Atari-Mailbox (Anmerkung der Redaktion: Telefonnummer: 06142/211…) entnehmen oder gegen Einsendung einer Diskette bei Ataris Software-Support beziehen.

ST-Magazin: Die Entwicklung des neuen TOS (Version 1.4) ist ja noch nicht vollständig abgeschlossen (Anmerkung der Redaktion: Stand Anfang November 1988). Für wann darf man eine endgültige Version auf ROMs erwarten? Wird es diesmal wieder eine Diskettenversion geben, um den Umstieg auf die neue TOS-Version zu beschleunigen?

Harald Müller: Die Master-ROMs sollen Anfang November 1988 eintreffen und dann zur Produktion freigegeben werden, so daß mit einer Auslieferung Ende November oder Anfang Dezember zu rechnen ist.

ST-Magazin: Atari hat sich für das Austesten der neuen TOS-Version viel Zeit genommen und wurde dabei von Beta-Testern in vielen Ländern unterstützt. Ist Atari mit den Resultaten dieser Arbeitsweise zufrieden und wird man in Zukunft häufiger so Vorgehen?

Harald Müller: Das neu eingeführte Product-Tracking-System in Verbindung mit einer Datenbank in Sunnyvale ist als feste Einrichtung vorgesehen und soll auch bei künftigen Neuentwicklungen im Hard- und Softwarebereich zum Einsatz kommen. Es hat beim Testen des TOS 1.4 schon zu einer sehr guten Kommunikation zwischen den Entwicklern in Sunnyvale und den Subsidiaries geführt und führt bei weiterer Verbesserung des Feedbacks (Status-Reports) meiner Meinung nach zu starker Verbesserung der Produkte.

ST-Magazin: Nach Aussage von Mr. Good war TOS 1.4 nicht die letzte TOS-Version für den Atari ST. Für den TT hat Atari die TOS-Variante »TOS 030« angekündigt. Wo liegen die Unterschiede bei dieser TOS-Version, und wird diese gegebenenfalls auch für den ST erhältlich sein, eventuell auf Diskette, falls der Platz im ROM nicht reicht?

Harald Müller: Nach Aussage von Herrn Mester (Anmerkung der Redaktion: verantwortlich für den TT bei Atari Deutschland) ist das TOS 030 weitgehend identisch mit TOS 1.4, vermutlich bereinigt von den Line-F-Traps. Näheres dazu kann ich jedoch vermutlich erst nach der COMDEX sagen.

ST-Magazin: Aus Amerika hört man, daß Digital Research in Kürze eine neue GEM-Version vorstellt, die echtes Multitasking erlaubt und als Benutzeroberfläche für OS/2 und Unix angeboten werden soll. Werden wir das neue GEM auf den TTs und vielleicht auf dem ST sehen?

Harald Müller: Über eine neue GEM-Version liegen mir derzeit keine Informationen vor.

ST-Magazin: Atari will sich in Zukunft mehr darum kümmern, daß in Deutschland »sauber« programmiert wird und dazu Programmierrichtlinien veröffentlichen. Können Sie uns schon jetzt etwas dazu sagen?

Harald Müller: Die Idee, Programmierrichtlinien zu entwerfen, nimmt konkretere Formen nach Gesprächen mit mehreren Entwicklern an. Im Moment bin ich dabei, Vorschläge zu sammeln und auch eigene Ideen zu formulieren, wie so etwas aussehen könnte. Die gesammelten Werke sollen dann einer kleinen Gruppe von Entwicklern zur Prüfung und Ausarbeitung vorgelegt werden, um sie anschließend zu veröffentlichen. Unter anderem würde ich vorschlagen, Skelette für bestimmte Routinen in der Atari-Mailbox zur Verfügung zu stellen, um einen Einstieg entsprechend der Regeln zu erleichtern.

ST-Magazin: Wird es eventuell — ähnlich wie bei Apple — eine Art »Gütesiegel« für ST-Software geben?

Harald Müller: Wenn die Programming-Rules veröffentlicht sind, könnte man über eine Prüfungskommission nachdenken, die ein derartiges Markenzeichen vergibt. (uh)

Ändern des Volume-Labels