Welche Sprache hätten’s denn gern? Landessprachen auf dem Falcon
Wo nun schon MultiTOS und das TOS 4.0 des Falcon multilingual sind, dürfte es einem Programmierer doch in den Fingern jucken, auch eigene Anwendungen multilingual zu gestalten. Dazu muß man jedoch erst einmal wissen, welche Sprache angesagt ist.
Vor dem Falcon und MultiTOS war das ja noch recht simpel: Man konnte die Information, welche Sprache das TOS verwendet, dem System-Header entnehmen [1]. Das mußte dann zwar noch lange nicht die Sprache sein, die dem Anwender am meisten entgegenkam (man denke an einen Engländer vor einem deutschen ST), aber mehr ließ sich halt nicht machen.
Der Anwender ist König
Jedenfalls kann ATARI dies insofern behaupten, als daß es auf dem Falcon oder in Verbindung mit MultiTOS endlich möglich ist, dem Desktop verschiedene Sprachen zu entlocken. Durch ein kleines Konfigurationsprogramm, das jedem Falcon beiliegt, oder auch durch das in [2] vorgestellte Utility kann das TOS so konfiguriert werden, daß es in einer von fünf fest eingebauten Sprachen (Englisch, Deutsch, Französisch, Spanisch, Italienisch) redet.
Je nach Systemkonfiguration gibt es drei verschiedene Methoden, um die Sprache in Erfahrung zu bringen, die das Desktop benutzt. Daher möchte ich an dieser Stelle eine kleine C-Routine vorstellen, die für jedes System den richtigen Ländercode zurückliefert, wie er in [1 ] und [3] definiert ist. Dabei wird zunächst der System-Header ausgewertet, zusätzlich aber finden weitere Überprüfungen statt, die auf einem Falcon oder unter MultiTOS notwendig sind. Beim Falcon kann man sich keinesfalls mehr auf den System-Header verlassen, denn der liefert keine sinnvolle Angabe, was den Ländercode angeht. Wie sollte er auch? Schließlich ist der Falcon von Haus aus multilingual.
Zwei neue Verfahren
Bereits in der letzten Ausgabe wurde auf den neuen Cookie _AKP hingewiesen, der länderspezifische Informationen enthält. So findet sich in den Bits 8 bis 15 der Ländercode, für den der Falcon konfiguriert wurde. Ist also der _AKP-cookie vorhanden, ist nicht die Angabe im System-Header, sondern der Inhalt des Cookies ausschlaggebend für die Sprache des Desktops. Unter MultiTOS (also ab AES 4.0) stellt der neue AES-Aufruf appl_getinfo die gewünschte Information bereit. Bisher sind vollständige Libraries für AES 4.0 noch nicht allen C-Compilern beigelegt, deshalb wurde in GET_LANG.C ein eigener Aufruf realisiert, der von einem kleinen Assembler-Modul AES.S unterstützt wird. Wer einen C-Compiler mit vollständiger MultiTOS-Bibliothek verwendet, kann auf die fertige Library zurückgreifen.
Für appl_getinfo gibt es mehrere Parameter, die in der MultiTOS-Entwicklerdokumentation nachzulesen sind und auf die vorerst nicht näher eingegangen werden soll. Wird in intin[0] eine 3 übergeben, enthält intout[1] jedenfalls den Ländercode, der die Sprache des AES beschreibt.
Da MultiTOS gestartet wird, nachdem der _AKP-cookie (wenn überhaupt) vom Betriebssysstem angelegt wurde, ist der Information, die dieser Aufruf zurückgibt, Vorrang vor allen bisher schon gefundenen Einstellungen einzuräumen. Es könnte schließlich sein, daß die Sprache des MultiTOS anhand der Environment-Variablen AE_LANG in der GEM.-CNF-Datei unterschiedlich von der Einstellung gewählt wurde, die der _AKP-cookie vorgibt.
Die Aufgabe der Routine get_lang ist es, die notwendigen Überprüfungen in der aufgeführten Reihenfolge durchzuführen und den „wahren“ Code für die Landessprache zu liefern. Diese Information kann man in eigenen Programmen dazu verwenden, seine Benutzerführung der Sprache des Desktops anzugleichen. Falls Resource-Dateien für verschiedene Sprachen vorhanden sind, kann je nach dem Ergebnis, das get_lang liefert, die geeignete Datei nachgeladen werden. Hier spielen externe RSC-Dateien einen ihrer großen Vorteile aus: dadurch, daß sie nachträglich geladen werden, befinden sich nur diejenigen Daten im Speicher, die für eine bestimmte Sprache tatsächlich benötigt werden. Integriert man alle Resourcen in der Programmdatei, wächst deren Umfang bei multilingualen Programmen natürlich deutlich an.
Nachtrag
Wie kurz vor Redaktionsschluß bekannt wurde, soll auch MultiTOS demnächst getrennte Resourcen für die unterschiedlichen Landessprachen aufweisen. Ferner ist geplant, das Desktop aus der GEM.SYS-Datei auszuklammern. Dies dürfte darauf hinauslaufen, daß das GEM-Desktop in Zukunft ein eigenständiges Programm darstellt, das jederzeit durch einen Desktop-Ersatz wie Gemini oder Ease ersetzt werden kann. Bisher verbraucht das Standard-Desktop auch bei Verwendung eines alternativen Desktops Speicher, der nach dem beabsichtigten Änderungen für Anwenderprogramme zur Verfügung stünde.
Was MiNT angeht, war bei Redaktionsschluß Version 1.04 aktuell. Neben einer Reihe kleinerer Änderungen ist es nun endlich möglich, den Speicherschutz zu inaktivieren, ohne dafür ein externes Programm (wie PROTOFF aus dem letzten Heft) zu Hilfe zu nehmen. Es genügt nun, MINT.PRG in MINTNP.PRG umzubenennen. Mit Speicherschutz verträgt sich übrigens nur das MultiTOS-Desktop, nicht aber irgendeine andere der Desktop-Versionen im ROM.
Wie schon bei MiNT 0.99, sind auch die Quelltexte zu MiNT 1.04 frei verfügbar. Somit sind weiterhin interessante Einblicke in die internen Abläufe von MiNT möglich. Die Quellen zu MiNT befinden sich in vielen Boxen des Mausnetzes sowie auf einer Reihe von ftp-Servern, u.a. ftp.uni-muenster.de und ftp.uni-kl.de. Für die Compilierung mit Pure C 1.1 sollte man sich zusätzlich das Archiv MNT104PC.ZOO besorgen.
Literatur:
[1} Jankowski, Rabich, Reschke, „ATARI Profibuch ST-STE-TT“, Sybex-Verlag
[2] „Falcon neu konfiguriert“, ST-Computer 2/93
[3] Rainbow TOS Release Notes, ATARI Corp.
/*******************************/
/* get_lang */
/* Ermitteln der Systemsprache */
/* (c)1993 by MAXON-Computer */
/* Autor: Uwe Seimet */
/*******************************/
#include <stdio.h>
#include <tos.h>
#include <aes.h>
#define AKP 0x5f414d501
char *code to lang[] =
{ "USA", "FRG", "FRA", "UK",
"SPA", "ITA", "SWE", "SWF",
"SWG", "TUR", "FIN", "NOR",
"DEN", "SAU", "HOL" };
int get_lang(void);
int appl_getinfo(int ap_gtype, int *ap_gout1, int *ap_gout2, int *ap_gout3, int *ap_gout4);
extern int aes(void *aespb[]);
main()
{
int language;
char msg[40];
if (appl_init() < 0) return(-1);
language = get_lang();
sprintf(msg, "[0][Systemsprache: %s ][ OK ]", code_to_lang[language]);
form_alert(1, msg);
appl_exit();
return(0);
}
int get_lang()
{
long old_stack = 0;
long *cookie_jar;
int lang;
int dummy;
SYSHDR *syshdr;
if (!Super((void *)11)) old_stack = Super(0l);
/* Zunächst Systemheader auswerten */
syshdr = *(SYSHDR **)0x4f2;
syshdr = syshdr->os_base;
lang = syshdr->os_palmode>>1;
/* Als nächstes AKP-cookie überprüfen */
cookie_jar = *(long **)0x5a0;
while (cookie_jar[0]) {
if (cookie_jar[0] == AKP) {
lang = (int)(cookie_jar[1]>>8);
break;
}
else cookie_jar = &(cookie_jar[2]);
}
if (old_stack) Super((void *)old_stack);
/* Zum Schluß noch der Test auf AES 4.0 */
if (_GemParBlk.global[0] >= 0x0400)
appl_getinfo(3, &lang, &dummy, &dummy, &dummy);
return(lang);
}
/* Vorläufige Implementation von appl_getinfo */
int appl_getinfo(ap_gtype, ap_gout1, ap_gout2, ap_gout3, ap_gout4)
int ap_gtype;
int *ap_gout1;
int *ap_gout2;
int *ap_gout3;
int *ap_gout4;
{
void *aeapb[6];
aespb[0] = _GemParBlk.contrl;
aespb[1] = _GemParBlk.global;
aespb[2] = _GemParBlk.intin;
aespb[3] = _GemParBlk.intout;
aespb[4] = _GemParBlk.addrin;
aeapb[5] = _GemParBlk.addrout;
_GemParBlk.contrl[0] = 130;
_GemParBlk.contrl[1] = 1;
_GemParBlk.contrl[2] = 5;
_GemParBlk.contrl[3] = 0;
_GemParBlk.contrl[4] = 0;
_GemParBlk.intin[0] = ap_gtype;
aes(aespb);
*ap_gout1 = _GemParBlk.intout[1];
*ap_gout2 = _GemParBlk.intout[2];
*ap_gout3 = _GemParBlk.intout[3];
*ap_gout4 = _GemParBlk.intout[4];
return(_GemParBlk.intout[0]);
}
Uwe Seimet