Hallo Besucher, der Thread wurde 4,6k mal aufgerufen und enthält 26 Antworten

letzter Beitrag von cbmhardware am

Borland Turbo C 2.0

    ja, djgpp programme werden immer irgendwie sehr gross, hängt wohl auch mit diesem dpmi extender zusammen.


    wenn es wirklich klein und gemein werden soll kann man mit turbo-c 2.0 echt gute ergebnisse erzielen - allerdings sollte man wissen was man tut, der compiler ansich hat ein paar macken :)

    Zitat

    Original von sauhund
    wenn es wirklich klein und gemein werden soll kann man mit turbo-c 2.0 echt gute ergebnisse erzielen - allerdings sollte man wissen was man tut, der compiler ansich hat ein paar macken :)


    Ich habe mit dem 3.1 gearbeitet und auch einige Macken feststellen dürfen. Unter anderem:
    [list=1]
    [*]Der Optimierer erzeugt nicht selten fehlerhaften Code.
    [*]Man sollte nicht die 386-Code-Generierung einschalten, wenn man auch eine Interrupt-Routine benutzt. Der Compiler rettet nämlich nur die unteren 16 Bits. Daraufhin wundert man sich dann über unerklärliches und nur sehr schwer reproduzierbares Verhalten. Been there, done that - und zwar bei einem Projekt, wo es auch noch um vom Programm verwaltete Banknoten ging. Dieses Szenario bringe ich gerne als Beispiel wenn ich mal wieder gefragt werde, wieso man heutzutage noch Assembler können sollte. Die meisten unserer Studenten hätten das Problem nie lösen können. Mit einem Studenten habe ich mal einen Vormittag debugged bis wir einen ähnlichen Fehler in einem Linux-Kernel-Modul gefunden haben...
    [*]Unzählige Fehler sind mir auch noch in Turbo Vision im Kopf, auch wenn ich mich nicht an weitee Details erinnern kann.
    [/list=1]
    Gruß,
    - Spior.

    So richtig portable ist C aber nicht ?




    Das laeuft problemlos mit TC 2.0. Ich wollte dieses oder etwas aehnliches mit djgpp verwenden. Bin in tiefes Brueten verfallen und es klappt dennoch nicht.
    Der Compiler kennt scheinbar kein "far" und langsam gehen mir die Ideen aus.


    Wie koennte man ?


    Michael

    Versuchs lieber mit richtigem 32bit-Code, dann brauchst du solche Krücken nicht... :)


    'near'-Pointer sind nur innerhalb eines Segments brauchbar (die aktuellen 64KB) und 16 bit breit, "far"-Pointer dagegen sind 32 bit breit und können so den gesamten Arbeitsspeicher ansprechen.


    Die Funktionen in der dos.h sind natürlich auch nicht portabel. Aber ich denke das ist klar.

    Ja, dos.h war klar. Darf aber auch C++ werden. Solange der djgpp das compilieren kann, bin ich nicht unzufrieden.


    32bit-Code: Wie koennte soetwas konkret als Source aussehen ?


    Ich koennte das in Pascal oder auch in ASM machen. Eigentlich koennte man auch seine Assembler-Kenntnisse vertiefen. Duerfte wesentlich weniger Zeit in Anspruch nehmen, als die ganzen Haken und Oesen dieses C-Hippie-Wildwuchses zu finden. Das erlebt man imo nicht. :|



    Michael