Mail Archives: djgpp/2000/10/07/10:15:12
In article <2950-Sat07Oct2000133524+0300-eliz AT is DOT elta DOT co DOT il> you wrote:
>> From: "Michael N. Filippov" <michael AT idisys DOT iae DOT nsk DOT su>
>> Newsgroups: comp.os.msdos.djgpp
>> Date: 6 Oct 2000 15:38:09 GMT
>>
>> How can I estimate amount of free / busy memory
>> in the program runing under PMODSTUB DPMI server.
>> For example _go32_dpmi_remaining_physical_memory() and
>> go32_dpmi_remaining_virtual_memory() return values that have no
>> sense (4294967295 and 67107840).
> The first one is actually -1 (meaning the info is unavailable), but
> the second number is 64MB. Why doesn't this make sense, on a 128MB
> machine?
I understand about -1 (for unsigned long :) and corrected the prog a little.
I just expected that I'll be able to use all memory. As for the difference
in the program output when
using CWSDPMI)
-------- go32 information ---------
physical_mem = 132927488
virtual_mem = 266563584
-------- __dpmi_free_mem_info information ---------
largest_available_free_block_in_bytes = 266563584
maximum_unlocked_page_allocation_in_pages = 65079
maximum_locked_page_allocation_in_pages = 32453
linear_address_space_size_in_pages = unsupported
total_number_of_unlocked_pages = 32495
total_number_of_free_pages = 32453
total_number_of_physical_pages = 32495
free_linear_address_space_in_pages = unsupported
size_of_paging_file_partition_in_pages = 32760
-------- __dpmi_memory_info information ---------
Returned: -1
using PMODE)
-------- go32 information ---------
physical_mem = 4294963200
virtual_mem = 67107840
-------- __dpmi_free_mem_info information ---------
largest_available_free_block_in_bytes = 67107840
maximum_unlocked_page_allocation_in_pages = 16383
maximum_locked_page_allocation_in_pages = 16383
linear_address_space_size_in_pages = unsupported
total_number_of_unlocked_pages = unsupported
total_number_of_free_pages = unsupported
total_number_of_physical_pages = unsupported
free_linear_address_space_in_pages = unsupported
size_of_paging_file_partition_in_pages = unsupported
-------- __dpmi_memory_info information ---------
Returned: -1
So maybe PMODE doesnt use more than 64Mb, there's no hint in
documentation what can I do.
> What does go32-v2.exe print when invoked with no arguments, on that
> machine?
go32/v2 version 2.0 built Nov 15 1998 14:36:43
Usage: go32 coff-image [args]
Rename this to go32.exe only if you need a go32 that can run v2 binaries as
well as v1 binaries (old makefiles). Put ahead of the old go32 in your PATH
but do not delete your old go32 - leave it in the PATH after this one.
Set GO32_V2_DEBUG=y in the environment to get verbose output.
DPMI memory available: 130499 Kb
DPMI swap space available: 129881 Kb
>> I'd like to trace my program which uses STL and sometimes dies
>> with "out of memory" message though my estimations show than
>> only 30-50% of memory is allocated at the moment.
> go32-v2, when invoked with no arguments, will show you what maximum
> amount of memory can you count on. PMODE may incur additional
> limitations (why do you use it, btw?), which go32-v2 won't show, since
> it wasn't linked with PMODE stub.
Namely, I expected to have all memory :( and didn't think about additional
limitations (except virtual memory). I hope somebody can help me with
PMODSTUB tuning. Or offer another DPMI server (stub), because I have no
choice - only single EXE file (consumer demands) and even all data must be
attached to the executable in EXEDAT format.
BTW - i know that STL has own allocators, is there way to optimize it for
size (not for speed). And how can i estimate in the program (run-time)
free/busy memory amount (as far as I concerned sbrk(0) traces heap, how can
I find out if the program runs out of stack - to catch memory eating
block).
Sincerely,
Michael
- Raw text -