Software > Coding
gcc crosscompiler - GEMlib
KarlMüller:
--- Zitat von: czietz am Fr 13.01.2017, 19:23:35 ---ist Deine Lösung, AES zu nutzen, ohnehin empfehlenswert. Die Nutzung von Getrez() in einem AES-Programm, wie in Peter Lanes Guide, sollte vermieden werden. Zitat aus TOS.HYP zu Getrez(): "Hinweis: Vom Standpunkt der sauberen Programmierung betrachtet, sollte diese Funktion auf keinen Fall benutzt werden."
--- Ende Zitat ---
Dies bezieht sich nur darauf, das über den Rückgabewert keine Aussage über die Auflösung gemacht werden kann. Wenn ich nicht falsch bin wird z.B. beim Falcon fünf zurück geliefert. Das verstehen dann Programme nicht und meinen es sei eine falsche Auflösung vorhanden.
Die Lösung mit appl_getinfo hat den Nachteil das diese Funktion erst ab einer bestimmten AES Version vorhanden ist. Wenn sie nicht da ist wird es zu einer Fehlermldung des Systems kommen.
czietz:
--- Zitat von: KarlMüller am Sa 14.01.2017, 08:50:49 ---Dies bezieht sich nur darauf, das über den Rückgabewert keine Aussage über die Auflösung gemacht werden kann. Wenn ich nicht falsch bin wird z.B. beim Falcon fünf zurück geliefert. Das verstehen dann Programme nicht und meinen es sei eine falsche Auflösung vorhanden.
Die Lösung mit appl_getinfo hat den Nachteil das diese Funktion erst ab einer bestimmten AES Version vorhanden ist. Wenn sie nicht da ist wird es zu einer Fehlermldung des Systems kommen.
--- Ende Zitat ---
Ich habe nochmal nachgelesen und Du hast Recht. In diesem speziellen Fall (Öffnen der virtuellen Workstation) ist die Nutzung der XBIOS-Funktion Getrez() sicherlich gerechtfertigt und vermutlich die Lösung, die unter den meisten TOS-Versionen funktioniert. Da das Abertausende von GEM-Programmen so machen -- immerhin hat Atari das im "GEM Programmer's Guide" einst genau so vorgegeben --, kann man auch davon ausgehen, dass z.B. Grafikkartentreiber das falls nötig abfangen und das Öffnen der virtuellen VDI-Workstation somit auch dann klappt, wenn der Rückgabewert von Getrez() eigentlich keine Aussagekraft mehr hat -- z.B. bei Bildschirmauflösungen, die nicht ST- oder TT-Standard entsprechen.
--- Zitat von: gh-baden am Sa 14.01.2017, 04:00:44 ---Was 1988 noch sauber war, mußte es 1993 nicht mehr zwangsläufig sein.
--- Ende Zitat ---
Da das von aligator123456 genutzte Tutorial von 2016 ist, würde ich erwarten, dass es "State-of-the-Art" GEM-Programmierung beschreibt und nicht auf den Stand von 1988.
goetz @ 3rz:
--- Zitat von: czietz am Sa 14.01.2017, 11:20:44 ---Da das von aligator123456 genutzte Tutorial von 2016 ist, würde ich erwarten, dass es "State-of-the-Art" GEM-Programmierung beschreibt und nicht auf den Stand von 1988.
--- Ende Zitat ---
Zum einen fragte der OP "was ist sauber" und nicht "ist mein Tutorial sauber", zum anderen hat das Erscheinungsdatum ja nicht notwendigerweise was mit der Richtigkeit des Inhalts zu tun.
Aber gut, dann schauen wir mal, ob "ist mein Tutorial sauber" bzw. "auf dem Stand 2016" als Fragestellung was interessantes abgibt …
--- Zitat --- wd.handle = wind_create (NAME|CLOSER, fullx, fully, fullw, fullh);
wind_set_str(wd.handle, WF_NAME, "Example: Version 1");
wind_open (wd.handle, fullx, fully, 300, 200);
--- Ende Zitat ---
In dem Codeschnipsel wird bspw. nicht geprüft, ob wind_create einen Fehler liefert, stattdessen wir mit diesem Rückgabewert als Handle einfach das Fenster geöffnet. Das war auch schon 1988 keine gute Idee. Auch v_opnvwk wird verwendet ohne zu prüfen, ob das gutging.
In "VERSION8" wird fsel_exinput aufgerufen, obwohl es das erst ab TOS 1.04 gibt, ohne Prüfung. Das gibt unter TOS 1.0/1.02 Ärger.
Und spätestens bei dem Schnipsel hier:
--- Zitat --- char * filename = malloc (sizeof(char) * (strlen(path)+strlen(name)));
/* connect path+name to form complete filename */
strcpy (filename, path);
--- Ende Zitat ---
(VERSION8, "main.c")
… bin ich raus: Versuchen Speicher zu allozieren und in den reinzuschreiben, egal ob der auch erfolgreich angefordert werden konnte. D.h. im Zweifel schreibt die Software nach Adresse 0 (denn das wäre der Fehlercode) und da hagelt es dann Bomben. Ne, das ist nicht nur nicht der Stand von 2016, das ist nichtmal der Stand von 1988.
Ich würde also zusammenfassend mich von diesem 2016er Tutorial abwenden und lieber die von mir vorher angeführten Werke lesen:
* D. Geiß, J. Geiß: Vom Anfänger zum GEM-Profi; ISBN 978-3778521823
* S. Maguire: Writing solid code; ISBN 1-55615-551-4; http://cs.brown.edu/courses/cs190/2008/documents/restricted/Writing%20Solid%20Code.pdf
* Jankoswki, Rabich, Reschke: Atari Profibuch ST-STE-TT; ISBN 3-88745-888-5; http://atariprofibuch.de
* J. Reschke: Atarium; Artikelserie im ST-Magazin; http://www.stcarchiv.de/
* L. Prüßner: Artikelserien im ST-Magazin; http://www.stcarchiv.de/
* U. Seimet: viele Artikel in diversen ST-Magazinen; http://www.stcarchiv.de/
mfro:
--- Zitat von: gh-baden am Sa 14.01.2017, 16:05:29 ---...
Und spätestens bei dem Schnipsel hier:
--- Code: --- char * filename = malloc (sizeof(char) * (strlen(path)+strlen(name)));
/* connect path+name to form complete filename */
strcpy (filename, path);
--- Ende Code ---
--- Ende Zitat ---
Abgesehen von den schon erwähnten Fehlern ist - so es denn klappt - der allokierte Speicherbereich jedenfalls um ein Byte zu kurz. Das gibt früher oder später mit großer Wahrscheinlichkeit so oder so ein Problem ...
aligator123456:
Danke für die Infos!
Da hab ich dann erstmal genug Lesestoff :)
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln