Software > Coding

Quelle für CF Lib (möglichst Source)

<< < (2/3) > >>

mfro:

--- Zitat von: ST-Oldie am Do 29.01.2015, 00:29:28 ---Also rpm der SpareMinT. Alles andere hält Leute mit alten Installation von Upgrades ab.
--- Ende Zitat ---
Das funktioniert leider nicht. RPM läuft auf dem ST nur in einer uralten Version, neuere sind nicht ohne weiteres portierbar.


--- Zitat von: ST-Oldie am Do 29.01.2015, 00:29:28 ---GEMLIB ist doch eine "Standard" GEM Lib, die sich an die API der Geiß Brüder anlehnt?

--- Ende Zitat ---
Die GEM libs, die hier gemeint sind, haben mit dem, was die Geiß-Brüder damals gemacht haben, nichts zu tun. Gemeint sind hier die "Standard" AES- und VDI-Libraries. Die "Geiß"-APIs gibt's meiner Kenntnis nach nur auf den Disketten zu den Büchern vom Huth-Verlag oder man schnibbelt sich aus den Quellen von Phoenix raus, was man braucht.


--- Zitat von: ST-Oldie am Do 29.01.2015, 00:29:28 ---Daß die Programme nicht stabil sind, ist ärgerlich. Aber das sollte sich ja finden lassen. Der Zusammenhang mit fopen/fread, speziell für /dev/random ist aber erstmal merkwürdig. Das klingt auf den erstren Blick eigentlich danach, als werden Informationen im Speicher überschrieben. also z.B. eine Pointerfehler o.ä.

--- Ende Zitat ---
Die Programme sind stabil, so man die gcc-Toolchain benutzt, für die sie gemacht sind. Mit AHCC hab' ich nie was gemacht, da mag es Probleme geben, aber QED z.B. läuft mit der CFLIB und gcc kompiliert einwandfrei.

ST-Oldie:
Hi,


--- Zitat von: mfro am Do 29.01.2015, 06:56:48 ---Das funktioniert leider nicht. RPM läuft auf dem ST nur in einer uralten Version, neuere sind nicht ohne weiteres portierbar.
--- Ende Zitat ---

Schade, aber wäre nicht wirklich ein Hinderungsgrund.


--- Zitat von: mfro am Do 29.01.2015, 06:56:48 ---Die GEM libs, die hier gemeint sind, haben mit dem, was die Geiß-Brüder damals gemacht haben, nichts zu tun. Gemeint sind hier die "Standard" AES- und VDI-Libraries.
--- Ende Zitat ---

Moment. Die Geiß-Libs sind die "Standard" AES und VDI-Libraries. Die hatten das damals mit Atari und DRI standardisiert. Und meine Turbo C GEM Lib und auch meine (alte) gcc GEM Lib folgen (bis auf ganz wenig Unterschiede) diesem Standard. Wenn jetzt eine GEM Lib das anders macht, dann ist sie keine Standard GEM Lib mehr.


--- Zitat von: mfro am Do 29.01.2015, 06:56:48 ---Die Programme sind stabil, so man die gcc-Toolchain benutzt, für die sie gemacht sind. Mit AHCC hab' ich nie was gemacht, da mag es Probleme geben, aber QED z.B. läuft mit der CFLIB und gcc kompiliert einwandfrei.
--- Ende Zitat ---

Damit wäre ja die Frage von M0n0 beantwortet. War die CF Lib denn von Anfang an für den gcc vorgesehen? Ich dachte, die wäre immerhin so alt, daß sie wahrscheinlich zuerst für einen anderen Compiler, z.B. Pure C, entwickelt wurde.

Tschüß
Michael

mfro:

--- Zitat von: ST-Oldie am Do 29.01.2015, 16:54:44 ---Hi,


--- Zitat von: mfro am Do 29.01.2015, 06:56:48 ---Das funktioniert leider nicht. RPM läuft auf dem ST nur in einer uralten Version, neuere sind nicht ohne weiteres portierbar.
--- Ende Zitat ---

Schade, aber wäre nicht wirklich ein Hinderungsgrund.

--- Ende Zitat ---
Na dann. Auf geht's! ;)



--- Zitat von: ST-Oldie am Do 29.01.2015, 16:54:44 ---
--- Zitat von: mfro am Do 29.01.2015, 06:56:48 ---Die GEM libs, die hier gemeint sind, haben mit dem, was die Geiß-Brüder damals gemacht haben, nichts zu tun. Gemeint sind hier die "Standard" AES- und VDI-Libraries.
--- Ende Zitat ---

Moment. Die Geiß-Libs sind die "Standard" AES und VDI-Libraries. Die hatten das damals mit Atari und DRI standardisiert. Und meine Turbo C GEM Lib und auch meine (alte) gcc GEM Lib folgen (bis auf ganz wenig Unterschiede) diesem Standard. Wenn jetzt eine GEM Lib das anders macht, dann ist sie keine Standard GEM Lib mehr.

