Sie sind nicht angemeldet.

Limits bei Verwendung von UMB-Speicher

Lieber Besucher, herzlich willkommen bei: GEOS-InfoBase-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

  • 1
  • 2

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

1

Mittwoch, 19. Dezember 2018, 22:20

Limits bei Verwendung von UMB-Speicher

Hallo zusammen

Bei DOSEmu2 wird gerade am BIOS gearbeitet. Netter Nebeneffekt ist, dass der freie UMB-Speicher zunimmt.

C:\ENSEMBLE>mem /p /c

Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 17,280 (17K) 10,080 (10K) 7,200 (7K)
COMMAND 3,552 (3K) 0 (0K) 3,552 (3K)
Free 892,368 (871K) 645,088 (630K) 247,280 (241K)

Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 640K 10K 630K
Upper 252K 11K 241K
Reserved 132K 132K 0K
Extended (XMS) 32,832K 164K 32,668K
---------------- -------- -------- --------
Total memory 33,856K 317K 33,539K

Total under 1 MB 892K 21K 871K

Largest executable program size 630K (645,072 bytes)
Largest free upper memory block 208K (212,736 bytes)
FreeDOS is resident in the high memory area.

Nur scheint mir, dass BBX den zusaetzlichen Speicher gar nicht sieht oder verwendet.

Hat da jemand Erfahrung, wie PC/GEOS den UMB-Speicher einbindet ? Gibt es Specherbereiche, die ignoriert werden ?

Sonst koennte ich ja mal versuchen, das im Quelltext nachzuvollziehen.

Gruss
Andreas

Achim

Fortgeschrittener

Beiträge: 507

  • Nachricht senden

2

Donnerstag, 20. Dezember 2018, 19:44

Hi Andreas.
Bei mir sind System und Command größer, dann wird noch emufs geladen. Sieht dann so aus:http://geos-infobase.de/wcf/icon/fileTypeIconPictureM.png
In der geos.ini kann der Treiber extmem.geo geladen werden. Keine Ahnung, ob der mit den UMB's in Zusammenhang steht.
»Achim« hat folgendes Bild angehängt:
  • memory.png
Gruß Achim



PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

jpolzfuss

Profi

Beiträge: 835

  • Nachricht senden

3

Donnerstag, 20. Dezember 2018, 19:59

Extmem:

DESCRIPTION:
A driver to make use of memory above the 1Mb limit.

PC/GEOS EXTENDED MEMORY MANAGER CORE

A manager for extended memory that relies on BIOS int 15h

A user should make use of an EMS driver if his hardware is capable
of supporting it as the time taken to switch to protected mode to
access extended memory is long (supposed to be only marginally faster
than an access to fixed disk storage).

Glossary (some terms differ from regular pc-geos usage):

Block:
The block of memory in the heap with which we are dealing.

Linear address (LinAddr):
The 24 bit extended memory address of the unit.

Pointer:
A unit index.

Page:
The smallest amount of space allocatable.
Currently set at 1024 bytes. See EM_PAGE_SIZE

Some implementation details:
There can be 15 Megs of extended memory (15360 K).
This memory is divided up into pages and memory is swapped out
by breaking up the block into page-sized chunks.

The swap map is a structure maintained by the swap library that
tracks the allocation of pages in the swap space. Since a page
index is a word, the smallest a page can be is 256 bytes. The
swap map can be large if page size is small (eg 256 byte units
in a 15 Meg system => 15360 * 8 = 122880 bytes).

A page size of 1 K is currently used. The swap map will then
be at most 30720 bytes.

Conversion from a page index into a linear address:
For a 1 Kbyte page,
linear address := (page index * 1024) + 1Meg
There are two rules in life:
1. Never give out all of the information.

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

4

Donnerstag, 20. Dezember 2018, 23:04

Danke fuer Euer Feedback. Ich verwende XMS anstatt EMS. Auch EMUFS verwende ich nicht.

Meine Verstaendnisfrage ist quasi, kann GEOS den UMB-Speicher (direkt) verwenden und wenn ja, was sind die Voraussetzungen. Auch ist gut moeglich, dass gewisse Speicherbereiche aus historischen oder anderweitigen Gruenden ignoriert werden. Da koennte man ja die Quellen dahingehend oeffnen.

Aktuell sieht es bei mir so aus:

C:\ENSEMBLE>mem /p /c

Modules using memory below 1 MB:

Name Total Conventional Upper Memory
-------- ---------------- ---------------- ----------------
SYSTEM 17,280 (17K) 10,080 (10K) 7,200 (7K)
COMMAND 3,552 (3K) 0 (0K) 3,552 (3K)
Free 900,560 (879K) 645,088 (630K) 255,472 (249K)

Memory Type Total Used Free
---------------- -------- -------- --------
Conventional 640K 10K 630K
Upper 260K 11K 249K
Reserved 124K 124K 0K
Extended (XMS) 32,832K 164K 32,668K
---------------- -------- -------- --------
Total memory 33,856K 309K 33,547K

Total under 1 MB 900K 21K 879K

Largest executable program size 630K (645,072 bytes)
Largest free upper memory block 218K (223,248 bytes)
FreeDOS is resident in the high memory area.

Laut Stas waere mit PC DOS sogar 332kB UMB moeglich.

Wenn GEOS den UMB Speicher fuer den Heap verwenden kann, dann haette das definitiv positiven Einfluss...

MeyerK

Fortgeschrittener

Beiträge: 190

  • Nachricht senden

5

Donnerstag, 20. Dezember 2018, 23:33

Soweit ich mich erinnere zeigt doch Perf den verwertbaren Heap-Speicher an und das waren mit UMB's deutlich mehr als 640 KB (immer so um die 800?) oder täusche ich mich da? Aber das sollte man definitiv mal eruieren. Der Code, um auf den Videospeicher des GlobalPC zuzugreifen ist ja auch da und der wurde ganz offenbar nicht in den klassischen Speichermanager integriert...

Interessant sind auch die Dinge die Jörg gepostet hat: GEOS will lieber EMS, weil ein Switch in den Protected Mode fast genauso viel Zeit kostet wie ein Festplattenzugriff?! Dass EMS bevorzugt ist, war ja schon bekannt, aber die Begründung kenne ich erst jetzt...
Bye,
MeyerK

jpolzfuss

Profi

Beiträge: 835

  • Nachricht senden

6

Freitag, 21. Dezember 2018, 13:39

Ich hatte den Text zu extmem eigentlich nur gepostet, um zu zeigen, dass dieser Treiber nur für Speicher jenseits der 1MB-Grenze zuständig ist, also nicht für umb zuständig sein kann... ;)
There are two rules in life:
1. Never give out all of the information.

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

7

Freitag, 21. Dezember 2018, 13:46

In der Hilfe (Preferences -> Computer) steht, dass GEOS nur XMS oder EMS benutzt, aber nicht beides gleichzeitig.
Das mit dem Festplattenzugriff ist wahrscheinlich auf den "Swap" Treiber bezogen. Die Swap-Datei habe ich früher in eine RAM-Disk gepackt, dann hat man die Zugriffslatenzen schön tief ;-)

Ich bin mir einfach noch nicht sicher, ob der Zugriff auf UMB und eventuell auch noch HMA unabhängig ist von XMS / EMS. Habe über die Jahre schon sicher 20x Beschreibungen zu diesem Thema durchgelesen. z.B.

https://www.vogonswiki.com/index.php/DOS_memory_management

Aber die absolute Erleuchtung gab es nicht...
Mein letzter Stand war XMS vor EMS. EMS hatte mit spezieller Hardware gewisse Vorteile (LIMEMS ?). Aber ohne diese Hardware-Unterstützung laufen doch beide rein in Software und müssen jeweils in den Protected Mode umschalten.

Man sollte auch noch im Blick behalten, dass für jeden Typ von Memory-Manager im Heap ein fixer Block fürs Mapping reserviert wird. Je mehr Memory-Manager und je mehr Memory diese anbieten, umso weniger Heap beleibt übrig. Das kann dann genau kontraproduktiv sein. Was hilft mir viel erweiterter Speicher wenn mir dafür der Heap zu klein wird und GEOS deswegen abschmiert ?
Somit sind wir wieder am Anfang dieses Threads. Je mehr Heap unser GEOS bekommt, umso eher können wir dann auch den erweiterten Speicher komplett ausnutzen.
Übrigens gehen pro Speicher-Manager maximal 32MB. Bei der Swap-Datei muss dies von Hand in der GEOS.INI gemacht werden, da in den Voreinstellungen maximal 16MB eingestellt werden können.
Ich hatte auch mal angefangen, mit einem eigenen Tool die Werte zu erfassen. Heap Size / Free und Swap Free habe ich. Nur an den Wert vom gesamten "Swap Size" bin ich nicht herangekommen. Auch hätte ich natürlich gerne die Swap Werte pro Memory-Manager...

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

8

Freitag, 21. Dezember 2018, 15:01

So, habe mal in den Quellen geforscht. In "emm.asm" habe ich keiner Referenzen zu UMB gefunden, aber in "xms.asm" scheinen UMBs alloziert zu werden. Mein erster Eindruck ist, dass der XMS-Treiber UMBs für seine SwapMap verwendet...

Am schönsten wäre es natürlich, wenn UMBs vom Kernel als Heap alloziert würden. Ich schaue mal, ob ich da noch weiter komme...

MeyerK

Fortgeschrittener

Beiträge: 190

  • Nachricht senden

9

Samstag, 22. Dezember 2018, 10:23

Andreas, sieh Dir mal den Source Code für Perf an... (calc.asm). Der ist recht gut kommentiert, vielleicht bringt Dich das weiter. Da findet man dann solche Zeilen:

;The area from A0000h to BFFFFh is not really RAM, and so is allocated
;by the kernel as a fake "LOCKED block". If that is what we have,
;then leave it out of the stats completely.

;now we scan forwards, making a complete loop through the heap,
;gathering stats as we go. (heapUpperStart = handle OR 8000h if we
;are starting in the middle of the Upper area).

;The area from A0000h to BFFFFh is not really RAM, and so is allocated
;by the kernel as a fake "LOCKED block".

Vielleicht könnte man dem Kernel beibringen, dass die genannten Speicherbereiche heutzutage nicht LOCKED sein müssen? Oder müssen sie? Ich habe keine Ahnung...
Bye,
MeyerK

MeyerK

Fortgeschrittener

Beiträge: 190

  • Nachricht senden

10

Samstag, 22. Dezember 2018, 10:27

Der genannte Adressbereich ist offenbar das Fenster für den Videospeicher von VGA Karten...
Bye,
MeyerK

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

11

Sonntag, 23. Dezember 2018, 00:22

Hallo Konstantin

Besten Dank fuer Deine Nachforschungen. Ja, 0xA000 bis 0xAFFF ist das Fenster fuer VGA.

In der Konfiguration von DOSEmu2 kann man z.B. explizit den Bereich von 0xB000 fuer UMB freischalten. Das habe ich bei mir auch so standard-maessig aktiviert. Aber wenn dieser von GEOS ignoriert wuerde, dann waere das doch ziemlich schade...

Koennte es nicht auch sein, dass das frueher so mal gaengig war und Perf dahingehend nie angepasst worden ist ? Es ist ja nicht Perf, das den Speicher scannt und die Bloecke alloziert. Das muesste man in der Kernel Heap-Allozierung sehen koennen (Stichwort Fake-Bloecke mit Wert $90 anstatt $10).

Wenn ich mit einem Test-Programm die Groesse des Heaps auslese, bekomme ich sagenhafte 972'518 Bytes, was knapp 950 kB sind. Dabei habe ich laut DOS "MEM.EXE" nur 879 kB freien Speicher. Kann aber auch sein, dass ich die Funktionen falsch benutze. Auf jeden Fall ohne UMBs bekomme ich auch weniger freien Heap gemeldet.

Im XMS-Treiber wird UMB und/oder HMA alloziert. Im EMS-Treiber konnte ich nichts hierzu finden. Wenn man sich ueberlegt, wie diese Speciher-Manager funktionieren, dann brauchen doch beiden einen Speicher-Bereich, der direkt addressierbar ist. Sprich im unteren 1 MB + 64 KB (HMA). Ueber diesen werden ja die Daten in oder vom hoeheren Speicher transferiert. Bei EMS ist es das EMS-Frame, welches z.B. bei 0xD000 beginnt und 64 kB Gross ist. XMS muesste doch ein aehnliches Fenster haben. Mir scheint es, als ob hier fuer ein UMB oder HMA Bereich gesucht wird.

Nun muesste man die Stelle identifizieren, wo im Kernel der Speicher fuer den Heap gescannt wird.

Gruss
Andreas

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

12

Montag, 14. Januar 2019, 13:18

Ich bin zwar bezüglich Heap-Allozierung nicht zum "Weiterforschen" gekommen, aber habe noch ein paar aktuelle Heap-Werte:

- FreeDOS-Kernel / FreeCOM-Shell : 972'368 Bytes

- FDPP-Kernel / FreeCOM-Shell : 972'576 Bytes

- FDPP-Kernel / LOADER.EXE als Shell : 972'624 Bytes *

* Mit dem FDPP-Kernel (FreeDOS-Kernel-Ersatz vom Programmierer der DOSEmu2) habe ich es geschaft, die "LOADER.EXE" direkt als Shell anzugeben, also ohne "COMMAND.COM" zu starten...

Dazu habe ich folgender Eintrag in der "CONFIG.SYS" gemacht:

Quellcode

 
1

SHELL=C:\ENSEMBLE\LOADER.EXE /log


Leider gibt es beim Beenden die folgende Meldung:

Quellcode

 
1

Shell C:\ENSEMBLE\LOADER.EXE exited, press any key...


Ansonsten verwende ich:

Quellcode

 
1

SHELLHIGH=C:\COMMAND.COM /E:512 /P


Das sieht dann mit "MEM.EXE" folgendermassen aus:

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

C:\>mem /a
 
Memory Type        Total       Used       Free
----------------  --------   --------   --------
Conventional          640K        10K       630K
Upper                 260K        10K       250K
Reserved              124K       124K         0K
Extended (XMS)     32,832K       157K    32,675K
----------------  --------   --------   --------
Total memory       33,856K       301K    33,555K
 
Total under 1 MB      900K        20K       880K
 
Largest executable program size       630K (645,136 bytes)
Largest free upper memory block       219K (223,792 bytes)
Available space in High Memory Area    58K ( 59,823 bytes)
FreeDOS is resident in the high memory area.


Ok, man darf/kann/soll das ruhig als unnötige Optimierungsversuche sehen. Einen wirklichen praktischen Nutzen hat es wohl nicht...

hanslse

Fortgeschrittener

Beiträge: 272

Beruf: Systemadministrator

  • Nachricht senden

13

Dienstag, 22. Januar 2019, 11:06

Some comments in english to EMS memory and Geos, which is from my experience regarding EMS and GEOS

LIM EMS is the EMS standard. Today LIM is usuallay dropped, and it is just called EMS. LIM stands by the way for Lotus, Intel Microsoft, which were the creators of this standard in the old XT (8088) days. So there is no special hardware that explicitly relates to LIM EMS. There was in the early 90's if I recall correctly, when EMS was a mess. I remember having an old 8088, with a 4 MB EMS memory card. GEOS Pro (1.28) ran so fast with this memory card supporting LIM EMS, although it only used 64 KB of the 4 MB card. Nowadays EMS in FreeDOS are LIM EMS and is the standard EMS, as in every DOS, the LIM prefix is dropped.

Regarding EMS and GEOS, as I recall, Geos still uses only 64 kB (the frame) and adds it to the heap. When getting the EMS working properly with GEOS, there is a significant difference in speed, at least it have been for me, from Geos 1.x to Breadbox Ensemble 4.13, and also more RAM to GEOS. But there are drawbacks, I don't have the faintest idea why, but Geos works best with the DR DOS EMS driver and the IBM EMS Driver in PCDOS. I had problems with FreeDOS EMS-driver, and also the Microsoft one, but it might not relate to the EMS driver itself? As there are many things which can create problems. Like the BIOS handling of the upper memory area, like BIOS shadowing, for graphics and System BIOS. They nomally needs to be turned off. Other software and drivers that uses upper memory can also be a problem, if it does not behave according to the EMS standard. The result when GEOS is not working properly with GEOS is a KR-09 crash (might also be KR-07)

I would appriciate if there is someone that can outline a way to troubleshoot the EMS handling, and especially in FreeDOS as it is the only supported DOS.

Hans

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

14

Dienstag, 23. August 2022, 09:24

Update bezüglich Stand HEAP unter DOSEmu2 mit FDPP DOS-Kernel. PC/GEOS hat mit der aktuellsten DOSEmu2-Version nun einen HEAP von 981'120 Bytes. Das sind doch nochmals rund 500 Bytes mehr als mit der Version vor einer Woche...

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

C:\>mem /a /c

Modules using memory below 1 MB:
 
  Name           Total           Conventional       Upper Memory
  --------  ----------------   ----------------   ----------------
  SYSTEM       9,216    (9K)      1,328    (1K)      7,888    (8K)
  COMMAND     20,752   (20K)          0    (0K)     20,752   (20K)
  EMUFS          176    (0K)          0    (0K)        176    (0K)
  Free       882,928  (862K)    653,696  (638K)    229,232  (224K)
 
Memory Type        Total       Used       Free
----------------  --------   --------   --------
Conventional          640K         2K       638K
Upper                 252K        28K       224K
Reserved              132K       132K         0K
Extended (XMS)     32,832K        64K    32,768K
----------------  --------   --------   --------
Total memory       33,856K       226K    33,630K
 
Total under 1 MB      892K        30K       862K
 
Largest executable program size       638K (653,680 bytes)
Largest free upper memory block       196K (200,576 bytes)
HMA is available via the XMS driver


Folgende Anpassungen habe ich noch gemacht:

DOSEmu2 Source (Tip von Stas):

Quellcode

 
1
2
3
4

$ vi src/plugin/fdpp/hooks.c

//        heap_seg = 0x90;  // for low heap
        heap_seg = 0x50;  // for low heap (0x90)


FDPP Source (funktioniert nicht mit WIndows 3.x):

Quellcode

 
1
2
3
4

$ vi kernel/config.c

//      DynAllocLow("sft", 1, sizeof(sftheader) + 3 * sizeof(sft));
      DynAlloc("sft", 1, sizeof(sftheader) + 3 * sizeof(sft));


Ich brauche kein CD-ROM und soviele Laufwerke:

Quellcode

 
1
2
3
4

# vi /usr/local/share/dosemu/dosemu2-cmds-0.3/fdppconf.sys

lastdrive=F
rem devicehigh=dosemu\cdrom.sys


Für PC/GEOS benötigt:

Quellcode

 
1
2
3
4

$ vi ~/.dosemu/drive_c/userhook.sys

FILESHIGH=120
STACKS=0


Weitere Optimierungen für PC/GEOS:

Quellcode

 
1
2
3
4
5
6
7
8
9

$ vi ~/.dosemu/dosemurc

