Software > Coding

Omikron und Gfa Basic unter Mint. Was ist zu beachten?!

<< < (7/8) > >>

gstoll:

--- Zitat von: michschmi am Do 15.07.2010, 10:26:57 ---Ach und warum wurde dann etwa zur Zeit des Autauchens der Clone-Ataris  überall postuliert, dass die systemnahe Programmierung Mist ist, weil inkompatibel zu anderen Systemen/Tos-Versionen und dass nur entsprechende (Gem)-Libraries benutzt werden sollten, um die Programme so sauber wie möglich auf allen möglichen Systemen laufen zu lassen?

--- Ende Zitat ---

Damit hast Du vollkommen recht, ich fürchte nur wir reden an einander vorbei.

Meine Frage war nur ob GFA-Basic eine GEM-Lib hat. Wobei mein Verständnis dafür erstmal ist, daß man alle GEM Systemfunktionen aufrufen kann, ohne irgendwelche Klimzüge wie Assemblerteile oder Peek und Poke.

Was Du meinst sind Libs die einem das Leben leichter machen. Dort benötigt man nur ein Kommando um z.B. einen Dialog zu öffnen. Wer das selbst mit GEM Kommandos macht muß drei oder nutzen.




--- Zitat von: simonsunnyboy ---Mint ersetzt das GEMDOS nämlich nur durch modernere Routinen und flexiblere Dateisystemtreiber.

--- Ende Zitat ---
Ich  setze grundsätzlich noch ein Pdomain(1)  am Anfang des Programms.

Gerhard

guest2552:
Hallo Arthur,

ein paar (sicher nicht erschöpfende) Antworten auf Deine Fragen im Allgemeinen und Omikron.BASIC betreffend:


--- Zitat ---Kann man ohne spezielle Bibliotheken schon lange Dateinamen verwenden?
--- Ende Zitat ---

Ab Version 5.13 kann Omikron.BASIC (das heißt der Editor) lange Dateinamen falls das System es unterstützt.
Das BASIC selbst ist unabhängig von langen Dateinamen.
Ob der BASIC-intern aufgerufene Fileselector lange Dateinamen korrekt behandelt weiß ich nicht.
Der Fileselector über die letzte mir bekannte GEM.LIB oder GEM.BAS aufgerufen kann langen Dateinamen nicht korrekt verarbeiten (Dateinamenspeicher nur für 13 Zeichen!) Auch ist diese GEM.LIB nicht besonders Multitaskingtauglich da es die Handles von Fremdfenstern ignoriert und die entspr. AES-Funktionen einfach nicht ausgeführt werden.
Diese 2 Probleme liesen sich jedoch (bei Interesse an der Programmierung über die GEM.LIB) ohne Aufstand lösen.


--- Zitat ---Läuft so ein Programm unter Mint als auch TOS?
--- Ende Zitat ---

Ja! Aber:
Mir ist kürzlich (recht einfach) eine Installation von MiNT +  XaAES oder MyAES unter Aranym auf Windows gelungen und mußte feststellen, dass nach einigen AES-betreffende kleinen Anpassungen meiner Programme alle sehr stabil liefen (z.Zt. noch ausgenommen der freien Listboxen).
Die grundsätzliche Lauffähigkeit von Omikron.BASIC-Compilaten ist also unter TOS, MiNT, Geneva, XaAES und (naja) MyAES gegeben.
Das Hauptproblem taucht erst auf nachdem ALLE laufenden Omikron.BASIC-Compilate (auch das Omikron.BASIC selber) beendet wurden:
Darauf gestartete Applikationen können beim Start das System zum Totalhänger bringen.
Ich denke dass dies an verbogenen Zeigern des Omikron.BASIC in Zusammenhang mit MiNT liegt, weiß es aber nicht sicher!
Einen ausschließlichen MiNT-Betrieb hab ich noch nie versucht - hier bräuchte ich mal Nachhilfe (Installation, Sinn und Zweck). Zum Aktivieren/Testen von Netzwerken hab ich keinerlei Möglichkeit.


--- Zitat ---Wie könnte eine Abfrage des OS (unter dem es gerade läuft) im Programm aussehen?
--- Ende Zitat ---

Ich habe in der OW-DEMO.APP der OM-WINs-Library in einem Textfenster eine textbasierte Mini-Version des Programmes SYSHELP in dem die viele Systemaufrufe und -abfragen in der Sourcedatei ersehen könntest. (Aber bitte nächstes Update abwarten)

zu 4. ???

zu 5. Für Omikron.BASIC kenne ich auch nur noch Karsten Lüdersens Seiten zur KLib-Library


--- Zitat ---Welche Versionen sollte ich dafür nehmen?
--- Ende Zitat ---

Omikron.BASIC 3.6 für Single-TOS-Betrieb bei Programmerstellung (leider mit leichten Einschränkungen im Code) oder V5.20 für Multitasking und schnellere Rechner.
Omikron.BASIC selber läuft unter TOS, Geneva, MagiC.
Unter XaAES darf kein Dauerklick (z.B. Blockaufziehen) ausgeführt werden da es zu einer Endlosschleife führt (Fehler in XaAES oder drunterliegendem EmuTOS in der Funktion graf_mkstate() - bei zu hochfrequentem Aufruf wird kein Maustaste-loslassen mehr zurückgemeldet). Zudem muß man mit der Fensterverwaltung (Tokenlisting) vorsichtig sein!
Unter MyAES verschwindet die Menuzeile des Omikron.BASIC sofort wieder und das System hängt!


