DTCOOKIE Version 1.3 - Date/Time-Cookies setzen
===============================================

Sinn und Zweck von DTCOOKIE
---------------------------
Das Programm DTCOOKIE.PRG dient lediglich dazu, die Cookies
"DATE", "TIME", "_IDT" und "_AKP" auf sinnvolle Werte zu setzen.
Falls einer dieser Cookies bereits gesetzt ist, wird er von
DTCOOKIE nicht verndert. Sinnvollerweise startet man DTCOOKIE.PRG
aus dem AUTO-Ordner, vor den Programmen, die diese Cookies
auswerten. Die genannte Cookies werden z.B. vom Programm LEDPANEL 
ausgewertet, aber von diesem ebenfalls gesetzt, so da DTCOOKIE
zum Betrieb von LEDPANEL nicht notwendig ist. Fr andere Programme
oder eigene Entwicklungen mag DTCOOKIE aber interessant sein.
Im folgenden noch einige Informationen zu den genannten Cookies:

Die Cookies "_AKP" und "_IDT"
-----------------------------
Dies sind mehr oder weniger offizielle Cookies von Atari. Sie
enthalten Informationen ber nationale Besonderheiten, die von
Anwenderprogrammen und vom Desktop bercksichtigt werden sollten.
Die Cookies werden unter anderem vom MultiTOS-Desktop ausgewertet,
allerdings von lteren TOS-Versionen nicht gesetzt. Falls Multi-
TOS unter einer lteren TOS-Version gestartet wird, sollte man
diese Cookies z.B. mit DTCOOKIE selber setzen. Die Werte fr die
Cookies entnimmt DTCOOKIE, wenn mglich, dem nichtflchtigen
Speicher (NVM), und sonst der Lnderkennung im System-Header.

Der "_AKP"-Cookie im Detail:
----------------------------
Bit 0..7:   Lndercode fr Tastaturlayout
Bit 8..15:  Lndercode fr Landessprache
Bit 16..31: reserviert

Der "_IDT"-Cookie im Detail:
----------------------------
Bit 0..7:   Trennzeichen fr Datumsangaben
            (Null steht als Default fr '/').
Bit 8..11:  Datumsformat,
            (0: MM-TT-JJ, 1: TT-MM-JJ,
             2: JJ-MM-TT, 3: JJ-TT-MM.)
Bit 12..15: Zeitformat
            (0: am/pm, 1: 24 Stunden)
Bit 16..31: reserviert

Die Cookies "DATE" und "TIME"
-----------------------------
Dies sind infoffizielle Cookies, welche das Abfragen von Datum
und Uhrzeit aus dem Interrupt erleichtern sollen:

Der "DATE"-Cookie enthlt einen Zeiger auf eine word-groe
Variable mit dem aktuellen Datum im Tgetdate()-Format.
Der "TIME"-Cookie enthlt einen Zeiger auf eine word-groe
Variable mit der aktuellen Uhrzeit im Tgettime()-Format.

DTCOOKIE besetzt die Cookies mit Zeigern auf die GEMDOS-internen
Variablen fr Datum und Uhrzeit. Es ermittelt die Adressen dieser
Variablen ber die GEMDOS-Funktion Sconfig() (die bisher nur von
"KAOS" und "MagiX" angeboten wird) und wenn dies nicht mglich
ist, durch Tracing von Tgetdate()/Tgettime()-Aufrufen. Diese
Methode ist zwar nicht ganz "sauber", funktioniert aber unter
allen TOS-Versionen und auch mit MiNT (MiNT hat brigens seine
eigenen internen Variablen. Wird DTCOOKIE vor MiNT gestartet,
zeigen die Cookies auf die GEMDOS-internen Variablen, wird
DTCOOKIE nach MiNT gestartet, zeigen sie auf die MiNT-internen
Variablen).

Tips zur Abfrage von Datum und Uhrzeit aus dem Interrupt
--------------------------------------------------------
Die aktuelle Uhrzeit und das aktuelle Datum sollten eigentlich
grundstzlich mit den GEMDOS-Funktionen Tgetdate() und Tgettime()
ermittelt werden. Diese Routinen benutzen zur Bestimmung der Zeit
die Systemtimer-Routine etv_timer(), die Zeit wird dabei beim
Start von GEMDOS und bei jeder Beendigung eines GEMDOS-Prozesses
mit Hilfe der Hardware-Uhr aktualisiert, was einen Kompromi aus
Geschwindigkeit und Genauigkeit darstellt. Das Problem stellt sich
dann, wenn die Zeit von einem residenten Programm im Interrupt
bentigt wird (etwa von einer Bildschirmuhr oder einem Programm,
das im Hintergrund zeitabhngig Mewerte aufzeichnet oder irgend-
welche Prozesse oder Gerte steuert). Weil das Standard-GEMDOS
nicht re-entrant ist, drfen Tgetdate() und Tgettime() hier nicht
aufgerufen werden. Unter MiNT ist zwar das GEMDOS re-entrant, darf
aber trotzdem nicht aus einem Interrupt aufgerufen werden. Man
knnte statt der GEMDOS-Funktionen Tgetdate() und Tgettime() zwar
die XBIOS-Funktion Gettime() aufrufen, aber auch dies ist nicht zu
empfehlen, denn Gettime() liest die Hardware-Uhr, was eventuell
einige Zeit in Anspruch nehmen knnte. Auerdem ist auch das XBIOS
nur bedingt re-entrant (der Rekursionsstapel ist zu klein und der
Dispatcher sperrt whrend des Rettens der Register nicht die
Interrupts) und darf unter MiNT ebenfalls nicht im Interrupt
aufgerufen werden.

