Speicherreservierung mit farmalloc unter Boralnd C++ 3.1



  • Kletiz

    Ich möchte die Möglichkeit haben Speicher von mehr als einem MB
    zu reserviren, musste aber feststellen das malloc unter dos dazu anscheinend
    nicht in der lage ist, und wollte deswegen auf famalloc ausweichen.
    Seltsamerweise kann ich mit farmalloc nicht mehr als 31KB an Speicher reservieren.

    Ich mache das so:

    #include <alloc.h>

    char far string;
    string=(char far
    )farmalloc(1024*100);
    if(!string) return 1;
    else return 0;

    stimmt mit dem oberen code was nicht? hab ich was vergessen?
    ich habe das programm schon im small, large und huge modus compiliert, immer mit dem gleichen Ergebniss.



  • Dieser Thread wurde von Moderator/in junix aus dem Forum Borland C++ Builder (VCL/CLX) in das Forum Andere Compiler verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Da muss ich dich leider enttäuschen. Du kennst den Spruch "640KB ought to be enough for anybody", der Bill Gates zugeschrieben wird? Genau nach der Maxime arbeitet MS-DOS. Der Prozessor befindet sich unter DOS in einem Emulationsmodus für die uralten 8086/8088-Prozessoren, die damals in den ersten IBM-PCs zum Einsatz kamen. Die Architektur lies damals nicht mehr als 1MB Speicher zu. Als die PCs besser wurden, ist DOS leider nicht wirklich mitgewachsen und wurde ungefähr durch Windows95 endgültig und viel zu spät abgelöst.
    Die einzige Hoffnung ist also, diese Barriere irgendwie zu umgehen und auf malloc zu verzichten. MS-DOS hat glaub ich ab Version 5.0 die HIMEM.SYS mitgeliefert, die den sog. Extended Memory verwaltet hat (XMS). Wenn du dich da reinfuchst, kannst du so vielleicht etwas mehr Speicher locker machen. Ich würd natürlich einfach sagen, dass es sich wahrscheinlich nicht lohnt, da DOS mittlerweile schon etwas streng riecht und es wohl auch kaum mehr Programmierer kennen, die sich damit auskennen bzw. sogar das heute noch praktizieren.

    farmalloc hat übrigens nur den Sinn, dass du in einem der kleinen Speichermodelle (Tiny, Small, Medium (oder Compact, vergessen)) Speicher ausserhalb deines 64KB-Heaps bekommen kannst. In den großen Modellen wie Large und Huge ist farmalloc mit malloc (weitgehend?) identisch.



  • Aha, das mit den maximal 1MB arbeitsspeicher hab ich schon mal gehört, hab aber
    das mit diesem Probleme verbinden koennen.

    Zu den 640KB, die wären schon mal nicht schlecht, weil im moment bekomm ich von malloc und farmalloc nur maximal 31KB, hast du da vielleicht einent tip?

    und noch mal zu farmalloc, ein Auszug aus Befehlsdoku der Borland C++ 3.1 IDE

    ###############################################################################
    ▄▄▄▄▄▄▄▄▄▄▄
    ▌farmalloc▐ <ALLOC.H>
    ▀▀▀▀▀▀▀▀▀▀▀
    Reserviert Speicher auf dem far-Heap

    Definition: void far *farmalloc(unsigned long nbytes);

    Hinweis:
    farmalloc reserviert einen Speicherblock der Länge nbytes auf dem far-Heap

    Merke: Für die Reservierung auf dem far-Heap:
    ■ kann das gesamte, verfügbare RAM verwendet werden
    ■ können Blöcke größer als 64K verwendet werden
    ■ werden Zeiger des Typs far (oder des Typs huge,
    bei Blöcken größer als 64K) für den Zugriff auf
    die reservierten Blöcke verwendet.

    In den Speichermodellen Compact, Large und Huge ist farmalloc ähnlich wie
    malloc, aber nicht gleich. Es verarbeitet Parameter des Typs unsigned long,
    während malloc Parameter des Typs unsigned verarbeitet.

    In einem Programm mit dem Speichermodell Tiny kann farmalloc nicht verwendet
    werden.

    Rückgabewert:
    ■ bei fehlerfreier Ausführung: ein Zeiger auf den neu reservierten
    Block
    ■ im Fehlerfall: (wenn für den neuen Block nicht genügend
    Speicher vorhanden ist), 0.

    ###############################################################################

    also meiner Meinung nach, sollte man mit farmalloc wenn ich die Leuten von Borland verstanden habe, mehr als 1MB reserviren koennen. (ausser natürlich
    sie meinen mit "kann das gesamte, verfügbare RAM verwendet werden", das nur der Teil des rams verwendet werden kann welchen auch dos verwaltet)



  • mm-motm schrieb:

    Zu den 640KB, die wären schon mal nicht schlecht, weil im moment bekomm ich von malloc und farmalloc nur maximal 31KB, hast du da vielleicht einent tip?

    Es gibt da noch ein weiteres Problem, das damit zusammenhängt, dass DOS ein 16bit-OS ist (bzw. dass der 8088 ein 16bit-Prozessor ist). Zusammenhängende Speicherblöcke(Arrays z.B.) können höchstens 64 KB gross sein, es sei denn man arbeitet im Huge-Modell. Warum du nur 31KB bekommst, weiß ich nicht, aber wie siehts denn mit Huge aus? BTW zur Not gibts noch eine Funktion, die direkt aufs DOS geht ... dos_alloc oder so, guck mal nach (alloc.h oder dos.h) Die alloziert nicht vom Heap, sondern fragt direkt das Betriebssystem nach einem Block. Da könnte man dann einen huge-Pointer drauf setzen (auch in den anderen Speichermodellen).
    Aber gewöhn dich dran, dass du, insbesondere wenn die IDE im Hintergrund läuft, nicht allzuviel freien Speicher haben wirst.

    also meiner Meinung nach, sollte man mit farmalloc wenn ich die Leuten von Borland verstanden habe, mehr als 1MB reserviren koennen. (ausser natürlich
    sie meinen mit "kann das gesamte, verfügbare RAM verwendet werden", das nur der Teil des rams verwendet werden kann welchen auch dos verwaltet)

    Doch, meinen sie. Das hat zunächst einmal weniger mit DOS an sich zu tun, sondern mit dem sog. Real Mode des Prozessors (der Emulationsmodus für 8088/8086-Kompatibilität), der ohne weiteres überhaupt nicht zulässt, mehr Speicher als 1 MB anzusprechen. Wieviel davon dann konkret verfügbar sind, ist nochmal eine andere Frage.



  • hi,
    das problem kommt mir bekannt vor 😞
    du kannst mal farcoreleft() aufrufen. das zeigt dir an, wieviel speicher du maximal bekommen kannst. wenn du unter dos mehr speicher brauchst, gibt es nur noch die moeglichkeit ueber extended memory (xms) oder expanded memory (ems) an speicher zu kommen. das ist alles sehr aufwendig.
    mir ist zudem aufgefallen, wenn ich mehr als 64kb speicher anfordere, das die adressierung manchmal nicht richtig hinhaut. ich vermute da einen fehler im bc.
    soll es also eine reine dos anwendung werden, die auch direkt unter ms-dos laeuft, ist stress angesagt.

    wenn du statt bc den vc nimmst und eine consolenanwendung schreibst, klappt alles wunderbar. es ist dann eine 32bit anwendung die auch entsprechend mehr speicher nutzen kann (keine limits bezgl real, ems, xms memory). die anwendung hat dann nichts mehr mit dos zu tun und du kannst alles benutzen (auch sockets usw). die programmierung ist die gleiche wie fuer dos (fast).

    leider musste ich durch diese sachzwaenge seinerzeit auf vc umsteigebn 😞



  • Eine Alternative ist auch der DJGPP, der unter DOS lauffähige 32-bit-Programme erstellen kann (die dann einen DOS-Extender benötigen, den man vorher starten muss). Der hat die ganzen Library-Funktionen vom Borland und vom MS-Compiler dabei, soweit ich das sehen kann (also z.B. conio.h, dos.h usw.)


Anmelden zum Antworten