--- Zitat ---1. Wer Programmiert eigentlich noch an einem richtigen Atari und wer benutzt dafür eher einen Emulator wie Steem, Hatari oder Stemulator oder gar Aranym dafür?
2. Welche Überraschungen oder Besonderheiten sind bei der Verwendung eines Emulators evtl. zu beachten?
--- Ende Zitat ---

Unter Steem auf dem PC läuft die Sache sehr ordentlich, wie ich bemerkte (hab ich im Frühjahr zum weiteren Testen und Entbuggen von OM-WINs und der Applikationen genutzt!) Allerdings bekomme ich den AUTO-Ordner nicht in Betrieb.
Mit dem Stemulator hatte ich Anfang 2000 keine guten Erfahrungen gemacht. Weitere Updates habe ich nicht mehr versucht.
Hatari kenne ich nicht.


--- Zitat ---Benötige ich unbedingt ein Resource Construction Set oder gehts auch ohne? Und wenn ja, welches würdet ihr empfehlen?
--- Ende Zitat ---

INTRFACE.PRG: mittlerweile kostenlos, sehr stabil, sauber und kompatibel und keineswegs veraltet!


... und noch ein kleiner Nachtrag zum Mörderposting:
Reine TOS-Programme (sauber in Fenster laufend) sind mit Omikron.BASIC nicht möglich da das BASIC bzw. das Compilat Appl_Init IMMER selbstständig aufruft und vom Programmierer nicht unterbunden werden kann.
Es sind also neben sauberen GEM-Programmen nur Schmuddelprogramme ala TOS oder ein GEM/TOS-Mischmasch möglich.
Als Accessory compliert gibt's meines Wissens auch keine Probleme (Einschränkung: der Accessoryplatz ist weg und es ist keine Menuzeile möglich)

Gruß Charly

Arthur:
Hallo Charly, hab mir gestern und vorgestern mal deine Seite angeschaut und deine mächtigen Libs für Omikron Basic. Was Du da Programmiert hast ist schon echt riesig. Es scheint wirklich der Wurm in Omikron Basic zu stecken wenn es um das OS MiNT geht. Leider haben dein umfangreichen Infos eher abgeschreckt als ermutigt. Ich möchte eigentlich nur ein wenig Programmieren und mich nicht mehr als nötig um die zahlreichen Bugs in Omikron-Basic oder dem Atari OS TOS und MiNT zu kümmern. Mit Geneva und Magic hab möchte ich mich nicht beschäftigen da es Einbahnstraßen sind die nicht weiter ausgebaut werden. Auf dem Falcon mit NVDI ist auch MiNT für die meisten Zwecke mehr als schnell genug. Ich warte jetzt erst mal den C-Kurs hier im Forum ab. Und nochmals vielen Dank für deine neutrale und ausführliche Antwort zum Omikron Basic.

Gruß Arthur

m0n0:
Wenn es um Mint geht... also wenn du ein Tool für mint schreiben willst, und es keine GEM-GUI haben muss, dann würde evt. auch eine Script Sprache wie Python angebracht sein,... Damit wird das programmieren auch Wesentlich einfacher!

Nur müsstest du eine Konsolen Gui erstellen... also ohne GEM, denn soweit ich weiss hat das MiNT-Python keine GEM Anbindung.

Eine andere Möglichkeit wäre PERL....

Omikronman:
Tja Arthur, programmieren heißt auch, Probleme zu lösen. Eine Programmierumgebung für den Atari, die mit all die superexotischen Systemerweiterungen, die in den letzten Jahren aus dem Boden gestampft wurden perfekt umgehen kann, kenne ich nicht. Dafür ist der Atari vermutlich auch schon zu lange tot. Wenn man mit dem Atari unbedingt etwas machen will, wofür er nicht gemacht war darf man sich nicht beklagen, wenn das Probleme bereitet. Niemand hat behauptet, daß programmieren einfach ist. Solange Du Dich aber nicht an die erste Zeile Deines Programms wagen willst, brauchst Du eigentlich gar keine weiteren Fragen stellen, denn Programmieren ist nun mal ein langwieriger Lernprozeß, bei dem man umso besser wird, je mehr Zeit man damit verbringt. Und das bedeutet nunmal, irgend wann los zu legen, auch, wenn manche Fragen erst einmal keine befriedigende Antwort finden.

"Ich möchte eigentlich nur ein wenig Programmieren und mich nicht mehr als nötig um die zahlreichen Bugs in Omikron-Basic oder dem Atari OS TOS kümmern."

Quatsch. Du willst nicht programmieren. In mehr als zehn Jahren Omikron.Basic habe ich keine Bugs bemerkt die Dich, falls Du ernsthaft daran interessiert wärst "eigentlich nur ein wenig zu programmieren", davon ahalten würden, genau das zu tun. Wenn Du Deine ganzen Vorbehalte mal ablegen und einfach loslegen würdest wäre das schon ein guter Schritt nach vorn! Der Atari ist aus einer Zeit als man noch bereit sein mußte, Kompromisse einzugehen. Es gab Leute, die ernsthaft erwarteten, daß ein Spiel wie Crown of Creation im GEM-Fenster laufen können müsse. Das ist definitiv nicht möglich (wer es nicht glauben will: ich sprach seinerzeit mit Rebelsoft darüber). Es kann sein, daß Du irgendwann merkst, daß sich Dinge am Atari möglicherweise nicht oder nur unzureichend in Vereinbarung bringen lassen. Wenn Dir dieser Gedanke Kopfschmerzen bereitet, so mußt Du halt die Idee mit dem Programmieren an den Nagel hängen, auch wenn´s schwer fällt. :-/

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete