Anfänger: DOS-Programm auf den Classic portieren

amiga-news.de Forum > Programmierung > Anfänger: DOS-Programm auf den Classic portieren

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

20.07.2011, 10:45 Uhr

Dr_Chaotica
Posts: 244
Nutzer

Hallo Leute!

So, ich bin ein Anfänger, was Programmierung betrifft.
Meine Frage: Ich habe ein DOS-Programm und seine C-Sources. Wie muss man vorgehen, um das auf den Amiga (OS 3.9) zu portieren?
Was braucht man außer einem C-Compiler noch?
Und welche Teile der Sources müssen ersetzt werden?

Ich weiß, bzw. kann mir denken, dass die Fragen etwas naiv klingen. Ich möchte mich aber Stück für Stück mit dem Thema Portierung vertraut machen. Bin also für Ratschläge aller Art dankbar.

Gruß und vielen Dank!
DC

[ - Antworten - Zitieren - Direktlink - ]

20.07.2011, 11:08 Uhr

thomas
Posts: 7717
Nutzer

Die Fragen sind nicht naiv, es sind genau die Fragen, die nur du beantworten kannst, denn nur du weißt, um welches DOS-Programm es sich handelt.

Die einfachste (und naivste) Herangehensweise ist, das Programm einfach so durch den Compiler zu jagen. Wenn es wirklich reines ANSI-C ist, ohne spezielle Funktionen von MS-DOS zu benutzen, dann sollte es das gewesen sein.

Wenn der Compiler Fehlermeldungen ausspuckt, musst du herausfinden, woran die liegen und was fehlt, damit die Fehler nicht mehr kommen.

Am schierigsten sind logische Fehler zu finden, die der Compiler nicht erkennt, wie z.B. Endianness.

Neuschreiben musst du üblicherweise alle Teile, die mit einer GUI zu tun haben.

Kleiner Tipp: als Anfänger sollte man nicht versuchen, andere Programme zu portieren, sondern lieber eigene Programme zu schreiben. Um einen vernünftigen Port zu erstellen, muss man sich mit der Quellplattform, der Zielplattform und der Programmiersprache gut auskennen.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

20.07.2011, 16:31 Uhr

Thore
Posts: 2266
Nutzer

Hi

Ergänzend zu Thomas, alles was OS spezifische API benutzt, muss umgeschrieben werden (Ausnahmen sind plattformübergreifende APIs wie z.B. SDL)
Ebenfalls umgeschrieben werden müssen Hardware-Hacks, also Code der direkt Hardware anspricht, ohne auf einen HAL zuzugreifen. (Bei DOS z.B. Interrupts oder Textausgabe per Direktaddressierung, bei Amiga z.B. Customchip-Zugriffe)
Dafür müssen sogar manchmal ganze Codeblöcke oder Funktionen neugeschrieben werden, um das gleiche Resultat zu bekommen.

Grundlegend gilt aber das was Thomas schon angesprochen hat, einfach mal compilieren und dann schrittweise die Fehler korrigieren.

[ - Antworten - Zitieren - Direktlink - ]

21.07.2011, 11:11 Uhr

Dr_Chaotica
Posts: 244
Nutzer

Hallo!

Danke für die Antworten!

Aaaalos, das DOS-Programm ist ein Nodebuilder zum Erstellen von Blockmaps für Levels eines Spiels. Der Sourcecode ist, wie der Autor schreibt, frei verwendbar.
An sich ist das Programm recht unscheinbar. Es hat keine GUI, verlangt ein File, manipuliert dieses und speichert es dann wieder.

Mit vbcc habe ich einen Fehler erhalten und zwar:
"unexpected identifier <M_PI>"
Es scheint sich wohl um die Zahl Pi zu handeln, wenn ich das richtig verstehe. Weiß jemand, was man stattdessen für vbcc angeben muss?

Tja, mein Hauptproblem ist aber vbcc selbst. Obwohl ich es per Install-Script auf den Rechner gespielt habe, crasht es ziemlich gerne, und zwar meistens dann, wenn es auf eine Datei zugreifen will, die es zuvor in t: abgelegt hat. Hat jemand eine Idee?

Und dann bekam ich ein File a.out heraus, das aber kein Executable ist. Frage: Weiß jemand, wo man eine Anleitung für vbcc für Anfänger herbekommt?

Vielen Dank und schönen Donnerstag!
DC

[ - Antworten - Zitieren - Direktlink - ]