Im Multitasking-Zeitalter sollte man sich zunchst einmal berlegen,
ob ein solches residentes Programm (TSR) nicht besser durch eine ganz
"normale" im Hintergrund laufende Applikation ersetzt werden kann.
Man kann dann vllig problemlos Tgettime() und Tgetdate() aufrufen.

Ist wirklich ein TSR erforderlich, wird vorgeschlagen, da es das
aktuelle Datum und die Uhrzeit wie folgt ermittelt:

1. Es testet, ob der Cookie "MagX" gesetzt ist. In diesem Fall ist
"MagiX" installiert, und es kann Tgettime() und Tgetdate() auch im
Interrupt aufrufen. Die Routinen sind unter MagiX ausreichend
schnell und re-entrant.

2. Es testet, ob die Cookies "DATE" und "TIME" gesetzt sind. In
diesem Fall kann es Datum und Uhrzeit ber die Variablen
bestimmen, deren Zeiger in den Cookies stehen (Zugriff auf die
Variablen nur im Supervisor-Modus und nur lesend).

3. Ansonsten bleiben dem TSR im wesentlichen die folgenden zwei
Mglichkeiten: Erstens, zu versuchen, die Adressen der GEMDOS-
Variablen fr Datum und Uhrzeit selbst zu ermitteln, und dann
diese Variablen zu benutzen (eine "unsaubere" Methode!) oder
zweitens, bei der Initialisierung des Programms mit Tgetdate() und
Tgettime() Datum und Uhrzeit zu bestimmen sowie die Systemvariable
_hz_200 ($4ba) auszulesen und im Interrupt dann Datum und Uhrzeit
aus der nderung von _hz_200 zu bestimmen. Wenn es Blockierungen
oder Ungenauigkeiten von _hz_200 Rechnung tragen will, sollte es
sich noch in den GEMDOS-Trap hngen und dort die Uhrzeit gelegent-
lich korrigieren (z.B. bei jedem Pexec()- oder Pterm()- oder
Pterm0()-Aufruf mit einem zustzlichen Tgettime()-Aufruf).

Wie gesagt, ist die Methode, mit der DTCOOKIES die GEMDOS-internen
Variablen findet und die Benutzung dieser Variablen durch andere
Programme (auer unter KAOS und MagiX) nicht "offiziell erlaubt"
und daher als "unsauber" zu bezeichnen, obwohl sie in allen
bekannten Fllen funktioniert und elegant, schnell und einfach
ist. Da in Deutschland "Sauberkeit" grogeschrieben wird, seien
hier noch zwei Mglichkeiten genannt, wie man die Cookies auch
"sauber" setzen knnte. Allerdings sind diese Lsungen weder
elegant, noch schnell, noch einfach. Welche Lsung man bevorzugt,
hngt wohl hauptschlich davon ab, ob man mehr pragmatisch oder
mehr dogmatisch denkt.

1. Ein residentes Programm legt zwei Variablen fr Datum und
Uhrzeit an, lt die Cookies "DATE" und "TIME" darauf zeigen,
klinkt sich in etv_timer() oder irgendeinen anderen Timer ein,
initialisiert die Variablen mit Tgetdate()/Tgettime() und
aktualisiert sie dann im Timer-Interrupt, hnlich, wie es das
GEMDOS in etv_timer() mit seinen Variablen auch macht.

2. Das TSR, das die Cookies benutzen mchte, legt die Cookies
"DATE" und "TIME" an und lt sie auf zwei Variablen im TSR
zeigen (falls die Cookies bereits existieren, hat ein anderes
TSR dies bereits getan, in diesem Fall benutzt es einfach die
Zeiger in den Cookies). Das TSR initialisiert die Variablen
danach mit den GEMDOS-Funktionen Tgetdate() und Tgettime().
Ein zustzliches Accessory-Programm aktualisiert die Variablen
dann regelmig (etwa einmal pro Sekunde) in einer evnt_timer()-
Schleife mit Tgetdate() und Tgettime().

Schlielich besteht theoretisch noch die Mglichkeit, da die
Variablen unter GEMDOS oder MiNT einmal offiziell zugnglich
gemacht werden, aber diese Lsung wre ja viel zu einfach.

Wahrscheinlich wird sich das ganze Problem in Zukunft aber auch
von selbst lsen - entweder weil Atari schnellere Rechner mit
Multitasking-Betriebssystem ausliefert oder weil Atari pleite
geht. Beides wrde die Notwendigkeit von TSR-Programmen auf dem
Atari erheblich vermindern.

Zum Schlu
----------
DTCOOKIE ist ein Freeware-Programm von Christoph Zwerschke. Die
Benutzung geschieht auf eigene Gefahr. Alle Aussagen in obigem
Text ohne Gewehr und Pistole.

                                         Heidelberg, den 26.1.1994
