
TAB-Weite=4

Dieser Text	richtet	sich  an  alle GEM-Programmierer. Aufgrund meiner lang-
jhrigen Beta-Tester-Erfahrung mu ich feststellen,	da	leider immer wieder
die	 gleichen  Fehler  und	 Unschnheiten	 gemacht   werden,	selbst	von
gestandenen und bekannten, kommerziellen Programmierern.


1. Umgang mit dem minixfs (z.T. auch gltig fr VFAT.XFS und RD_FS.XFS)
Viele Programmierer	unterlassen	es leider,	ihre Software auf einem	minixfs
zu testen. So knnen  sich	allerhand Fehlerchen einschleichen.	Zu beachten
ist, da  Dateinamen  auf  einem  minixfs  grundstzlich  klein	geschrieben
werden.	Grobuchstaben bzw.	 Gemischt-Schreibweise	sind  eher die Ausnahme
und dann auch konkret dokumentiert.

1.1 rsrc_load().
Viele Programme	 scheitern	schon  beim	 Laden	der	 Resourcedatei,	weil im
Quelltext bspw.	 rsrc_load("LZHSHELL.RSC")	steht,	dies  jedoch  nirgendwo
dokumentiert ist. Der genervte	Anwender  mu dann erst	einmal lzhshell.rsc
in	LZHSHELL.RSC  umbenennen.	Gleiches   gilt	  fr  ST-GUIDE-Hypertexte,
Klemmbrett-Dateien u..	Also: bitte	Dateinamen	klein schreiben, wenn nicht
ganz bewut	andere Schreibweisen erforderlich  erscheinen! MiNT	bzw. GEMDOS
wandeln	 klein	geschriebenen	Dateien,   die	 von/auf  GEMDOS-Partitions
gelesen/geschrieben werden, automatisch in Grobuchstaben um.

1.2 scrap directory
Auch ein rgernis ist, da das clipboard  file mal mit Namen scrap.txt, mal 
mit  Namen  SCRAP.TXT   angelegt   wird.   Dies   sind  auf  einem  minixfs 
unterschiedliche Dateien!  Bitte,  liebe  Programmierer,  gewhnt  Euch an, 
Dateinamen KLEIN zu schreiben!
Nachtrag:  laut  Julian  F.  Reschke   sollte  SCRAP.*  in  GROSSBUCHSTABEN 
geschrieben werden, um Kompatibiltt zu lteren Programm zu wahren!

1.3 Fsfirst()/Fsfirst()
Von	der	Benutzung dieser Funktionen	sei	dringend abgeraten.	Selbst in einem
Programm, das in der MiNT-Domain luft,	liefern	diese Funktionen Dateinamen
immer, d.h.	auch von  einem	 minixfs,  in  Grobuchstaben  und ggf.	auf	8+3
Zeichen	 verstmmelt.  Die	Vorgehensweise	der	  Wahl	ist	 die  folgende:
Dopendir()	 aufrufen;	  liefert	 die	Funktion	EINVF	 (ungltige
Funktionsnummer), so  sind	Fsfirst()/Fsnext()	zu	benutzen, ansonsten	mit
D(x)readir usw. fortfahren.

Selbst die Existenz einer Datei berprfe man bitte nicht mittels z.B.
if (Fsfirst("C:\\st-guide.inf", 0x0) == E_OK)
sondern:
if (access("/boot/st-guide.inf",f_OK) == 0)
die Ausfhrbarkeit mittels z.B.
if (access("/bin/sh",x_OK) == 0)
Erst wenn access() bzw. die dabei benutzten MiNT-Funktionen nicht vorhanden
sind, benutze man Fsfirst(). Eine gute library macht dies automatisch.

1.4 rwx--x--x
Achtung:  auf  einem  minixfs	mu	  ein	(ausfhrbares)	Programm  nicht
zwangslufig eine Extension	(ttp, app,	usw.)  besitzen. Es	reicht auch	ein
gesetztes x-flag. Dagegen ist aber auch	zu beachten, da sog. Shell	Scripts
(Batch Dateien fr UNIX	Shells)	u.U. ein gesetztes x-flag aufweisen	knnen,
aber selbstredend kein GEMDOS-Binrformat aufweisen.

1.5 access denied
Auch wenn eine Datei auf  einem	 minixfs  zweifelsfrei vorhanden ist, heit
dies noch lange	nicht, da	man	 darauf	 zugreifen darf. Rechnen Sie damit,
da	die	Datei einem	anderen	Benutzer (minixfs ist ein multiuser	filesystem)
gehrt und Ihr Programm keine entsprechenden Zugriffsrechte besitzt.


2. G_USERDEF-Objekte und Umgang mit proportionalen AES-Fonts
Zur	Zeit (19.04.1997) ist N.AES	 1.1.0	dank  "cellmodel" noch am besten in
der	Lage, proportionale	AES-Fonts zu verwenden.	 Nach dem Motto	"Das knnen
wir	auch" haben	GEM-Programmierer  MacOS  und Windows schon	lange bewiesen,
da	es unter GEM auch Farbicons, runde Radiobuttons, Buttons zum Ankreuzen,
Popup-Mens	usw. geben kann. Nur bei der Untersttzung proportionaler Fonts
hapert	es	 meistenteils.	 Zu	  unrecht.	 GEM-Programmierer,	 die  keine
G_USERDEF-Objekte im  Sinne	 von  Flydial-Clones  verwenden,  brauchen sich
keine Gedanken machen. Alles was zur  Zeit noch	nicht perfekt aussieht,	ist
den	 AES  anzulasten  *).	GEM-Programmierer,	 die  in  ihren	 Programmen
G_USERDEF-Objekte verwenden, sollten folgendes beachten:

2.1 prop. AES-Font
Machen Sie keine Annahmen ber den	Font,  den AES verwendet. Unter	AES	4.x
erfhrt	man	die	AES-Fontdaten  mit	Hilfe  der AES-Funktion	appl_getinfo().
Fr	AES	< 4.x gibt es  von Julian F. Reschke vorgeschlagene	Vorgehensweisen
zur Emulation von appl_getinfo().
Ab AES 4.1 kann man im TEDINFO  auch prop. Fonts eintragen (Felder te_font, 
te_fontid, te_fontsize). Leider ist  dies  nicht  abwrtskompatibel, da AES 
1.x/3.x mit te_font == GDOSPROP  (==  0) nichts anzufangen wei. Daher also 
z.B. eine eigene get_tree_ptr()-Routine schreiben, bei  der unter AES < 4.1 
GDOSPROP wieder auf IBM gesetzt wird.

2.2 shortcut buttons
Verndern Sie weder	 Breite	 noch  Hhe	 der  Box,	sondern	geben Sie Ihren
shortcut button	text  einfach  nur	zentriert  innerhalb  der  Box aus.	Zur
Berechnung	 der   Zentrierung	 verwenden	  Sie	bitte	unbedingt	die
VDI-Auskunftsfunktion vqt_extent()!	vqt_extent() berechnet	die	Lnge eines
Strings	auch bei Verwendung	eines  prop.  Font korrekt.	Wenn die Boxausmae
von	AES	zu breit berechnet werden (wie z.B.	 bei ATARI AES 4.x), so	ist	AES
daran schuld, nicht Sie!
Zum Unterstreichen des eigentlichen  shortcut-Buchstabens benutze man nicht 
etwa v_pline(), um einen  Strich  mit  der  Lnge graf_char_width zu malen. 
Dieser Strich wird bspw. fr ein  proportionales "i" viiiel zu lang. Besser 
ist es, die  Position  des  bestreffenden  Buchstabens  mit vqt_extent() zu 
berechnen und ihn  noch  einmal  mit  "Texteffekt unterstrichen" auszugeben 

2.3 group boxes
Auch bei group boxes sollte	 der  Bereich  des Rahmens,	der	gelscht werden
soll, bevor	dort  der  "berschriftstext"  ausgegeben  wird,  mit Hilfe	von
vqt_extent() berechnet werden.

