Newsgroups: comp.sys.ibm.pc Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!uunet!drivax!frotz From: frotz@dri.com (Frotz) Subject: Re: DR DOS 5.0 and available memory Message-ID: <8DR39ZR@dri.com> Sender: frotz@dri.com Reply-To: frotz@dri.com Organization: Digital Research, Monterey CA/USA or none (see also My_Desk) References: <1991May23.231255.6520@cbnewse.att.com> <1991May28.150326.381@ulkyvx.bitnet> <1991May30.131929.9709@cpqhou.uucp> Distribution: usa Date: Fri, 31 May 91 21:46:35 GMT Lines: 47 thomasr@cpqhou.uucp (Thomas Rush) writes: ]In article <1991May23.231255.6520@cbnewse.att.com>, langev@cbnewse.att.com (steve.j.langevin) writes: ]> ]> I just purchased DR DOS 5.0 and installed it on my hard disk. I'm seeing ]> what looks like some discrepancies between chkdsk and mem about how ]> much memory I have available. ]> ]> chkdsk (and PC TOOLS) say I have ~590KB available. ]> ]> mem says I have ~613KB. ]> ]>Patrick Lankswert ...psuvax1!ulkyvx.bitnet!pclank01 ]Could it be that chkdsk is about 20K larger than mem? Funny, I was just up in Tech.Sup. talking to someone about the future;-) Bradley Kerth (sorry, no net address guys;-{ mentioned that there was a bug problem with chkdsk. It is now EXEPACKed. This means that in order to decompress in memory, it CANNOT reside in segment 0000:ofs (where mem is loaded because it is NOT EXEPACKed). An bug report (SPR) has been submitted to the development group and their initial response has something to do with MEMMAX and disabling lower memory. No, I wasn't paying too much attention to the details...;-) Below is a quick map: MEM CHKDSK (not packed) (packed) ------------------------------ ------------------------------ Segment 0 MEM Segment 0 Free memory ... Segment 'n' Free memory Segment 'n' CHKDSK Segment 'm' Free memory Segment 'n' Free memory The bottom line is that CHKDSK is not smart enought to recognize the free memory in segment 0 (below itself). It only reports the amount of memory above itself. Since MEM is loaded as low as possible it reports the amount of free memory above it (which is the correct total). -- John "Frotz" Fa'atuai frotz@dri.com (email@domain) Digital Research, Inc. uunet!drivax!frotz (bang!email) c/o MIS Dept. 408/647-6570 or 408/646-6287 (vmail) 80 Garden Court, CompRm 408/649-3896 (phone) Monterey, CA 93940 408/646-6248 (fax)