--- Ende Zitat ---
Da weißt Du mehr als ich (was ich aber überhaupt nicht in Frage stellen will). Ich kenne von den Geiß-Brüdern lediglich die beiden Bücher über strukturierte GEM-Programmierung und natürlich Phoenix. Ich war immer der Überzeugung, daß die GEM APIs schon lange vorher durch DR festgeschrieben wurden.


--- Zitat von: ST-Oldie am Do 29.01.2015, 16:54:44 ---
--- Zitat von: mfro am Do 29.01.2015, 06:56:48 ---Die Programme sind stabil, so man die gcc-Toolchain benutzt, für die sie gemacht sind. Mit AHCC hab' ich nie was gemacht, da mag es Probleme geben, aber QED z.B. läuft mit der CFLIB und gcc kompiliert einwandfrei.
--- Ende Zitat ---

Damit wäre ja die Frage von M0n0 beantwortet. War die CF Lib denn von Anfang an für den gcc vorgesehen? Ich dachte, die wäre immerhin so alt, daß sie wahrscheinlich zuerst für einen anderen Compiler, z.B. Pure C, entwickelt wurde.

--- Ende Zitat ---
Das stimmt wohl - QED wurde zunächst mit Pure-C programmiert.

MJaap:
Die CF-Lib war von Anfang an sowohl für PureC als auch GnuC konzipiert. Ich habe sie selbst mit PureC zur Modernisierung von spareTIME verwendet.

ST-Oldie:
Hi,


--- Zitat von: mfro am Do 29.01.2015, 19:34:23 ---Na dann. Auf geht's! ;)
--- Ende Zitat ---

Na da würde ich mir ja die komplette Verwaltung einer Mintdistribution ans Bein binden. Ganz so viel Zeit stecke ich im Moment doch nicht mehr in Atari.

Ich kann mir im Moment eher vorstellen, mal wieder an meiner Homepage zu arbeiten und Doku zum Thema Atari zu erweitern bzw. vervollständigen. Da ist ja der Teil zum Programmieren, wo ich eine Übersicht über diverse Protokolel wie z.B. Olga, BubbleHelp, ... habe. Das könnte vielleicht eine Aktualisierung vertragen, wenn es mittlerweile tote Links gibt. Ich hab noch einen angefangenen GEM Programmier Kurs den ich fertigstellen könnte (nur bis TOS 3.xx). Neueres (ab Falcon, Mint, ...) ist noch gar nicht angesprochen. Evtl. fällt dabei auch etwas für Agelika's FireBee SDK ab. Und einfach um Leute einzuladen (wieder) mit Atari zu spielen ein paar einfache Anleitungen zum Einrichten, Bedienen, Instalaltion eines Emulators, ... Eine Übersicht über TOS Versionen, Hardware und Emulatoren ist ja schon da. Und meist auf vorhandene Seiten verwiesen.

Einfach deshalb, damit das nicht in Vergessenheit gerät. Und beim Programmierteil auch um selbst einen Überblick zu behalten.


--- Zitat von: mfro am Do 29.01.2015, 19:34:23 ---Da weißt Du mehr als ich (was ich aber überhaupt nicht in Frage stellen will). Ich kenne von den Geiß-Brüdern lediglich die beiden Bücher über strukturierte GEM-Programmierung und natürlich Phoenix. Ich war immer der Überzeugung, daß die GEM APIs schon lange vorher durch DR festgeschrieben wurden.
--- Ende Zitat ---

Das Buch "Vom Anfänger zum GEM Profi" verweist auf diese Arbeit. Ich hab aber aus dieser Zeit auch den Eindruck bekommen, daß sowieso jede Atari C Entwicklungsumgebung als Namen der C-Bindings die offiziellen Namen der GEM Funktionen verwendet. Auch die defines für Konstanten verwenden fast überall die gleichen Namen. Mit der Datei portab.h wurden dann Fehler oder Unterschiede ausgeglichen und Integer Datentypen einer definierten Länge definiert (WORD, ...). Außerdem wurde dadurch plattformunabhängiger Code (bzgl. GEM Programmierung) möglich.

Wenn man mal in den Quellcode der freigegebenen Programme schaut (RCS, Desktop) sieht man, daß dafür noch keine GEM Lib benutzt wurde. Die benutzten VDI Funktionen waren direkt Bestandteil des Sourcecodes. Und die Namen der VDI Funktionen entsprachen noch denen des GKS Grafikpakets von DRI, das dann zum GEM VDI wurde. Zumindest für diese Programme wurde noch eine andere GEM API benutzt. Zwar natürlich dieselben Funktionen, aber noch nicht die uns vom VDI bekannten Namen.

Tschüß
Michael

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete