atari-home.de - Foren
Software => Coding => Thema gestartet von: goetz @ 3rz am Do 18.01.2024, 20:54:18
-
Hat die jemand, am besten übersetzt mit PureC?
(mit TurboC habe ich’s schon, aber das b0rkt in einem PureC-Projekt, und ich will versuchen …)
-
Niemand?
-
Scheinbar nicht.
Ich habe das Teil nie in freier Wildbahn gesehen. Auf Julians alter Seite gabe die wohl nicht und auf der neuen auch nicht. Kenne nur einen mini Teil des Quellcodes, weil er mal in einer Maus Gruppe gepostet wurde.
-
Niemand?
Hast Du schon mal die direkte Kontaktaufnahme versucht?
Wenn ich mich nicht täusche, dann ist Julian Reschke einer der Geschäftsführer der Firma Greenbytes GmbH.
-
Ich habe das Teil nie in freier Wildbahn gesehen. Auf Julians alter Seite gabe die wohl nicht und auf der neuen auch nicht. Kenne nur einen mini Teil des Quellcodes, weil er mal in einer Maus Gruppe gepostet wurde.
Hmm. Ich versuche die Gemini-Sourcen zu übersetzen (das Venus-Mupfel-Gemini-Paket), und FlyDials liegen da als Objektdatei bei, für Turbo C. Das ganze Projekt ist mit Turbo angelegt, ich habe in der Projektdatei die (Standard-)Libs und die Startup-Datei gegen die PureC-Äquivalente getauscht, es baut auch durch, aber im Linking habe ich einen Fehler: c:\src\……\flydial.lib: Undefined Symbol '_AesCtrl'
Den erhoffte ich mit meiner Anfrage loszubekommen, aber vielleicht liege ich auch komplett falsch mit meiner Raterei.
Edit: Wenn ich das Projekt mit TurboC übersetze, dann ist der Fehler weg.
-
Hast Du schon mal die direkte Kontaktaufnahme versucht?
Wenn ich mich nicht täusche, dann ist Julian Reschke einer der Geschäftsführer der Firma Greenbytes GmbH.
Jap, to no avail (O-Ton: zu lange her).
-
Hast Du schon mal die direkte Kontaktaufnahme versucht?
Wenn ich mich nicht täusche, dann ist Julian Reschke einer der Geschäftsführer der Firma Greenbytes GmbH.
Jap, to no avail (O-Ton: zu lange her).
Schade. Aber da kann man wohl nichts mehr machen.
-
Hmm. Ich versuche die Gemini-Sourcen zu übersetzen (das Venus-Mupfel-Gemini-Paket),
Huks. Wo hast du die denn her? Die würden mich echt interessieren. Sind die externen tools auch dabei?
und FlyDials liegen da als Objektdatei bei, für Turbo C.
Wie gross ist denn die lib? Evtl. könnte man die mit dispobj disassemblieren, und wieder in eine Form umwandeln die man übersetzen kann.
Das ganze Projekt ist mit Turbo angelegt, ich habe in der Projektdatei die (Standard-)Libs und die Startup-Datei gegen die PureC-Äquivalente getauscht,
es baut auch durch, aber im Linking habe ich einen Fehler: c:\src\……\flydial.lib: Undefined Symbol '_AesCtrl'
Da muss man aufpassen beim ersetzen. Wenn er sich fehlende AES-Funktionen nachgebaut hat, geht das schief, weil die Strukturen unterschiedlich sind, die lib aber die alten Strukturen benutzt.
-
Hmm. Ich versuche die Gemini-Sourcen zu übersetzen (das Venus-Mupfel-Gemini-Paket),
Huks. Wo hast du die denn her? Die würden mich echt interessieren. Sind die externen tools auch dabei?
Von Gereon, auf meine Anfrage und etwas Schubs und Support beim "alte-SCSI-Platte-gefunden-und-jetzt-auslesen". Vorerst private, bald public, unter MIT-Lizenz.
Es ist komplett Venus+Mupfel+Gemini, aber auf dem Stand V.1.2.2, also ein Releasestand nach der letzten 1.x (1.2.1), und vor der ersten 1.9. Erste Anpassungen an MultiTOS sind drin enthalten.
Wie gross ist denn die lib? Evtl. könnte man die mit dispobj disassemblieren, und wieder in eine Form umwandeln die man übersetzen kann.
40 KB
Da muss man aufpassen beim ersetzen. Wenn er sich fehlende AES-Funktionen nachgebaut hat, geht das schief, weil die Strukturen unterschiedlich sind, die lib aber die alten Strukturen benutzt.
Ich fürchtete sowas schon, daher mein OP.
Ich hab noch 1 weiteren Linker-Fehler bei "du" in der Mupfel, aber da such ich noch etwas.
-
Hier der genannte mini Teil der Quellen. Wurde auch in der ST-Computer 9/1995 Seite 88 abgedruckt.
https://www.stcarchiv.de/stc1995/09/atarium (https://www.stcarchiv.de/stc1995/09/atarium)
MausNet Gruppe war gelogen, es war die Fido.ATARI_EXPERT.GER
-
if (_GemParBlk.global[0] >= 0x0400 || 0 == appl_find ("?AGI\0\0\0\0"))
Dort sieht man das angesprochene Problem. Die _GemParBlk Struktur ist unterschiedlich zwischen Pure-C und Turbo-C, solange man die kompletten Sourcen der Flydial-Library nicht neu mit Pure-C übersetzen kann, muss man wohl notgedrungen erstmal bei Turbo-C bleiben.
-
Dort sieht man das angesprochene Problem. Die _GemParBlk Struktur ist unterschiedlich zwischen Pure-C und Turbo-C, solange man die kompletten Sourcen der Flydial-Library nicht neu mit Pure-C übersetzen kann, muss man wohl notgedrungen erstmal bei Turbo-C bleiben.
Wenn ich das richtig sehe ist der Codeauschnitt von 1995, die Lib in den veröffentlichten Gemini Quellen ist von 1991. Da kommt das ganze wohl her. Die Funktionen scheinen auch nicht in der Lib von 1991 zu sein.
Neuere Gemini Versionen enthalten eine aktuellere Lib.
-
Neuere Gemini Versionen enthalten eine aktuellere Lib.
Eine *.lib sehe ich da aber nirgendwo. Wenn du sowas hast, immer her damit ;)
Wie schon im anderen Thread gesagt, Pure-C ist von 1993, also kann die Version von Gereon nur mit Turbo-C übersetzt worden sein (sieht man auch wenn man sich den Code anschaut, Turbo-C erzeugt etwas anderen Code). Es wäre vermutlich auch kein Problem die FlyDial lib mit Pure-C neu zu übersetzen, aber dafür braucht man erstmal die Sourcen. Was man aber halt nicht machen kann ist die Sachen zu mischen.
-
Eine *.lib sehe ich da aber nirgendwo. Wenn du sowas hast, immer her damit ;)
Habe ich leider nicht. Einfach das Programmfile von Gemini im Editor öffnen und nach dem String "FlyDials" suchen. Dann sieht man die Version.
-
Ich wunder mich trotzdem daß man die nirgendwo findet. War denn Gemini das einzige Programm das die Library benutzt hat?
-
Ich wunder mich trotzdem daß man die nirgendwo findet. War denn Gemini das einzige Programm das die Library benutzt hat?
Reschkes Tetris-Klon Kubis 96 nutzt die Lib ebenfalls. Hilft aber nicht wirklich weiter...
-
Ich wunder mich trotzdem daß man die nirgendwo findet. War denn Gemini das einzige Programm das die Library benutzt hat?
Rufus verwendet die Library ebenfalls.
-
Naja immerhin, aber irgendwie schon komisch. So eine Library macht ja nur Sinn wenn man sie auch verbreitet (wenigstens in binärer Form). Ich finde sie aber nichtmal in Archiven von Öffentlichen Programmteilen des MausNetz.
-
Naja immerhin, aber irgendwie schon komisch. So eine Library macht ja nur Sinn wenn man sie auch verbreitet (wenigstens in binärer Form). Ich finde sie aber nichtmal in Archiven von Öffentlichen Programmteilen des MausNetz.
Die gab es wohl nicht öffentlich. (nur ihre unzähligen Klone)
-
In meinen FTP-Abzügen von funet.fi, TU Berlin, Uni Paderborn und leo.org von Oktober 2010 ist auch nichts zu finden.
-
So,
mein TT ist entstaubt, und es ist mir gelungen, ein paar Sourcen zu "retten".
Daher: https://github.com/reschke/FlyDials
-
Oh wow, das ist ja mal ''ne Überraschung ;)
Du hast nicht zufällig auch noch Sourcen von Gemini gefunden? Gereon hat zwar schon was veröffentlicht, allerdings eine recht alte Version.
-
Oja! Ich drück die Daumen dass da noch was von Gemini ist. Die Mupfel war der Grund warum ich mit Linux angefangen habe :)
-
So,
mein TT ist entstaubt, und es ist mir gelungen, ein paar Sourcen zu "retten".
Daher: https://github.com/reschke/FlyDials
Klasse, danke!
Auf den ersten Blick fehlt (aus clip.c, form.c …) "flydial/flydial.h" bzw. "../include/flydial/flydial.h" das ich grad nirgends finde. Schaust du ggfs. nochmal „eine Ebene höher“?
-
...flydial.h - ich schaue mal - kann aber ein wenig dauern.
-
Oh wow, das ist ja mal ''ne Überraschung ;)
Du hast nicht zufällig auch noch Sourcen von Gemini gefunden? Gereon hat zwar schon was veröffentlicht, allerdings eine recht alte Version.
https://github.com/gereons/gemini2
-
Oh wow, das ist ja mal ''ne Überraschung ;)
Du hast nicht zufällig auch noch Sourcen von Gemini gefunden? Gereon hat zwar schon was veröffentlicht, allerdings eine recht alte Version.
https://github.com/gereons/gemini2
Die URL ist 404 / nicht öffentlich.
Gereon hatte eine V.1.26 (ungefähr) veröffentlicht, die 2er (bzw. 1.99…) Sourcen hatte er nicht gefunden.
-
...flydial.h - ich schaue mal - kann aber ein wenig dauern.
Als start kann man erstmal https://github.com/gereons/gemini/blob/main/FLYDIAL/FLYDIAL.H nehmen. Es fehlen aber auch noch ein paar andere (wk.h z.b.) Vermutlich sind die im Pure-C include Ordner bei dir?
-
Oh wow, das ist ja mal ''ne Überraschung ;)
Du hast nicht zufällig auch noch Sourcen von Gemini gefunden? Gereon hat zwar schon was veröffentlicht, allerdings eine recht alte Version.
https://github.com/gereons/gemini2
Die URL ist 404 / nicht öffentlich.
Gereon hatte eine V.1.26 (ungefähr) veröffentlicht, die 2er (bzw. 1.99…) Sourcen hatte er nicht gefunden.
Das Repo ist da, aber nicht öffentlich. Ich frage nach.
-
...flydial.h - ich schaue mal - kann aber ein wenig dauern.
Als start kann man erstmal https://github.com/gereons/gemini/blob/main/FLYDIAL/FLYDIAL.H nehmen. Es fehlen aber auch noch ein paar andere (wk.h z.b.) Vermutlich sind die im Pure-C include Ordner bei dir?
Das:
https://github.com/search?q=repo%3Areschke%2FFlyDials%20include&type=code
sollte alle Includes finden, richtig?
-
Ja, schon. Aber im repo sind diese Dateien nicht vorhanden, können also nur vom einem vorher installierten zoo-archive von 1995 stammen. Das ist aber nirgendwo mehr zu finden (weiss auch nicht ob das damals überhaupt öffentlich verfügbar war, oder nur für Beta-Tester)
-
Ja, schon. Aber im repo sind diese Dateien nicht vorhanden, können also nur vom einem vorher installierten zoo-archive von 1995 stammen. Das ist aber nirgendwo mehr zu finden (weiss auch nicht ob das damals überhaupt öffentlich verfügbar war, oder nur für Beta-Tester)
Schon klar. Ich wollte nur sichergehen, dass ich dann auch alle Include-Files finde.
-
Oh wow, das ist ja mal ''ne Überraschung ;)
Du hast nicht zufällig auch noch Sourcen von Gemini gefunden? Gereon hat zwar schon was veröffentlicht, allerdings eine recht alte Version.
https://github.com/gereons/gemini2
Die URL ist 404 / nicht öffentlich.
Gereon hatte eine V.1.26 (ungefähr) veröffentlicht, die 2er (bzw. 1.99…) Sourcen hatte er nicht gefunden.
Das Repo ist da, aber nicht öffentlich. Ich frage nach.
Wohooo, ein Gemini-1.9x-Stand von ~1996 (das Repo ist jetzt öffentlich). Klasse, danke euch!
-
Wie nice! Gleich mal schauen ob man das übersetzt bekommt.
-
Hope this helps:
https://github.com/reschke/FlyDials/tree/main/include
...and it seems it does:
(http://)
-
Hope this helps:
https://github.com/reschke/FlyDials/tree/main/include
...and it seems it does:
Danke! Hmm, ich bin nicht so gut. Ist „außerhalb“ der FlyDials, anderseits wurde PureC’s PORTAB.H bisher noch nie angemeckert?
-
Wo die Include-Dateien liegen ist ja erstmal nicht so wichtig. Vermutlich sollte es eine Unterscheidung zwischen denen geben, die zum Bauen der Library nötig sind, und denen (mehrere?), die zur Benutzung relevant sind.
Den Fehler bzgl portab.h habe ich nicht. Vielleicht unterschiedliche Versionen? (bei mir steht da: "typedef int BOOLEAN;")
-
Wo die Include-Dateien liegen ist ja erstmal nicht so wichtig
Leider doch (momentan). In den Sourcen wird überall
#include <flydial\flydial.h>
benutzt. Das passt leider nicht zur momentanen Ordner-Struktur, wo die Datein im "include" Verzeichnis liegen.
Vermutlich sollte es eine Unterscheidung zwischen denen geben, die zum Bauen der Library nötig sind, und denen (mehrere?), die zur Benutzung relevant sind.
Ja, sehe ich auch so. Muss man mal sehen was z.B. für gemini2 notwendig ist, idealerweise sollte das nur flydial.h sein. Allerdings wird dort auch fontsel.h gebraucht, und damit auch ein paar andere includes.
Den Fehler bzgl portab.h habe ich nicht. Vielleicht unterschiedliche Versionen? (bei mir steht da: "typedef int BOOLEAN;")
In der original portab.h steht da
typedef char BYTE;
und der Fehler wird durch https://github.com/reschke/FlyDials/blob/f1ab8fa6d1b70164016c8c771799671aa0c2e196/src/GRAF.C#L82 verursacht:
#define BYTE unsigned char
Besagte Zeile in graf.c löschen und, die Reihenfolge ändern hilft (dadurch wird portab.h zuerst included)
#define EXTERN extern
#include "uhr.rsh"
#include "uhr.rh"
Eine erste leicht bereinigte Version ist auf https://github.com/th-otto/FlyDials zu finden. Jetzt mal schauen, was Gemini2 damit anfangen kann ;)
PS.: zum kompletten Glück würden noch die mupfel-tools fehlen (auch wenn man die mittlerweile grösstenteils durch die coreutils von mint ersetzen kann).
-
Gemini scheint damit glücklich zu sein ;)
Edit: es fehlte noch die Definition der MacFinderInfo Struktur. Die konnte ich aber aus https://github.com/th-otto/MagicMac/blob/master/extensio/cd-mxfs/macfs.h übernehmen.
-
1) Der Pfad zum Include-Verzeichnis kann in Pure-C konfiguriert werden.
2) typedef BYTE: Ok; seltsam, dass es bei mir funktoniert. Bitte PR auf Github.
3) mupfel-tools: müsste ich suchen.
4) Gemini 2: war das Kompilieren trivial, oder willst Du ein README beisteuern?
-
1) Der Pfad zum Include-Verzeichnis kann in Pure-C konfiguriert werden.
Ja, schon klar. Hilft aber nicht, wenn <flydial\flydial.h> gesucht wird, die Datei aber in <include\flydial.h> steht.
2) typedef BYTE: Ok; seltsam, dass es bei mir funktoniert. Bitte PR auf Github.
Ich schätze mal, daß deine portab.h eine komplett andere als die vom original Pure-C ist (vermutlich angepasst an PC-GEM). xrsrc.h z.B. scheint auch zu erwarten, daß dort GLOBAL, EXTERN, FAR, GEMDOS, GEM etc. entsprechend definiert sind.
3) mupfel-tools: müsste ich suchen.
Wäre grossartig, der Vollständigkeit halber. Wie gesagt, einige kann man vermutlich auch durch die mint-binaries ersetzen (date z.B), einige andere sind eh auch in gemini eingebaut (cp, mv). Gibt aber auch welche die Atari-spezifisch sind und vermutlich nirgendwo anders zu finden sind (runopts zb).
4) Gemini 2: war das Kompilieren trivial
Geht so, siehe oben. Hauptproblem war die portab.h, und damit xrsrc.[ch]. In ls.c musste ich auch noch ein paar Sachen ändern (S_ISDIR etc. sind original weder in tos.h noch in ext.h definiert). Gross getestet habe ich bisher auch noch nicht, nur gesehen daß sich sowohl Gemini als auch die standalone-mupfel kompilieren lassen. Möglich, daß ich noch ein paar Fallstricke übersehen habe.
willst Du ein README beisteuern?
Ich habs jetzt erstmal in meinem fork hochgeladen (https://github.com/th-otto/gemini2).
BTW, es würde auch noch Sourcen für die exec_obj.lib fehlen (Interface zu Kobold). Falls du die nicht finden kannst, kann man die auch rekonstruieren (ist nicht besonders gross).
-
Ich schätze mal, daß deine portab.h eine komplett andere als die vom original Pure-C ist (vermutlich angepasst an PC-GEM). xrsrc.h z.B. scheint auch zu erwarten, daß dort GLOBAL, EXTERN, FAR, GEMDOS, GEM etc. entsprechend definiert sind.
Den PC-GEM-Support können wir eigentlich entfernen; kannst Du mir die ursprüngliche portab.h irgendwo hinlegen?
Sourcen für die exec_obj.lib fehlen (Interface zu Kobold)
Ich glaube nicht, dass "wir" die je im Source hatten -- müsste man Hansi Reichstein (der war es doch, oder?) finden.
-
Den PC-GEM-Support können wir eigentlich entfernen;
Ja, macht für xrsrc.c eh keinen Sinn, das ist eh Atari-spezifisch. Das hat bei den Gemini 1.2-Sourcen und in diversen anderen Projekten auch schon für Probleme gesorgt.
<portab.h> wurde allerdings auch ursprünglich in hello.rh eingebunden; dort habe ich es jetzt erstmal manuell entfernt (was ein bisschen unschön ist, weil das überschrieben wird wenn man sie mit dem Resource-Editor neu erzeugt).
kannst Du mir die ursprüngliche portab.h irgendwo hinlegen?
Die ist recht simple:
/* PORTAB.H
For use with rsh output of RCS
Copyright (c) Borland International 1990
All Rights Reserved.
*/
#if !defined( __PORTAB__ )
#define __PORTAB__
typedef void VOID;
typedef char BYTE;
typedef int WORD;
typedef long LONG;
typedef unsigned char UBYTE;
typedef unsigned int UWORD;
typedef unsigned long ULONG;
#endif
/***********************************************************************/
Ich glaube nicht, dass "wir" die je im Source hatten
Dann mach ich mich mal an die Arbeit ;)
PS.: ich kann die Änderungen auch als PR für euer repo zur Verfügung stellen wenn dir das lieber ist, allerdings ist der erste commit recht umfangreich (ohne daß sich wirklich viel geändert hat), weil ich erstmal alle Dateien umbenannt habe, da sie bei mir in einem Verzeichnis auf dem linux-host liegen.
-
Bitte eine minimale PR :-)
Die Großbuchstaben habe ich aus nostalgischen Gründen dringelassen.
-
Bitte eine minimale PR :-)
Das wird schwierig, wenn ich die Dateien nicht umbenennen soll, weil die folgenden Änderungen ja darauf aufbauen. Wenn du das aus nostalgischen Gründen nicht magst, kann ich das verstehen, aber für meine Arbeitsumgebung ist das notwendig, weil ich sonst die Dateien nach Änderungen doppelt habe, einmal klein, einmal gross.
Vlt. hilft es dir ja erstmal nachzuvollziehen, was ich in https://github.com/th-otto/gemini2/commit/ddd5715e8668d09c500556aec647113929366398 geändert habe.
PS.: die sourcen scheinen tatächlich "der neueste ****" zu sein:
$ grep sccsid FlyDials/src/handle.c
static char sccsid[] = "@(#)Fliegende Dialoge 0.57, Copyright (c) "
$ strings gemini.app | grep Fliegende
@(#)Fliegende Dialoge 0.48, Copyright (c) Julian F. Reschke, Jan 15 1995
-
...zunächst ging's mir um die FlyDials...
-
Bitte eine minimale PR :-)
Das wird schwierig, wenn ich die Dateien nicht umbenennen soll, weil die folgenden Änderungen ja darauf aufbauen. Wenn du das aus nostalgischen Gründen nicht magst, kann ich das verstehen, aber für meine Arbeitsumgebung ist das notwendig, weil ich sonst die Dateien nach Änderungen doppelt habe, einmal klein, einmal gross.
Und wenn du ein FAT16-Image loop-mountest, und darin die Gemini-Sourcen compilierst? Damit kommt Linux klar, und Hatari & GEMDOS-Emulation legen (weil es nicht anders geht) keine anderen „Schreibweisen“ der Dateinamen in klein an.
-
Das wäre noch umständlicher. Dann müsste ich die Dateien ja jedesmal hin- und her kopieren, das .git Verzeichnis und alles was darin ist muss ja klein bleiben, und hat auch zu lange Dateinamen.
-
Das wäre noch umständlicher. Dann müsste ich die Dateien ja jedesmal hin- und her kopieren, das .git Verzeichnis und alles was darin ist muss ja klein bleiben, und hat auch zu lange Dateinamen.
Okay, also doch noch ein Wunsch an die Hatari-Emulation, das GEMDOS-Layer optional mit "egal was an Fscreate reinkommt, mach Großbuchstaben" draus zu betreiben ;)
-
Wer sagt daß ich Hatari dafür benutze? ;)
-
Okay, also doch noch ein Wunsch an die Hatari-Emulation, das GEMDOS-Layer optional mit "egal was an Fscreate reinkommt, mach Großbuchstaben" draus zu betreiben ;)
Ähm, ist das nicht das Szenario, wofür...
--gemdos-case <x>
Specify whether new dir/filenames are forced to be in upper or lower case with GEMDOS HD emulation. Off/upper/lower, off by default
... da ist?
-
exec_job.c ist nun fertig (siehe https://github.com/th-otto/gemini2/commit/371e227c511e588c13491679907691ea185ab402)
Es gibt dort allerdings ein paar Fallstricke:
- Bei der Prüfung auf die AES version wird dort auf _GemParBlk[5] zugegriffen. In der original aes.h von Pure-C fängt die Struktur mit int contrl[15] an, danach kommt dann das global array. Ich kann mir das nur so erklären daß der Source mit den Headern einer anderen Library übersetzt wurde. Betrifft allerdings nur MiNT, MagX wird vorher abgefragt.
- Beim überprüfen des Pfades von kobold_2.prg wird die DTA der Applikation auf einen privaten Bereich gesetzt, aber hinterher nicht auf den alten Wert zurück gesetzt.
- Wenn auf Antwort von Kobold gewartet wird, wird dies in einer evnt_mesag() Schleife gemacht. Andere messages die für die Applikation gedacht waren gehen dabei verloren. Es ist dort auch kein timeout vorgesehen, wenn Kobold nicht antwortet, hängt auch Gemini.
- sämtliche Variablen dort sollten eigentlich als static deklariert werden, um zu vermeiden daß sie mit der Applikation kollidieren.
- in der lokalen search_cookie (https://github.com/th-otto/gemini2/blob/371e227c511e588c13491679907691ea185ab402/exec_job/exec_job.c#L77) Funktion ist ein Fehler der zum crash führen dürfte, wenn kein cookiejar vorhanden ist.
-
Okay, also doch noch ein Wunsch an die Hatari-Emulation, das GEMDOS-Layer optional mit "egal was an Fscreate reinkommt, mach Großbuchstaben" draus zu betreiben ;)
Ähm, ist das nicht das Szenario, wofür...
--gemdos-case <x>
Specify whether new dir/filenames are forced to be in upper or lower case with GEMDOS HD emulation. Off/upper/lower, off by default
... da ist?
Da guck, danke. (Ich habe das Problem nicht, daher nie zu lösen versucht).
-
@reschke: kann es sein, daß dort noch Ersatzroutinen für malloc() etc. fehlen? Zumindest in der gemini version 1.a (die wohl letzte offiziell verfügbare) wird in AddApplRule, wo malloc() im Source steht, die folgende routine aufgerufen:
[0001045c] 4eb9 0005 913e jsr malloc
malloc:
[0005913e] 2079 0006 b648 movea.l $0006B648,a0
[00059144] 4eb9 0005 8c1e jsr umalloc
[0005914a] 4e75 rts
umalloc:
[00058c1e] 6100 fd66 bsr mymalloc
[00058c22] 4e75 rts
Das sieht mir überhaupt nicht nach der malloc() Routine aus pcstdlib aus.
Edit: args, vergiss es. Ist ja da, in myalloc.
-
FWIW:
ich habe diese Sourcen seit 30 Jahren nicht angesehen, und das Meiste ist ja nicht von mir :-)
-
Schon klar ;)
Ich hoffe es stört dich trotzdem nicht, wenn ich Fragen stelle, sollten noch welche auftauchen. Wenn du sie nicht beantworten kannst, dann ist das halt so.
-
Falls es interessiert: ich habe jetzt in meinem repo auch scripts hinzugefügt, die automatisch auf github die binaries erzeugen.
Verwendet habe ich dazu crosstos (https://github.com/th-otto/crosstos) und pcmake (https://github.com/th-otto/pcmake). Ausserdem benutzt es die originalen Pure-C Header und libraries (portab.h ist u.A. jetzt auch dort zu finden).
Crosstos ist nicht ursprünglich von mir, aber ich habe ein paar Änderungen vorgenommen, um Parameter per ARGV zu unterstützen (wird definitiv für pclink benötig, weil die Kommandozeile dort in der Regel die 126 Zeichen überschreitet). crosstos benutzt den Musashi 68000 emulator, und erzeugt binaries die die ursprünglichen Atari programme (pcc.ttp, plink.ttp) etc. eingebaut haben. Ausserdem emuliert er teilweise gemdos calls (nicht perfekt, aber zum Aufruf der Kommandozeilen-Version reicht es).
pcmake is ein utility daß ich vor einiger Zeit geschrieben habe, daß einfach ein Pure-C Project-File parsed und compiler, assembler, und linker mit den entsprechenden Option aufruft.
Jetzt muss ich nur noch rausfinden, warum m68k-atari-tos-pc-pcc.tpp beim übersetzen von mupfel.c hängt. Seltsamerweise funktioniert es, wenn ich es erst mit cpp.ttp behandel, und dann das mit pcc übersetze. Das passiert auch nur mit den crosstos-binaries. Direkt auf einem Atari ausgeführt (auch mit einem Emulator) funktioniert es.