2.4 rounded radio buttons
Prop. AES-Fonts	bedeutet  i.d.R.  auch,	 da  die  Zeichenhhe auf kleinere
Werte als blich gesetzt werden	knnen.	 Radiobutton images, die i.d.R.	fr
den	8 x	16	Pixel  groen  Systemzeichensatz  entworfen	 wurden, sehen dann
etwas zu gro aus.	Leider	bleibt	einem  nichts  anderes brig, in seiner
Resourcedatei einen	bestimmten	Vorrat	an	radio  button  images bereit zu
halten, z.B.:
b/w normal           12 images von 7 bis 18 Pixel Hhe
b/w seleceted        12 images von 7 bis 18 Pixel Hhe
b/w normal            1 image fr ST-mittel
b/w selected          1 image fr ST-mittel
3D coloured normal    8 images von 9 bis 16 Pixel Hhe
3D coloured selected  8 images von 9 bis 16 Pixel Hhe
                    ---                    
                     42 images (!)

Insbesondere darf man von einer	aktuellen  Hhe	des	AES-Zeichensatzes von 9
points nicht etwa auf die mittlere	ST-Auflsung schlieen!	Als	Abfrage	der
mittleren ST-Auflsung hat	sich  unter	 Verwendung	 der  Rckgabewerte	von
graf_handle() die Formel

ST_medium = (graf_boxwidth >= 2 * graf_boxheight)

bewhrt.

2.5 cross buttons
Ankreuzbare Buttons sollte man  nicht  als  G_IMAGE darstellen (Probleme s.
2.4), sondern mit v_pline()  o.  .  zeichnen.  Die Kantenlnge ergibt sich
aus der Hhe pb_h des von AES gelieferten Parameterblocks.

2.6 3D-Grau (ab AES 3.3x)
Man	sollte keineswegs  davon  ausgehen,	 da  ein  3D-Dialog  immer	in grau
dargestellt	wird. Vielmehr sollte man die diversen Fllfarben mit Hilfe	von
objc_sysvar() ermitteln. Zu	beachten ist  auch,	 da die 3D-Farben z.B.	mit
Hilfe des 3DBUTTON.CPX zur Laufzeit gendert werden knnen.
Fr	den	Fall, da man z.B. ein	b/w	normal rounded radio button	image unter
Bercksichtigung der  Hintergrundfarbe	darstellen	will,  eignet sich z.B.
folgender Aufruf:

if (draw_3D(PB))            /* 3D object flag && objc_sysvar() available */
  vrt_cpyfm(handle,MD_REPLACE,&pxy,&src,&dst,BLACK,AES_backgr_color);
else                        /* no 3D effect */
  vrt_cpyfm(handle,MD_REPLACE,&pxy,&src,&dst,BLACK,WHITE);

...

Abgesehen davon,  da  ich	noch  berhaupt	 keine	3D-rounded radio button
images besitze,	halte ich mich in  meinen  Programmen an die Punkte	2.1	bis
2.6. Es	ist	wirklich nicht schwer - der	Aufwand	hlt sich in Grenzen und es
sieht recht hbsch aus.

