(redirected from
DOS.Mem)
WIKI page for FreeDOS MEM
MEM is a program delivered with DOS which shows the usage and availability of several types of DOS memory. FreeDOS aims to have its own MEM program, for which the documentation is on this page.
Download
- View CVS repository (all versions up to 1.7beta)
- Download released files: As at 29-Aug-05, mem17bet.zip contains the most recent source and binaries except for a change in CVS which replaces the getenv() function although this doesn't change the user-visible behavior. This file is missing the kitten.[ch] source files which are in CVS.
- Version 1.8 alpha 1: for testing only; includes source for mem.c only
- Version 1.9 alpha 2: for testing only; includes full sources with additional (partially-documented) tools MEMTEST and MUSCHI. Version number increased for several reasons
- Latest source/binary snapshots: these include fairly minor changes compared to 1.9 alpha 2
Compiling MEM
Obtain OpenWatcom 1.3 or later, and specify "-c -j -wx -ms -oahls -s -d2" as options. These are the options used by current developer David o'Shea; check the Makefile in CVS to see what was used for 1.7 beta.
If you are having problems
- check the known issues list below
- post a question on the freedos-user mailing list
Solved issues up to v 1.9 alpha 2
- Bug: v1.6 showed error message:
MEM: UMB Corruption. Solved in 1.7+
- Bug: v1.8 Alpha1 didn't show (fd)config.sys drivers in MEM /C output
- Bug: MEM /M didn't report errorlevel for non-existing modules. Now returns errlvl 2
- Bug: MEM /N (/N /P) showed nothing. Now a warning is shown.
- For remaining bugs, see below. Not everything verified or solved yet.
Open issues
- Compatibility with pre-386 systems
- The summary, /X and /E options should be safe on systems without XMS/EMS
- 8086 : conventional memory and hardware EMS cards
- 80186: same
- 80286: also XMS
- Bug: MEM /M MSDOS didn't work. Workaround: MEM /M DOS (alias: MEM /M SYSTEM) Note that MS-DOS 6.22 'MEM /M MSDOS' includes the free memory but FreeDOS 'MEM /M DOS' doesn't.
Bug: when there is no upper memory available, MEM /FREE shows an empty table and a total of 0K; it should instead show No upper memory available
Developer notes: future plans, work status, etc.
- is it possible to show HMA allocation for BUFFERSHIGH, etc.? From the thread "Kernel Problems" on freedos-devel on 27-Nov-2005 we can see that it is confusing that we show BUFFERS and we show BUFFERSHIGH if it isn't actually stored in HMA but we don't show BUFFERSHIGH when it's in HMA
- Bart said: int86() is an expensive function in terms of space in OpenWatcom, a lot more expensive than #pragma aux.
Here are notes from an email exchange I (doshea) had:
- Eric said: Would be nice if you could also add MEM /A which adds a line of HMA info to the default summary, based on int 2f.4a01 output. [...] MS MEM has /A as undocumented option, too.
- the full name of the argument in MS-DOS 6.22 is /ALL, which is strange since it doesn't alter any other part of the output as far as I can tell, only the HMA information
- with MS-DOS 6.22 MEM, the /ALL option adds this line:
Available space in High Memory Area 8,320 (8K)
- this indicates how much HMA space is avaiable via DOS if DOS=HIGH is specified
- MS-DOS 6.22 shows 0 bytes available if DOS=HIGH is not specified in CONFIG.SYS, i.e. if DOS is not responsible for the HMA
- FreeDOS MEM 1.7 beta and MS-DOS 6.22 MEM show a line such as this when DOS=HIGH is specified:
MS-DOS is resident in the high memory area. (in the MS-DOS 6.22 MEM command's output, this line comes after the line that /ALL adds)
- if DOS=HIGH is not specified, FreeDOS MEM 1.7 beta does not provide any information about the HMA, but MS-DOS 6.22 MEM shows
The high memory area is available.
- if no XMS driver is loaded, MS-DOS 6.22 MEM shows no HMA information regardless of whether /ALL is specified or not
- the new FreeDOS MEM will:
- not show 0 bytes available if DOS=HIGH is not specified like MS-DOS 6.22 MEM does, because although this is followed in MS-DOS 6.22 MEM by a statement that the HMA is available, it is misleading and confusing; instead it will show:
HMA is available via the XMS driver; the amount of HMA available via the XMS driver is constant (64K - 16) so is not shown in the output of the MEM command
- if the XMS driver is enforcing a minimum HMA allocation size (due to a /HMAMIN flag being passed to it), a suffix such as the following will be added:
; minimum TSR size (HMAMIN) is 16384 bytes
- give an indication if the HMA is not available due to no XMS driver being loaded, i.e.:
HMA is not available as no XMS driver is loaded
- give an indication if the HMA is not available due to some other reason indicated by the XMS driver, e.g.:
HMA is not available via the XMS driver: not implemented by the driver, a VDISK device is present, etc.
- Bernd suggested we add a flag such as /N[OSUMMARY] to prevent the display of the default summary, which would of course only make sense when e.g. /C is used
- he also suggested that there should be a /S[UMMARY] command that overrides /N[OSUMMARY] in case /N[OSUMMARY] is coded in an alias/batch file but the user occasionally does want the summary
- /N[OSUMMARY] is available in 1.8 alpha 1; /S[UMMARY] will be available in the next release
- I suggested that output order should depend on the order of the switches, i.e. /C/D output would differ from /D/C, although I note that this would require significant changes to the way in which command-line arguments are parsed
- this may never be implemented
- Bernd noted a bug with /C/? vs. /?/C - one will show the /C output before the help whereas in both cases we should only show the help
- this will be fixed in the next release
- Bernd pointed out that MS-DOS MEM supports /M<program name> and /M:<program name> and I also found it supports any number of colons and also /MODULE<program name>. I will need to modify the command-line parser to support this.
- this will be fixed in the next release
- Bernd would like versions of MEM with different languages built-in
- this will be provided in the next release using a Perl script called \"MUSCHI\"
- Bernd would prefer that we generate files such as BIN\MEM\MEM_DE.EXE, etc.; the current code does not behave that way
Items from the version 1.0 TODO list:
- \"Rename /F => /D[EBUG]; inline list of device drivers; identify source in CONFIG.SYS\"
- I have preserved /F[ULL] (and /DEV[ICE]) and added /D[EBUG]; /F[ULL] and /D[EBUG] only differ in that /D[EBUG] includes the devices inline
- with regards to identifying the source in CONFIG.SYS:
- MS-DOS 6.22 MEM shows this in MEM /D:
Segment Total Name Type
------- ---------------- ----------- --------
0025B 17,088 (17K) IO System Data
1,152 (1K) XMSXXXX0 Installed Device=HIMEM
- FreeDOS MEM 1.7 beta shows this in MEM /D (devices):
Address Attr Name Program
----------- ------ ---------- ----------
0269:0000 8000 XMSXXXX0 HIMEM
- I have implemented this output for /D[EBUG] (note the output above is now under /DEV[ICE]; also note that the text \"(DOS)\" will probably be changed to \"DOS\"):
Segment Size Name Type
------- -------- ------------ -------------
025a 22112 (DOS) system data
0269 2528 HIMEM device driver
XMSXXXX0 installed DEVICE=HIMEM
- \"add /F[REE]: shows free blocks in both transient memory area and upper memory area\"
Free Conventional Memory:
Segment Total
------- -----------------
0096D 320 (0K)
012FF 352 (0K)
01567 88,992 (87K)
02B21 478,704 (467K)
Total Free: 568,368 (555K)
No upper memory available
- this is included in 1.8 alpha 1
- \"add /M[ODULE] modulename: shows information about the given filename\"
4DOS is using the following memory:
Segment Region Total Type
------- ------ ---------------- --------
007D4 64 (0K) Data
007D8 3,392 (3K) Program
008AC 3,088 (3K) Environment
----------------
Total Size: 6,544 (6K)
- for FreeDOS MEM:
- I believe the \"region\" information is unavailable in FreeDOS as the kernel does not use UMB control blocks as per Ralf Brown's Interrupt List version 61 table #01630
- while the MS-DOS format doesn't include the \"Name\" column, it would be good to provide inline device names in the /M[ODULE] output (maybe only if another switch is specified), in which case the \"Name\" column would be needed
- this is included in 1.8 alpha 1; inline device names are always shown
- note that the above suggestions/changes will cause both /D and /F to change meaning - /D will refer to the new (MS-DOS 6.22 compatible) /DEBUG whereas its current output will move to /DEVICE, and /F will now refer to the new (MS-DOS 6.22 compatible) /FREE whereas its current output will move to /FULL
- perhaps a switch should be available to cause /D and /F to revert to their old meanings; a user who wishes them to keep their old meanings could create an alias that inserts this switch before whatever switches they manually enter on the command line
Should verify that MEM works with linking upper memory to conventional memory
Provide an 8086 version? Yes
- in the post to freedos-devel with subject \"x-comment to Johnson Lam\", Aitor suggests: \"say \"386+ optimised version\" or \"8088 version\" clearly in the /?\"
- in the post to freedos-devel with subject \"Chasing MS-DOS compatibility\", Bernd said: \"I'd suggest a 8086 version with 386 optimizations/possibilities, not a '80386+-exclusive version & a 8086 version' like many other programs.\"
- this seems reasonable given that the performance of the tool isn't critical
- see link to bugzilla entry in bug list above
- comments from Eric:
- I can tell you that the inline assembly contains nothing that requires a better CPU than 8086 OUTSIDE the functions call_xms_driver_edx and call_xms_driver_eax and check_e820, which is the same set as with the NASM assembly code. In both cases, you have to make sure to call those functions ONLY after is_386() returned true.
- Another important but completely CPU-unrelated problem is that the check_8800 function must not be called on pre-286 CPU (just use \"do not call on pre-386\" for now...) and the check_e801 makes no sense on pre-386 CPUs. Those can cause crashes even though they do not call non-8086 instructions in themselves. The problem is simply that the BIOS of an 8086 cannot handle them!
- As told, you can use DEBUG \"m0\" before disassembling with DEBUG, but I am pretty sure that the problem is only in one or several of:
- the compiler optimizes for newer CPU than 8086 (makefile bug)
- you call call_xms_driver_edx, call_xms_driver_eax or check_e820 without first checking is_386
- you call check_8800 or check_e801 without first checking is_386
- And I am pretty sure that check_xms fails to follow those rules.
- Bart said: About the XT problem, I suspect this may be because int15/e801 and int15/88 are called unconditionally. Though int15/88 should not hang according to RBIL.
- doshea has not actually investigated anything yet
The FreeDOS kernel is responsible for moving the EBDA - see the freedos-kernel mailing list archives here, here, here; MS-DOS takes care of moving the EBDA in EMM386.EXE
- Need to verify that MEM works properly when the EBDA reports less than 640K of memory installed - it has been tested with both 639K and 640K, but what will it do if there is significantly less due to some driver like \"ontrack\" being loaded? It should note there is some memory reserved there.
This thread discusses using DEVLOAD to load HIMEM or EMM386. Experiments done after the thread showed that Martin Stromberg's FDXMS family of XMS drivers can be loaded using DEVLOAD.
Future enhancements
Add support for showing which interrupts are associated with which block of memory - there is already code there to do this, but it's disabled, and there is no command-line switch to enable this output yet. Arkady says: "I recommend to look at smart interrupts walking in MAP from JADOXA: http://www.geocities.com/jadoxa/map/map30.zip" (I assume this code walks the interrupt chain as opposed to what MEM's disabled code appears to do which is to just indicate the most recent code that hooked an interrupt)
Try to associate XMS allocations with programs in memory (if this is possible) and show those XMS allocations in the /C output.
PC Tools' Memory Information (MI) Output format:
- Johnson Lam requests that output in the style of PC Tools' Memory Information (
MI) tool be provided.
MI provides a number of different command-line options. Johnson provided this sample output which may have had its formatting messed up a bit, particularly at the end (not sure which options were provided to MI at this time):
Memory Info V9 (c)1993 Central Point Software, Inc.
Total bytes owned
Addr. Low area High area Program or device driver
----- -------- --------- --------------------------
026Fh 2,528 .. Device=HIMEM Attr=8000h Name=XMSXXXX0
030Eh 3,360 .. Device=EMM386 Attr=C000h Name=EMMQXXX0
03E1h 960 .. Device=XDMAJR Attr=8000h Name=XDMAJR$
041Eh 432 .. Device=HXLDR32 Attr=8000h Name=HXLDR32#
043Ah 1,328 .. Device=SRDXMS Attr=2842h Drive D
05C6h 2,992 1,024 COMMAND
0695h 5,872 .. PRN2FILE \mi.txt
0806h 620,432 .. <largest free area>
---- Begin High (Upper) Memory ----
C802h .. 5,008 Device=VIDE-CDD Attr=C800h Name=SHSU-CDN
C93Ch .. 3,248 Device=NANSI Attr=8013h Name=CON
CA08h .. 3,952 Device=IFSHLP Attr=D000h Name=IFS$HLP$
CB00h .. 5,968 SHCDX32C
E201h .. 3,312 CTMOUSE
653,312 bytes (638k) total DOS 7.10 conventional memory.
620,432 bytes (606k) largest executable program. 80,016 bytes if loaded high.
High memory is managed by DOS. Memory allocation strategy 00h: First fit.
UMBs linked. 0 bytes Extended (AT/286/386) memory, reported by BIOS.
64,448k bytes XMS 3.0 (3.11) memory: 33,383k used + 31,065k free. DOS in HMA.
32,768k bytes EMS 4.0 memory: 1,856k used + 30,912k free. No page frame.
- since
MI has a number of command-line options, it may be complex to support these along with the normal MEM options, especially if some flags overlap; it may be simpler to have a separate executable called MI.EXE and this would also help for users who are used to typing MI
Bernd requests:
- try to get more driver information for EMS and XMS drivers, e.g. dates