$_cdrom = ""
$_umb_b0 = (on)
$_ems = (0)
$_xms = (32768)
$_X_noclose = (on)
$_X_vesamode = "1366,768 1920,1080 1920,1200"
$_X_vgaemu_memsize = (8192)

Achim

Fortgeschrittener

Beiträge: 507

  • Nachricht senden

15

Dienstag, 23. August 2022, 15:29

Bei mir...

...funktioniert die DOSEmu2 z. Z. überhaupt nicht. Nach dem gestrigen Update war totale Funkstille. Nach dem heutigen Update kommen wenigstens ein paar Meldungen im Terminal, aber das DOSEMU-Fenster schließt sich wieder. ?( :wacko:
Gruß Achim



PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

16

Dienstag, 23. August 2022, 21:11

Hallo Achim

Sieht Dein Fehler so aus?

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11

ERROR: SMALLOC: Out Of Memory on alloc, requested=1023
Total size: 16384
Available space: 971 (15413 used)
Largest free area: 971
Memory pool dump:
	area: 1024 bytes, used
	area: 14384 bytes, used
	area: 5 bytes, used
	area: 971 bytes, free

ERROR: lowmem_heap: OOM, size=1023


Dieser wurde erst gestern gefixt. Du solltest bald ein Update erhalten. Wichtig ist hier noch, dass auf FDPP aktualisiert wird. Siehe Diskussion auf Github

Dort ist auch eine Option beschrieben, welche das Problem in der Zwischenzeit umgeht:

Quellcode

 
1

$dos_up = (off)


Gruss
Andreas

Achim

Fortgeschrittener

Beiträge: 507

  • Nachricht senden

17

Mittwoch, 24. August 2022, 15:13

Hi Andreas.
Genauso sieht mein Fehler aus. OK, werde mal auf das Update warten und bis dahin die Notlösung probieren.
Gruß Achim



PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

Achim

Fortgeschrittener

Beiträge: 507

  • Nachricht senden

18

Mittwoch, 24. August 2022, 17:54

Hallo.
Update ist eingespielt, et looft wieda. :D

Mein Speicher sieht jetzt so aus:
Gruß Achim



PC/GEOS unter Linux in der DOSEMU = UNSCHLAGBAR!

MeyerK

Fortgeschrittener

Beiträge: 190

  • Nachricht senden

19

Mittwoch, 24. August 2022, 20:11

... und was sagt GEOS? (Siehe Perf / Heap)....
Bye,
MeyerK

bolle732

Fortgeschrittener

  • »bolle732« ist der Autor dieses Themas

Beiträge: 332

  • Nachricht senden

20

Donnerstag, 25. August 2022, 10:10

TWEAKED 20220823 - DOSEMU HEAP_SEG / FDPP ALL SFT HIGH / NO CDROM / LASTDRIVE=F

Quellcode

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

C:\>mem /a /c

Modules using memory below 1 MB:
 
  Name           Total           Conventional       Upper Memory
  --------  ----------------   ----------------   ----------------
  SYSTEM       9,216    (9K)      1,328    (1K)      7,888    (8K)
  COMMAND     20,752   (20K)          0    (0K)     20,752   (20K)
  EMUFS          176    (0K)          0    (0K)        176    (0K)
  Free       882,928  (862K)    653,696  (638K)    229,232  (224K)
 
Memory Type        Total       Used       Free
----------------  --------   --------   --------
Conventional          640K         2K       638K
Upper                 252K        28K       224K
Reserved              132K       132K         0K
Extended (XMS)     32,832K        64K    32,768K
----------------  --------   --------   --------
Total memory       33,856K       226K    33,630K
 
Total under 1 MB      892K        30K       862K
 
Largest executable program size       638K (653,680 bytes)
Largest free upper memory block       196K (200,576 bytes)
HMA is available via the XMS driver

GEOS HEAP 981'120 Bytes


Mit LOADER.EXE als Shell sind es sogar:

GEOS HEAP 981'296 Bytes
  • 1
  • 2

Ähnliche Themen

Thema bewerten