So ist es - eigentlich funktioniert das alles ganz automatisch.
Hat jemand schon "zlib" für eigene DOS-Programme (bspw. mit Turbo C bzw. C++) genutzt ?
-
-
Alles anzeigen
Zur Ergänzung: der beigefügte Code läuft im LARGE Modell ohne Probleme (mit Turbo-C 2.01).
Was FP_SEG und FP_OFF in Deiner Version genau machen, kannst Du ja in der zugehörigen Headerdatei nachsehen.
Beim SMALL Modell müsste FP_SEG eigentlich auf DS=CS gesetzt werden, bei meinem TC ist da keine Fallunterscheidung für verschiedene Speichermodelle.
Für die malloc() Funktionen müsstest Du auch die <stdlib.h> einbinden, damit die Parameter und die Rückgabewerte bekannt sind.
Hallo Martin Hepperle - Danke für den Wink mit dem Zaunpfahl (damit meine ich die stdlib.h).
Das alleine hat den Unterschied gemacht, bei ungeändertem Rest meines Codes war das Hinzufügen der stdlib.h die Lösung.
Mir ist aber nicht klar, warum die Definitionen in stdlib.h den Compiler dazu bringen, hier ganz anderen Code zu generieren.
Werden da mit Einbinden der stdlib.h Standarddefinitionen oder Standardeinstellungen verändert, die es auch ohne stdlib.h bereits gibt, aber anders aussehen/deklariert sind ?
-
Wenn kein Protoyp vorhanden ist, nimmt C ja an, dass eine Funktion einen int (hier auf MS-DOS/Intel 16 bit) zurückliefert.
Wenn dann aber etwas anderes (z. B. ein far * beim LARGE Modell) zurückgeliefert wird, wird auf int abgeschnitten, d.h. es geht ein Teil davon verloren und es bleiben nur 16 bit übrig. Das war bei Dir der Fall.
Deshalb ist es immer wichtig alle Funktionen sauber vorab mit Prototypen zu deklarieren bzw. die Header-Dateien einzubinden.
Bei TC kann man ja schnell mit CTRL+F1 sehen, wie der Protoyp aussieht und welche Header-Datei ihn enthält.
Wenn eine Funktion in der gleichen Quellcodedatei steht, ist das prinzipiell nicht nötig, aber guter Stil, auch dafür oben Prototypen zu deklarieren. Dann kann man später auch leicher Funktionen auslagern und entsprechende Header-Dateien erstellen.
[Bei Pascal gibt es etwas ähnliches mit den Forward Deklartionen.]
-
"moderne" C Compiler meckern bei fehlenden Prototypen, aber damals[tm] war das noch nicht so.
Ich schalte immer die höchste Warnstufe an und am Ende muss sich der Source ohne Warnung übersetzen lassen.
-
Mit TC habe ich meistens nur kleinere Progrämmchen geschrieben. Ich hatte es mir gekauft, da es sehr preiswert war und erstmals (für mich) eine IDE hatte.
Ansonsten habe ich hauptsächlich Microsoft C ab Version 4 und dann hauptsächlich 5.1 benutzt. Nicht weil das so viel besser war (keine IDE, erst später mit Version 6), sondern weil das der Standardcompiler für Windows und OS/2 war. Außerdem passte das gut zu MS-FORTRAN 5.1 für gemischtsprachige Programme.
Nachdem mich die verschiedenen Grafikkarten und Drucker bei DOS genervt hatten habe ich recht schnell mit Windows angefangen, dort musste ich nicht immer neue Treiber schreiben.
Mein größtes C Programm unter WIndows 2 besteht aus ca. 85 Quellcodedateien mit etwa 1.2 MB Quellcode.
Unter Windows 2000/XP habe ich dann mal ein etwas größeres Rechenprogramm von UNIX portiert, das hatte 1350 Dateien und knapp 40 MB Quellen. Das dann aber schon mit den passenden Visual Studio.
Große Programme unter MS-DOS hatte ich damals in FORTRAN geschrieben, da ich das auch auf Großrechnern und UNIX genutzt habe. Da musste ich das HUGE Speichermodell verwenden, da große Felder vorkamen. Speicherprobleme wurden damals über temporäre Dateien umgangen - z.B. große Gleichungssysteme, die nicht in den 640 KB Speicher passten, iterativ lösen (die arme Festplatte).
Ich denke, es sollte kein Problem sein, große MS-DOS Programme mit TC zu schreiben. Muss man nur als Projekt (Makefile) aufsetzten und schön in Module aufteilen.
