Mail Archives: djgpp/1997/03/14/13:05:59
> On 12 Mar 1997, David Wilson wrote:
>
> > With DPMI you need to realize that the values returned from
> > __dpmi_get_free_memory_information (yes it is a long name), and the
> > corresponding _go32_dpmi_remaining_*() functions, are subject to
change at
> > the whims of Windows/CWSDPMI/...
>
> AFAIK, this is incorrect. The reported *physical* memory might
> sometimes change on Windows (although I never saw this myself), but
> the total *virtual* memory should never change during a program's
> run. With CWSDPMI, it *never* changes. If you can describe a test
> which shows such changes in reported virtual memory, please post the
> description.
I didn't say that the total physical/virtual memory stats might change. I
said that the FREE physical/virtual memory stats might change.
However, there definitely is something more complex happening than I
thought originally. I've just done some playing around with DJGPP 2 in a
Windows 95 DOS box. I compiled and ran the short program below:
------[cut here]------
// test.cc
#include <stdio.h>
#include <stdlib.h>
#include <dpmi.h>
#include <go32.h>
#define MEGS 15
main(int argc, char* argv[])
{
unsigned long avl1, avl2, avl3, avl4, megs;
char* t;
megs = (argc > 1) ? atoi(argv[1]) : MEGS;
megs *= 1024*1024;
avl1 = _go32_dpmi_remaining_physical_memory();
avl2 = _go32_dpmi_remaining_virtual_memory();
printf("Before large malloc: %lu phys, %lu virtual free\n", avl1,
avl2);
t = (char*) malloc(megs);
if(!t) { printf("Malloc (%lu) failed\n", megs); return 1; }
*t = 0;
avl3 = _go32_dpmi_remaining_physical_memory();
avl4 = _go32_dpmi_remaining_virtual_memory();
printf("After large malloc: %lu phys, %lu virtual free\n", avl3,
avl4);
printf("A %lu-sized block uses %lu bytes phys, %lu bytes virtual\n",
megs, avl1-avl3, avl2-avl4);
return 0;
}
------[cut here]------
I ran it in a DOS box with the XMS and DPMI memory values set to 32768
each. Here is what I got:
------[cut here]------
E:\DJGPP2>test 15
Before large malloc: 9785344 phys, 31784960 virtual free
After large malloc: 9781248 phys, 16252928 virtual free
A 15728640-sized block uses 4096 bytes phys, 15532032 bytes virtual
E:\DJGPP2>test 16
Before large malloc: 9781248 phys, 31784960 virtual free
After large malloc: 9781248 phys, 16252928 virtual free
A 16777216-sized block uses 0 bytes phys, 15532032 bytes virtual
E:\DJGPP2>test 17
Before large malloc: 9781248 phys, 31784960 virtual free
Malloc (17825792) failed
------[cut here]------
This goes to prove my original point which I perhaps didn't make as clear
as I had intended: Free memory values under Windows aren't very accurate.
I suspect the problem is from the malloc() implementation. I think it
allocates blocks in fixed sizes that keep on doubling. So when asking for
the 17M chunk, it's trying to get a 30 or 31 meg chunk, which is being
refused by DPMI since Windows only wants to give the program 32 megs.
The only thing I can't figure out is "test 16"... How does a 16MB
allocation fit in *LESS* than 16MB of virtual memory? Can anyone shed any
light on this?
--Dave
<s335194 AT student DOT uq DOT edu DOT au>
- Raw text -