DTCOOKIE Version 1.1 - 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 ver„ndert. Sinnvollerweise startet man DTCOOKIE.PRG aus dem AUTO-Ordner, vor den Programmen, die diese Cookies auswerten. 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 m”glich, dem nichtflchtigen Speicher (NVM), und sonst der L„nderkennung im System-Header. Der "_AKP"-Cookie im Detail: ---------------------------- Bit 0..7: L„ndercode fr Tastaturlayout Bit 8..15: L„ndercode 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 enth„lt einen Zeiger auf eine word-grože Variable mit dem aktuellen Datum im Tgetdate()-Format. Der "TIME"-Cookie enth„lt einen Zeiger auf eine word-grože 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 m”glich 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 grunds„tzlich 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 ben”tigt wird (etwa von einer Bildschirmuhr oder einem Programm, das im Hintergrund zeitabh„ngig Mežwerte aufzeichnet oder irgend- welche Prozesse oder Ger„te 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 k”nnte 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 k”nnte. Aužerdem ist auch das XBIOS nur bedingt re-entrant (der Rekursionsstapel ist zu klein und der Dispatcher sperrt w„hrend des Rettens der Register nicht die Interrupts) und darf unter MiNT ebenfalls nicht im Interrupt aufgerufen werden. Im Multitasking-Zeitalter sollte man sich zun„chst einmal berlegen, ob ein solches residentes Programm (TSR) nicht besser durch eine ganz "normale" im Hintergrund laufende Applikation ersetzt werden kann. Man kann dann v”llig 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 M”glichkeiten: 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 h„ngen und dort die Uhrzeit gelegent- lich korrigieren (z.B. bei jedem Pexec()- oder Pterm()- oder Pterm0()-Aufruf mit einem zus„tzlichen Tgettime()-Aufruf). Wie gesagt, ist die Methode, mit der DTCOOKIES die GEMDOS-internen Variablen findet und die Benutzung dieser Variablen durch andere Programme (aužer unter KAOS und MagiX) nicht "offiziell erlaubt" und daher als "unsauber" zu bezeichnen, obwohl sie in allen bekannten F„llen funktioniert und elegant, schnell und einfach ist. Da in Deutschland "Sauberkeit" grožgeschrieben wird, seien hier noch zwei M”glichkeiten genannt, wie man die Cookies auch "sauber" setzen k”nnte. Allerdings sind diese L”sungen weder elegant, noch schnell, noch einfach. Welche L”sung man bevorzugt, h„ngt wohl haupts„chlich davon ab, ob man mehr pragmatisch oder mehr dogmatisch denkt. 1. Ein residentes Programm legt zwei Variablen fr Datum und Uhrzeit an, l„žt 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 m”chte, legt die Cookies "DATE" und "TIME" an und l„žt 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 zus„tzliches Accessory-Programm aktualisiert die Variablen dann regelm„žig (etwa einmal pro Sekunde) in einer evnt_timer()- Schleife mit Tgetdate() und Tgettime(). Schliežlich besteht theoretisch noch die M”glichkeit, daž die Variablen unter GEMDOS oder MiNT einmal offiziell zug„nglich gemacht werden, aber diese L”sung w„re ja viel zu einfach. Wahrscheinlich wird sich das ganze Problem in Zukunft aber auch von selbst l”sen - 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 18.1.1994