*) bei der aktuellen  Version  von	N.AES  (Stand  19.04.1997) mu man z.B.
folgendes beachten:
editierbare	Textobjekte	kann  man  ja  aus	Maske  und Eingabebereich ("__"
zusammensetzen,	z.B.:  "Datum:	__.__.__".	Gibt  man  als	Ausrichtung	des
Objekts	zentriert an, rutscht die Zeichenkette "Datum:"	whrend	der	Eingabe
hin	und	her, weil sich die Lnge des Gesamttextes in Pixeln	mit	jedem neuen
Zeichen	ndert.	Gibt man als  Zentrierung  linksbndig	an,	bekommt	man	bei
bereinanderliegenden Texten  die  Doppelpunkte	 nicht	in eine	Pixelspalte
(bei zentriert sowieso nicht), wie z.B.:
  Datum: __.__.__
Uhrzeit: __:__ Uhr
Irgendwie fehlt	einem hier ein Tabulator. Als work around hilft	leider nur,
den	Text mit dem Doppelpunkt vom  Rest	zu	trennen, in	ein	neues Objekt zu
verfrachten, den Text mit dem Doppelpunkt rechtsbndig auszurichten	und	den
rechtsseitigen Eingabebereich linksbndig auszurichten, also:
  Datum: __.__.__
Objekt 1 Objekt 2
rechtsb. linksbndig

Uhrzeit: __:__ Uhr
Objekt 3 Objekt 4
rechtsb. linksbndig


4. Diverse Kleinigkeiten

4.1	 Ich  wrde	  es   begren,   wenn	  auch	 GEM-Programme	Fehlercodes
zurcklieferten	und	exit(EXIT_SUCCESS/EXIT_FAILURE)	benutzen  wrden. DRI -
Demo-Quelltexte	wie	 z.B.  doodle.c	(GEM-Programmierhandbuch, Sybex-Verlag)
machen es vor. Findet ein Programm seine Resourcedatei nicht, ist dies kein
Grund so zu tun als sei alles in Ordnung und einfach Pterm0() aufzurufen.

4.2	Der	erste  Mentitel  von  links  sollte  nicht	 einfach "Desk"	lauten,
sondern	 den   Programmnamen   in	Grobuchstaben	 oder	einen  anderen,
aussagekrftigen String enthalten.

4.3	Unter einem	multi-AES (AES	4.x)  sollte ein Programm mglichst	auf	ein
eigenes	WF_NEWDESK-Fenster verzichten.	Eine  Ausnahme stellt natrlich	ein
"Desktop-Programm" wie z.B. MagiCDesk oder Thing dar.

4.4	Viele Programmierer	klammern offenbar  auch	objc_draw()	/ objc_change()
- Aufrufe vllig unntigerweise	mit	graf_mouse(M_ON/M_OFF,NULL)	- Aufrufen,
was bei sog. progress boxes o.. zu einem hlichen Mausflackern fhrt.

4.5	Eine weitere  Methode,	hliches  Mausflackern	 zu	vermeiden, ist,	das
Mausrechteck	(zuzglich	  eines		gewissen	"Sicherheitsabstandes":
Rechteckbreite = 64,  Rechteckhhe	=  32)	mit	 dem  redraw rectangle oder
gleich dem betreffenden	Fenster-Arbeitsbereich	zu	schneiden  und dann	die
Maus nur bedingt ein-  und	auszuschalten.	Das	 Lines-Demo	 von ATARI,	das
TOSWIN-Derivat von Christian Felsch und CAB von ASH machen es vor.

4.6	Fenstertitel sollten grundstzlich durch  je ein Leerzeichen geklammert
werden.

4.7 In vielen GEM-Programmen (nicht  nur  POVShell  und KandinskY) hat sich 
die  Unsitte  eingebrgert,  Grow-/Shrinkeffekte  sowie  3D-Darstellung  zu 
konfigurieren. So mu man also -  berspitzt formuliert - in jedem Programm 
erst mal hingehen und  die  ollen  3D-Effkte  unter single AES ausschalten. 
Wesentlich angenehmer und sinnvoller ist es, solche Sachen mit 3DBUTTON.CPX 
(->3D-Darstellung) oder  in  der  MagiC-Konfiguration  (-> Boxeffekte) bzw. 
N.AES-Konfiguration (->  slowfx)  _global_  einzustellen. G_USERDEF-Objekte 
sollten also nur dann 3D-Effekte  darstellen,  wenn  AES dies auch kann (ab 
Version  3.3)  und  dann  auch  nicht  vergessen,  objc_sysvar()  nach  den 
3D-Farben zu fragen, vgl. 2.6
Auf gar keinen Fall sollte  ein  Programm  grundstzlich auf die Boxeffekte 
(form_dial(), graf_xxxxbox()) verzichten.  Diese  gehren  zu GEM UNBEDINGT 
dazu! Und man kann  sie  unter  MagiC  und  N.AES  ja  auch global ein- und 
ausschalten.  Boxeffekte  nach   WM_MOVED-   und   WM_SIZED-Meldungen  sind 
allerdings  nicht  sinnvoll,  erst  recht   nicht  im  Zeitalter  von  sog. 
Echtzeitfensterfunktionen  (->  WINX,   MagiC,   N.AES),  da  bereits  eine 
"Animation" durch "Geisterrahmen"  stattfindet.  Zusammengefat  sollte man 
also Boxeffekte bei folgenden Dingen einbauen:
wind_open()
WM_CLOSED
WM_FULLED
ffnen einer Dialogbox (form_dial(FMD_GROW,...)
Schlieen einer Dialogbox (form_dial(FMD_SHRINK,...)
Bei letzteren beiden Funktionen, ggf.  auch  bei wind_open(), sollte - wenn 
sinnvoll - sich das eine  Rechteck  auf  die  Dialogbox, das andere auf die 
Ausmae des "aufrufenden" Mentitels beziehen.

4.8 evnt_event().
Wer das Buch von den Gebrdern  Gei  noch  nicht kennt, dem sei es hiermit 
mitgeteilt:  man  kann   sein   GEM-Programm   durch   die  Verwendung  von 
evnt_event() statt evnt_multi() etwas beschleunigen!

4.9 AP_TERM
Mir ist aufgefallen, da  einige  Programme  zwar  auf  AP_TERM hren, sich 
jedoch nicht  mit  shel_write(9,0x0001,0,0L,0L) beim AES-shutdown-Protokoll 
anmelden.


5. Umgang mit memory protection
Wird MiNT im AUTO-Ordner  als  MINT.PRG	 und  nicht	MINTNP.PRG gebootet, so
berwacht die MMU des 68030	die	 Adresszugriffe	eines Programms. Greift	ein
Programm auf eine unerlaubte (fremde) Adresse  zu,	so wird	es von MiNT	mit
dem	Hinweis	auf	eine memory	violation beendet. Es gibt i.A.	zwei Grnde	fr
eine memory violation:

a) das AV-Protokoll
Wird im	 Rahmen	 des  AV-Protokolls	 ein  Zeiger  auf einen	Speicherbereich
bermittelt	und	wurde dieser Speicherbereich vom Sender	nicht "global" oder
"readable",	sondern	"private" angefordert  (-> Malloc()/Mxalloc()),	so wird
der	 unschuldige  Empfnger	  beim	 ersten	  Zugriff	auf	 den  "private"
Speicherbereich von MiNT terminiert.

b) range overflow
In einem Programm luft	z.B.  irgendein	 Index	ber  und es wird auf einen
Speicherbereich	zugegriffen, der  auerhalb	 des  dem Programm zugeordneten
Speichers liegt. Da	dies u.U. auch	ohne memory	protection fr rger sorgen
knnte,	ist	jedem Programmierer	grundstzlich anzuraten, sein Programm auch
einmal mit memory protection zu testen.


6. Gestaltung der Benutzeroberflche

6.1 Grundstzliches
Es ist grundstzlich zu	begren, wenn	ein	Programmierer sein Programm	mit
rounded	radiobuttons, check	boxes, group  boxes	und	dergleichen	"aufpeppt".
All	diese Dinge	kamen mit dem Auftauchen  der sog. Flydials	in Mode. Leider
hat	der	Autor der Flydials meines Wissens  bis heute noch nicht	die	Sourcen
zu den Flydials	 zur  public  domain  gemacht,	soda  sich	 eine Reihe	von
Programmierern gentigt	sah,  diese	 einfach nachzuprogrammieren. Natrlich
wollte der Programmierer dann  sein	 Ego  befriedigen  und	das	Original in
seiner Originalitt	bertreffen. Dies  fhrte  zu einem	meiner Meinung nach
unseligen Wildwuchs	von	Flydial-Clones.	Mal	sind  die Kreuze in	einem cross
button etwas dicker, mal finden	 sich  blaue Hkchen statt eines Kreuzchens
in einem cross button, mal	sind  die Unterstriche von shortcut	buttons	rot
statt schwarz, mal sind	die	help  buttons  gelb	gefrbt, mal nicht,	und	die
ganz normalen OK-  und	Abbruch-Buttons	 haben	sowieso	 sehr  oft eine	von
Programm zu	Programm unterschiedliche  Hhe.  Die  Gebrder	Gei behaupten,
man	msse buttons etwas	grer machen, damit  man sie leichter mit der Maus
treffen	kann (oder hnliches). Da  sie	aber ihre rounded radio	buttons	und
cross buttons aber nicht vergrern	 und auch die Fensterbedienelemente	der
AES	nicht  vergrern  knnen,	ist	 dies  in  meinen  Augen  ein  ziemlich
inkonsequentes Argument: derjenige,	welcher	noch nicht einmal den OK-Button
auf Anhieb trifft, wird doch mit Fenstern erst Recht Schwierigkeiten haben.

Es ist eine  wissenschaftlich  erwiesene  Tatsache  (->  Untersuchungen des 
Xerox  research  centers),  da  eine  gute  graphische  Benutzeroberflche 
einenmglichst  einheitlichen  oder   besser   gesagt  harmonischen  "look" 
aufweisen  sollte  und  dem  "Unterbewutsein"  mglichst  wenig  Anla  zu 
Irritationen geben sollte. Das  hat  nichts mit bersteigertem sthetischem 
Empfinden zu tun. Es wre schn, wenn sich alle namhaften kommerziellen und 
Shareware-Programmierer  auf  einen  Standard   einigen  knnten  und  dann 
vielleicht eine unparteiische  Kontrollkommission  ein Zertifikat ("GEM-GUI 
Rev. x.x konform") vergeben knnte.  Als  Lektre zu diesem Thema empfehlen 
sich die entsprechenden Abschnitte  aus der englischsprachigen Artikelserie 
"Professional GEM" des RCS 1.0 - Autors Tim Oren.

Es wre	zumindest schon	ein	Fortschritt, wenn die Programmierer	die	rounded
radio buttons, cross buttons usw. der  AES untersttzen	wrden,	falls diese
solche Objekte bereitstellen, wie dies zur	Zeit (19.04.1997) bei MagiC	der
Fall ist.

Ich  kann  es  mir  nicht  verkneifen,  hier  eine  kleine,  unvollstndige 
Negativliste aufzufhren:
Artworx 1.21: blaue Ankreuzbuttons, rote shortcut-Unterstriche,
              Listboxen unter 3D-AES im single AES Look
JAnE 1.52:    rote Sliderpfeile
Clix 3.60:    ganz dnne Menzeilenseparatoren
POVShell 1.6: rote shortcut-Unterstriche
SysInfo 4.20: rote Beschriftung der Gruppenrahmenboxen

Es gibt aber auch lobenswerte Beispiel:
qed 4.0:      hlt sich noch am strksten an den Original-Flydial-Look
CAB 2.5:      trotz roter shortcut-Unterstriche ein Lob fr die Listboxen, 
              die sich in vorbildlicher Weise an den aktuellen AES-Look 
              halten!


7. GEM-NLS (GEM national language support)
Natrlich wei jeder,  welchen	Vorteil	 die  Resourcedateien  bieten: eine
leichtere bersetzung der  Dialoge	in	eine  Fremdsprache.	 Nun macht sich
leider nicht jeder	die	 Mhe,	die	 Resourcedatei	in	mehrere	Sprachen zu
bersetzen.	 Verstndlich  -  denn	 nicht	 jeder	kann  franzsisch  oder
schwedisch.	Bei	den	 lobenswerten  Programmen,	die	mehrere	Resourcedateien
mitbringen,	 gibt  es  jedoch  eine	  von  Fall	 zu	 Fall  unterschiedliche
Handhabung.	Oft	mu	die	 Resourcedatei	umbenannt werden. Ich schlage daher
das	"Flohr-Verfahren" vor:	die	 Resourcedatei	wird  nach folgendem Schema
gesucht	(dabei steht xy	fr	den	internationalen, zweistelligen country code
(de, en, it, fr, usw.),	 der  sich	aus	der	AES-Sprache	gem. appl_getinfo()
oder der TOS-Sprache ergibt):

 1. $NLSPATH/<xy>/RSC/name.rsc
 2. /usr/share/locale/<xy>/RSC/name.rsc
 3. es wird einfach nur name.rsc an rsrc_load() bergeben
    (rsrc_load() sucht dann via shel_find())

Selbstverstndlich	sollte/darf	  $NLSPATH	sowohl	 in	  UNIX-	  als  auch
DOS-Notation vorliegen (unix2dos() benutzen).


8. $HOME
Es ist mittlerweile	doch schon	recht  verbreitet,	doch leider	halten sich
einige	Programme  immer  noch	nicht  daran:  jedes  Programm,	 da  seine
Einstellungen (Stichwort: .INF-Datei) aus  einer  Datei	liest und schreibt,
sollte	diese	Datei	zunchst   in	dem	  Verzeichnis,	 auf   das	die
Environmentvariable	$HOME (getenv("HOME"))	zeigt,	suchen.	 Dies sorgt	fr
einen im wahren	 Sinne	des	 Wortes	 reibungsloseren Multiuserbetrieb (wenn
sich  unter	  KGMD	 oder	GEM-init   nacheinander	 unterschiedliche  user
einloggen).	Wer	sich an	Thomas	Much  halten  will,	liest und schreibt nach
$HOME\defaults\.   Die	 Extension	 der   Datei   ist	 nicht	festgelegt.
blicherweise werden .inf, .cnf	 oder  .cfg	verwendet. Der Dateiname sollte
jedoch eindeutig mit dem  zugehrigen  Programm	verknpft sein,	d.h. i.d.R.
bis	auf	die	Extension mit dem Programmnamen	identisch sein.	Sonst fllt	die
Zuordnung schwer, sollte  das  zugehrige  Programm	 einmal	gelscht werden
sollen. Auf jeden Fall aber Punkt 1.1 beachten!


9. threads
threads	gibt es	 sowohl	 unter	MiNT  (ber	 die  Funktion	tfork()	aus	der
MiNTLib), und damit	unter ATARI-AES	 4.x,  N.AES usw., als auch	unter MagiC
5.x	(als Unterfunktion von	shel_write()).	Warum  also	 nicht mal ein paar
threads	in ein GEM-Programm	einbauen? Ein  Editor knnte z.B. das Speichern
einer greren Datei einer thread  berlassen.	Ein	Desktop	knnte z.B.	das
Lschen	von	 mehreren  Dateien	einer  thread  berlassen.	CAB	 knnte	das
Formatieren	einer  Seite  einer	 thread	 berlassen.  Prinzipiell  ist	der
Einsatz	von	threads	sinnvoll,  wenn	 auf  Peripheriegerte zugegriffen wird
oder abzusehen ist,	 da  eine	bestimmte  Operation  eine	gewisse	Zeit in
Anspruch nehmen	wird,  der	Benutzer  aber	durchaus weiterarbeiten	knnte,
ohne da man Inkonsistenz  von	Daten  befrchten  mu.	Allerdings sind	der
Benutzung von threads Steine in den Weg gelegt:

1. man mu sich erst einmal eine Funktion schreiben, die tfork() und
   shel_write(SHW_CREATE_THREAD) unter einen Hut bringt
2. man darf zwar innerhalb einer thread AES-Aufrufe machen, jedoch mu die
   thread MT_AES.h benutzen und sich sowohl unter MiNT also auch MagiC
   mittels MT_appl_init() bei den AES anmelden
3. mchte man innerhalb einer thread per malloc() Speicher anfordern
   (passiert auch versteckt durch printf()!), so bentigt man _unbedingt_
   eine thread safe Speicherverwaltung. Fr C unter MiNT wurde eine solche
   Speicherverwaltung leider noch nicht gesichtet, wohl aber fr Modula-2
   (Quelle: ftp://ftp.cs.tu-berlin.de/pub/atari, im Verzeichnis programming
   oder so hnlich das Archiv M2LIB4, dort wiederum die Datei .../source/
   posix/c/mem.ipp. Die Verwendung von Malloc() ist jedoch kein Problem.
   MiNT bzw. MagiC wissen sehr genau, welchem process und welchem thread
   welcher Speicherblock gehrt.

Also Lohn dieser Arbeit	 (ich  meine  die  Steine wegrumen) winkt auch	die
Mglichkeit, z.B. Fselect()	 und  evnt_multi()	parallel  laufen zu	lassen,
oder gar zwei evnt_multi()-Schleifen parallel laufen zu lassen.


10. Drucken.
Prinzipiell	sollte jedes Programm  ber	 GDOS  drucken,	 sofern	 es	sich um
Grafik handelt.	Die	Grnde hierfr brauchen	heutzutage zum Glck nicht mehr
nher erlutert	werden.	Beim Drucken von reinen	Textdateien	(typischerweise
von	einem Editor aus) sollte man  ber	GEMDOS	drucken	und	nicht etwa ber
BIOS.  Darberhinaus  sollte  man  dann	 auch	den	 Druck	in	eine  Datei
ermglichen. Nur so	hat	man	 die  Mglichkeit, auf den Spooler /dev/lp oder
einen print	server	auszudrucken!  Vorbei  die	Zeit  des  Wartens	auf	den
Ausdruck! Selbst NVDI bietet  die  Mglichkeit,	 in	 eine Datei	zu drucken.
Nein,  nicht  GEM-Metafile,	 sondern   die	 Einstellung   einer  Datei	 in
NPRNCONF.CPX!


11. MT_AES.C
Die	Autoren	der	 MT_AES-Library	 haben	mir	 gegenber	zugegeben, das ihre
Implementation nicht unbedingt die	effizienteste  ist.	Der	AES-Parameter -
Block wird in jeder	AES-Funktion auf dem lokalen stack neu angelegt	und	bei
_jedem_	 Aufruf	 neu  initialisiert.  Darum	  an  dieser  Stelle  folgender
Vorschlag als Alternative:

In Wirklichkeit	braucht	ja	jede  AES-thread  nicht	 nur ein eigenes global
array, sondern einen eigenen Satz an kompletten	Eingabearrays,	d.h. global
und	 contrl,  int_in,  int_out,	 adr_in	  und  adr_out.	 Daher	wird  jeder
AES-Funktion nicht das global array,  sondern  gleich  ein Zeiger auf einen
thread-eigenen AES-Parameter-Block bergeben:

WORD MT_appl_init(AESPB *pb);

MT_appl_init()	fordert	 dann	dynamisch,	 allerdings	  per  _threadsafe_
malloc(), Speicher fr die	Eingabearrays  an  und	trgt deren	Adressen im
bergebenen	AESPB ein. Der AESPB ist somit einmalig	und	fr	die	Lebensdauer
der	thread initialisiert. Auf alle	Ein-  und Ausgabeparameter mu nun ber
Dereferenzierung des bergebenen AESPB zugegriffen werden.

Eine weitere Beschleunigung	ergibt sich	 durch die Verwendung von Registern
bei	der	 Parameterbergabe	an	den	 AES  call	sowie  die	Verwendung	des
movep-Befehls zum Fllen von contrl[0..3]:

#define F10 0x0A000100;
#define F11 0x0B020101;
...

WORD MT_appl_init(AESPB *pb);
...
{
 ...

 Adresse des pb z.B. nach a1,
 F10            z.B. nach d1,

 dann:

void mtaes(...); /* Parameterbergabe in Registern, z.B. a1 und d1 */
...
{
 move.l  (a1),a2  ; pb dereferenzieren
 movep.l d1,1(a2) ; pb noch einmal dereferenzieren und F10 eintragen
 move.l  a1,d1    ; Adresse des pb nach d1 (AES-Konvention)
 move.w  #200,d0  ; 0xC8 in d0 eintragen (AES-Konvention)
 trap    #2       ; und Sprung
 ...
}

Achtung: die Verwendung	 des  movep-Befehls	 erfordert	es,	 da das contrl
array vor dem ersten AES-call  gelscht	 wird, sonst enthalten die Hi-Bytes
junk. Da F10 usw. den  Inhalt  von	contrl	nur	 bis Anzahl	der	Eintrge in
adr_in enthlt,	 mu  pb.cb_pcontrol[4]	 (gleich  Anzahl  der  Eintrge	 in
adr_out) ebenfalls innerhalb  MT_appl_init()  gelscht	werden.	Die	einzige
Funktion, bei der die Anzahl der Eintrge in adr_out ungleich null ist,	ist
MT_rsrc_gaddr(). Dort ist pb.cb_pcontrol[4] temporr auf eins zu setzen.
