I personally use MAPMEM (from the old TSRCOM35 utilities) instead of MEM from
either MS or FD. I find its output much more useful and informative, at least
for my purposes. Here's an example of the output from my current VMWare
virtual machine (running MS-DOS rather than FreeDOS, and loading some
"experimental" TSRs I am working on):
MAPMEM 3.5, Copyright 1993 TurboPower Software
Psp Cnt Size Name Command Line Hooked Vectors
---- --- ------ ---------- ------------------- --------------------------------
2 23,296 DOS
1 144 ---free---
05E8 1 1,952 DPMS141
0663 1 768 PUSHDIR
0694 1 6,928 KEYB US,,V:\\KeyBoard.Sys FA
1 704 ---free---
0873 1 6,656 TODDY n/a 1B D5
0A14 1 11,776 DOSLFN n/a FD
0CF5 1 2,448 ANSI 21
0D8F 1 1,840 LocKeys n/a 09 10 29 2D
C901 2 1,104 (COMMAND)
0E4A 2 595,440 ---free---
653,296 ---total--
High Memory
2 102,304 DOS
B606 1 2,256 PrtScr n/a 05 08 13 28
B694 1 4,720 CLOCK
B7BC 1 640 BATTSAVE 16 2A 2F
1 416 ---free---
C901 2 10,720 COMMAND 22 23 24 2E
1 1,520 ---free---
122,720 ---total--
EMS Memory
0001 393,216 SYSTEM
0002 16,384 PrtScr
33,538,048 ---free---
33,947,648 ---total--
XMS Memory
0001 212,992 n/a
0002 16,777,216 n/a
0003 1,572,864 n/a
46,252,032 ---free---
64,815,104 ---total--
Of particular interest in this discussion is the PrtScr program (you can
download the program and source code from my web site, bretjohnson.us). I have
PrtScr configured to load part of itself into EMS (if EMS is available), DPMS
(if DPMS is available), and also to automatically load all or part of itself
into upper memory if UMBs are available.
As you can see, MAPMEM reports that PrtScr is loaded in a UMB at segment B606
with a reported size of 2,256 bytes and hooks at least 4 interrupts. In
addition, PrtScr shows up as using 16,384 bytes of EMS memory (one EMS page).
Note that if EMS (or DPMS) aren't available, PrtScr would show as using 4,304
bytes of either conventional or upper memory.
Here is the output from PRTSCR's internal memory allocation report:
PRTSCR has been installed using the following memory allocation:
Conventional (Low) Memory : 0 bytes
Upper Memory (UMBs) : 2272 bytes
Expanded Memory (EMS) : 16384 bytes
DOS Protected Mode Services (DPMS): 0 bytes
The discussion of whether MEM (or MAPMEM) should be showing PrtScr as using
2256 bytes (not including the 16-byte MCB) or using 2272 bytes (which includes
the MCB) is really a philosophical question, not a technical question.
The MCB is not actual data, but is metadata (information about the actual
data). This is similar to what happens with files where the metadata about the
file (file name, size, date, etc.) are stored in the File Allocation Table
(FAT). With files, the FAT is stored on a completely different part of the
disk than the file so it kind of looks like there is no metadata associated
with the file even though there is. Even a file that shows as 0 bytes in
length is using some part of the FAT, so if you were were to include the
metadata for files (the amount of data stored in the FAT) no file is truly 0
bytes long, and every file is just a little bit bigger than the reported file
size. But for files, we just consider the metadata (the FAT) to be part of the
"overhead" and don't include it in the calculations.
Memory allocations doesn't work the same way as file allocation, though, and
the memory metadata (the MCBs) are "interleaved" with the allocated memory
blocks instead of being stored in a completely separate location as they are
with files. Because an MCB is right next to the memory block it is
"controlling", it looks like maybe it should be considered part of the memory
block itself, but it really isn't. It's just the metadata abut the memory
block, and if it were stored in a different way (like it is for EMS and XMS
memory) this wouldn't even be up for debate.
What MAPMEM shows is the CONTENTS of the MCB (the information/metadata about
the memory block), which does not include any information about the MCB itself
(just like a FAT entry for a file doesn't include any information about the FAT
but only about the file).
Whether the MCB should be included in the output of MEM or MAPMEM is really a
matter of opinion, but I think the way MAPMEM does it (not including the MCB
itself) is probably the right way to do it. That is also consistent with the
way you request memory blocks (when you request a memory block of a certain
size, you don't worry about where or how the metadata is stored -- the memory
allocator worries about that -- again, for example, EMS and XMS don't use MCBs
but the metadata still exists).
In my memory allocation report for PrtScr, I include the 16-byte MCB in the
calculation since I think it's probably appropriate for an individual program
to do that, but I don't think DOS should do it with MEM._______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