21.07.2011, 12:30 Uhr

Thore
Posts: 2266
Nutzer

Im Grunde reicht es, math.h einzubinden. Klappt das nicht, verwende den Define:

#define M_PI 3.14159265358979323846

a.out ist sicher ein executable. Setz mal das Protection Flag für "Executable", und schau obs dann geht.

[ Dieser Beitrag wurde von Thore am 21.07.2011 um 12:31 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

21.07.2011, 12:49 Uhr

thomas
Posts: 7717
Nutzer

Zitat:
Original von Dr_Chaotica:
Mit vbcc habe ich einen Fehler erhalten und zwar:
"unexpected identifier <M_PI>"
Es scheint sich wohl um die Zahl Pi zu handeln, wenn ich das richtig verstehe. Weiß jemand, was man stattdessen für vbcc angeben muss?

In den Include-Files von VBCC fehlt diese Konstante. Bei anderen Compilern ist sie vorhanden. Am besten du definierst sie so:

#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif

Dann funktioniert es mit allen Compilern.

Zitat:
Tja, mein Hauptproblem ist aber vbcc selbst. Obwohl ich es per Install-Script auf den Rechner gespielt habe, crasht es ziemlich gerne

Beim Programmieren braucht man immer einen großen Stack. Mindestens 30000, besster 40000 oder 80000.

Bei mir ist stack 40000 immer die erste Anweisung in S:Shell-Startup.

Zitat:
Weiß jemand, wo man eine Anleitung für vbcc für Anfänger herbekommt?

Die Anleitung zu VBCC ist im Docs-Verzeichnis der Installation oder auf http://sun.hasenbraten.de/vbcc/

Das ist allerdings nur eine sachliche Beschreibung der Funktion von VBCC. Eine Einführung in die Programmiersprache C oder den Umgang mit Compilern im Allgemeinen wirst du dort nicht finden.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

22.07.2011, 11:22 Uhr

Polluks
Posts: 105
Nutzer

Der Vollständigkeit halber:
"The constant M_PI is not part of the ANSI/ISO C standard library (it comes from the BSD version of Unix)."
Also kein vbcc-Fehler ...

--
Pegasos II G4, MorphOS 2.7
Power Mac G3, OSX 10.3

[ - Antworten - Zitieren - Direktlink - ]

26.07.2011, 10:30 Uhr

Dr_Chaotica
Posts: 244
Nutzer

Hallo!

Vielen Dank an alle Hilfsbereiten!

Die Meldung von vbcc wegen PI ist somit beseitigt.

Mittlerweile habe ich noch ein bisschen rumprobiert, komme aber nicht weiter.
Der Sourcecode an sich ist nicht problematisch, weil das Programm selbst nicht auf Hardware zugreift, keine GUI hat und nur ein File verändert.
Mein Hauptproblem ist vbcc selbst.
Ich habe die Binaries für OS3 und die Target-Icludes für OS3 installiert.

Nun crasht der Befehl vc immer dann, wenn ein bestimmtes File (eine .asm-Datei) aus t: ausgelesen werden soll. Offenbar liegt es daran, dass vc oder vbccm68k auf ein Verzeichnis "t: statt t: zugreifen will, was wohl an einem Platzhalter %s in der Config-Datei liegt. Weiß jemand, was ich da eintragen soll, damit vc keine Anführungszeichen setzt oder erwartet?

Und dann noch dies: Wenn ich die Befehle von Hand eingebe, bekomme ich zuerst eine .asm-Datei, danach eine .o-Datei und letztere müsste dann mit vlink zum Executable werden. Da bringt vlink aber haufenweise Fehlermeldungen namens "unexpected reference" (bin mir nicht mehr ganz sicher, wie der genaue Wortlaut ist). Was bedeutet dies?

Danke nochmals und schönen Dienstag!
DC

[ - Antworten - Zitieren - Direktlink - ]

26.07.2011, 11:21 Uhr

jolo
Posts: 110
Nutzer

@Dr_Chaotica:

Zitat:
Mittlerweile habe ich noch ein bisschen rumprobiert, komme aber nicht weiter.
Der Sourcecode an sich ist nicht problematisch, weil das Programm selbst nicht auf Hardware zugreift, keine GUI hat und nur ein File verändert.

Wenn es ein MS-DOS-Programm ist, ist es problematisch (unter DOS verstehe ich ein MS-DOS Programm). MS-DOS ist so ziemlich das Inkompatibelste was man heutzutage zum schnellen Portieren vorfinden kann. MS-DOS Aufrufe muss man auf die C-Std-Lib ummünzen, evtl. musst Du auch noch auf die POSIX-API zurückgreifen. Beides ist möglich aber nur mit Aufwand verbunden.

Zitat:
Mein Hauptproblem ist vbcc selbst.
Ich habe die Binaries für OS3 und die Target-Icludes für OS3 installiert.

Nun crasht der Befehl vc immer dann, wenn ein bestimmtes File (eine .asm-Datei) aus t: ausgelesen werden soll. Offenbar liegt es daran, dass vc oder vbccm68k auf ein Verzeichnis "t: statt t: zugreifen will, was wohl an einem Platzhalter %s in der Config-Datei liegt. Weiß jemand, was ich da eintragen soll, damit vc keine Anführungszeichen setzt oder erwartet?

Welche Version von 'vbcc' benutzt Du? Aktuell ist die Version 0.9b (19.05.2011), die aber noch nicht auf Frank seiner Homepage zu finden ist. Leider ist die Version 0.9a, die auf der Homepage von Frank bereitgestellt wird, nicht zu empfehlen, da diese etliche Fehler beinhaltet, die aber erst beim Ausführen der Datei zum Tragen kommen, also nicht beim Kompilierungslauf (mit zwei Ausnahmen).
Einfach Frank eine E-Mail zukommen lassen und um die aktuelle Version bitten. Alternativ könnte ich auch ein Archiv mit den neuen OS3 Binaries/Configs bereitstellen; muss aber dafür erst einmal Franks OK haben, da Frank schon an dem neuem Release arbeitet.

Zitat:
Und dann noch dies: Wenn ich die Befehle von Hand eingebe, bekomme ich zuerst eine .asm-Datei, danach eine .o-Datei und letztere müsste dann mit vlink zum Executable werden. Da bringt vlink aber haufenweise Fehlermeldungen namens "unexpected reference" (bin mir nicht mehr ganz sicher, wie der genaue Wortlaut ist). Was bedeutet dies?

vc +aos68k -c99 test.c -o ram:test -lvc

Dieser Aufruf muss eine ausführbare Datei in der RAM-Disk erstellen, keine ".asm" oder ".o" Datei. Wenn ein interner Compiler/Assembler Fehler auftritt, so wie bei alten 0.7x/0.8x Versionen von 'vbcc', so bleiben die *Leichen*, sprich, die temporären ".asm" oder ".o" Dateien übrig...

Poste mal bitte die Fehlercodes.

--
Stupid mistakes are always made by others -
we only make unavoidable errors

[ - Antworten - Zitieren - Direktlink - ]

26.07.2011, 11:23 Uhr

thomas
Posts: 7717
Nutzer

@Dr_Chaotica:

Du solltest an der Config nichts ändern! Schon gar nicht als Einsteiger. Der Compiler ist so wie er installiert wird vollkommen korrekt. Wenn bei dir Fehler auftreten, dann liegt es an etwas, das du machst, nicht am Compiler.

Das einzige Kommando, das du brauchst, um den Compiter aufzurufen, ist das Frontend vc. Alles andere passiert automatisch. Von einer asm-Datei solltest du nichts sehen oder mitbekommen.

vc programm.c -o programm

oder

vc -c teil1.c -o teil1.o

vc -c teil2.c -o teil2.o

vc teil1.o teil2.o -o programm

Hast du denn wie ich gesagt habe den Stack vergrößert?

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

28.07.2011, 17:19 Uhr

Dr_Chaotica
Posts: 244
Nutzer

Mal wieder herzlichen Dank für alle Antworten!

Stack:
Ja, hatte ich gleich als Erstes in Verdacht und erhöht. Ergab keine Verbesserung.

Fehlercode:
Mit der Zeile
vc +aos68k -c99 source.c -o source -lcv
Komme ich ohne Fehlermeldung bis zum Aufruf von vlink. Das meldet dann mehrfach:
Error 21: Reference to unkbown identifier...
... mit verschiedenen Zusätzen, die aber, wenn ich richtig sehe, alle Definitionen aus math.h sind, also z.B. __atan2 und __sqrt

Gruß
DC

[ - Antworten - Zitieren - Direktlink - ]

28.07.2011, 17:42 Uhr

Holger
Posts: 8116
Nutzer

@Dr_Chaotica:
Halte Dich lieber an das von thomas geschriebene:

vc programm.c -o programm

Wenn Du es brauchst, dann gib -c99 an und in Hinblick auf die Fehlermeldung wäre -lm zu empfehlen. Aber den Rest, den solltest Du nicht brauchen, sonst wäre das ein Zeichen für eine fehlerhafte Compiler-Installation (und das sollte man immer als erstes beheben).

Also:
vc -c99 programm.c -lm -o programm
sollte es eigentlich tun.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

28.07.2011, 18:11 Uhr

Thore
Posts: 2266
Nutzer

Das ist mal eine Fehlermeldung womit man was anfangen kann.
Die Funktionen die in math.h beschrieben werden, müssen noch mit angelinkt werden.
In der math.h stehen nur die "Beschreibungen/Schablonen" der Funktionen, die sogenannten Header. Durch die Parameter "-lxxx" kann man Bibliotheken (libs, daher l) mit anlinken, die die gewünschten Finktionen beinhalten.
Ich weiß nicht ob m (Parameter -lm) deine Funktionen bereits alle drin hat. Kannst demoweise auch mal als Parameter -lmath verwenden. -lmieee wäre auch noch im Hinterkopf zu haben.

[ - Antworten - Zitieren - Direktlink - ]

28.07.2011, 18:11 Uhr

thomas
Posts: 7717
Nutzer

Eine einfache m.lib gibt es bei VBCC leider nicht. Man muss sich schon entscheiden, ob man direkt die FPU ansprechen möchte mit -lm331 oder -lm040 oder ob man die mathieee Libraries benutzen möchte mit -lmieee. Ich empfehle letzteres.

Die vc.lib ist die Standard C library von VBCC. Sie wird immer dazugelinkt, wenn man nicht -nostdlib angibt. Das -lvc dürfte also nicht schaden, aber auch keinen zusätzlichen Nutzen bringen (da es ohnehin default ist).

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

30.07.2011, 10:40 Uhr

Dr_Chaotica
Posts: 244
Nutzer

So, da ist der Anfänger wieder.

Der Aufruf...

vc -c99 -source.c -mlieee -o prgram

...hat nun endlich ein lauffähiges Programm hervorgebracht.
Aber nun ergibt sich ein neues Problem: Das Programm liest ja ein Datenfile ein. Das funktioniert auch einwandfrei. Nur wird am Anfang des Vorgangs ein long int Wert aus dem Header des Datenfiles ausgelesen. Das klappt auch, aber der Wert, den das Programm ausliest, ist 16777216mal höher, als er sein sollte.
(Blöderweise läuft das Programm dann nicht weiter durch, weil es wegen dieses viel zu hohen Wertes versucht, irrsinnige Mengen an Speicher anzufordern.)
Woran könnte das liegen? Am Kompilieren? Der Code sieht nicht falsch aus und läuft ja auch auf MS-DOS mit den tatsächlichen Werten des Datafiles.
(Andere Amiga-Programme, die solche Datenfiles einlesen, geben die Werte natürlich auch richtig an.)

Vielen Dank nochmals für Eure Unterstützung!!!

Gruß und schönes Wochenende!
DC

[ - Antworten - Zitieren - Direktlink - ]

30.07.2011, 11:14 Uhr

Thore
Posts: 2266
Nutzer

> Woran könnte das liegen? Am Kompilieren? Der Code sieht nicht falsch aus und läuft ja auch auf MS-DOS mit den tatsächlichen Werten des Datafiles.

Könnte das bekannte LE/BE Problem sein.
Lass dir die Werte mal als HEX Zahl ausgeben.
Steht in der Datei 0xABCD und er zeigt 0xCDAB an, dann ist entweder ein Swap eingebaut (für Intel) oder die Datei ist bereits auf LE. Der Amiga verwendet BE Codierung (Big Endian, logisch "richtigrum") während Intel und AMD auf LE Codierung (Little Endian, logisch "verdrehte Bytes") setzen.
Falls ein swap im Code drin ist, musst du dieses rausnehmen. Fehlt eins, ist dieses zu ergänzen. Falls genau das das Problem sein sollte.

[ - Antworten - Zitieren - Direktlink - ]

30.07.2011, 16:01 Uhr

Dr_Chaotica
Posts: 244
Nutzer

Hallo Thore!

Japp, das scheint der Grund zu sein.
Die Datafiles haben die Bytes verdreht, d.h. Dezimal-11 steht da als 0b000000 drin.
Im Sourcecode kann ich nichts erkennen, was nach einem Swap aussieht. Der wäre ja auch nicht nötig für MS-DOS.
Blöde Frage kommt jetzt natürlich wieder: Wie schreibt man so einen Swap? Theoretisch müsste der alle Zahlenwerte im Datafile erfassen.

Danke und Gruß
DC

[ - Antworten - Zitieren - Direktlink - ]

30.07.2011, 16:51 Uhr

Thore
Posts: 2266
Nutzer

MS-DOS hats eben gerade nötig. Womöglich ist aber bereits der Datenbestand auf LE optimiert, so daß das DOS Programm die Werte nur noch einlesen muss?

Ein Swap ist recht einfach implementiert.
Ich hab Dir kurz ein Demoprogramm geschrieben mit einem 16bit und einem 32bit Swap:

#include <stdio.h>

int swap16(int var)
{
return ((var & 0xFF) << 8 ) | ((var & 0xFF00) >> 8 );
}

int swap32(int var)
{
return ((var & 0xFF) << 24) | ((var & 0xFF00) << 8 ) | ((var & 0xFF0000) >> 8 ) | ((var & 0xFF000000) >> 24);
}

main()
{
int A = 0xABCD;
int B = 0xABCDEF11;
int C=0, D=0;

printf("%4xn", A);
printf("%8xn", B);

C = swap16(A);
D = swap32(B);

printf("%xn", C);
printf("%xn", D);
}

[ Dieser Beitrag wurde von Thore am 30.07.2011 um 16:51 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

30.07.2011, 16:59 Uhr

Dr_Chaotica
Posts: 244
Nutzer

Danke Thore!!!

Und dieser Code tauscht alle Zahlenwerte, also alles, was mit "int" bezeichnet wird?

DC

[ - Antworten - Zitieren - Direktlink - ]

30.07.2011, 17:20 Uhr

Thore
Posts: 2266
Nutzer

Die Unterfunktionen swappen das was sie als Eingang bekommen und liefern das geswappte zurück. Eigentlich hätt ich bei swap16 "word" und bei swap32 "long" verwenden sollen. Da "int" kompatibel ist (=32 Bit Wert auf Amiga und MS-DOS) gehts auch.

swap16 und swap32 machen entweder ein 16bit swap (0xABCD -> 0xCDAB) oder ein 32bit swap (0xABCDEF11 -> 0x11EFCDAB).
Ich denk 16bit Swap wird deine Lösung sein.

[ Dieser Beitrag wurde von Thore am 30.07.2011 um 17:22 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

01.08.2011, 09:27 Uhr

Mda
Posts: 90
Nutzer

> Das klappt auch, aber der Wert, den das Programm ausliest, ist
> 16777216mal höher, als er sein sollte.

> Ich denk 16bit Swap wird deine Lösung sein.

Sieht eher nach 32-Bit-Swap aus.

[ - Antworten - Zitieren - Direktlink - ]

01.08.2011, 13:15 Uhr

Thore
Posts: 2266
Nutzer

@mda
Leider kenn ich den Source nicht. Könnt auch sein daß Byteweise auslesen die Lösung ist

Aber Du hast natürlich recht, werden Long ausgelesen, dann müsste es ein swap32 sein.

[ - Antworten - Zitieren - Direktlink - ]

01.08.2011, 18:31 Uhr

Holger
Posts: 8116
Nutzer

Routinen zum Lesen und Schreiben von Dateiformaten bezügl. der Endianess zu fixen, setzt schon sehr viel Detailwissen zum Dateiformat und der Routinen voraus. Das wird alles andere als eine schnelle Portierung.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

01.08.2011, 19:53 Uhr

Thore
Posts: 2266
Nutzer

@Dr_Chaotica:
Kannst Du den Ausschnitt des Dateiauslesens mal posten? Könnte irgendwas mit fopen und fread sein. Mich würde mal interessieren wie das bewerkstelligt ist.
Manchmal reicht ein swap beim Lesen und ein swap beim Schreiben, aber manchmal trifft man auf Probleme wie Holger sie beschreibt.
Ein Blick in die Sourcen wäre hier sicher hilfreich.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Anfänger: DOS-Programm auf den Classic portieren

[ - Suche - Neue Beiträge - Registrieren - Login - ]