Date: Sat, 07 Oct 2000 13:35:25 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Michael N. Filippov" Message-Id: <2950-Sat07Oct2000133524+0300-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.5h CC: djgpp AT delorie DOT com In-reply-to: <8rkrl1$31j5$1@news.itfs.nsk.su> (michael@idisys.iae.nsk.su) Subject: Re: Memory amount and PMODE References: <8rkrl1$31j5$1 AT news DOT itfs DOT nsk DOT su> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Michael N. Filippov" > 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? What does go32-v2.exe print when invoked with no arguments, on that machine? > -------- __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 = 4294967295 > total_number_of_unlocked_pages = 4294967295 > total_number_of_free_pages = 4294967295 > total_number_of_physical_pages = 4294967295 > free_linear_address_space_in_pages = 4294967295 > size_of_paging_file_partition_in_pages = 4294967295 The docs for the function `__dpmi_get_free_memory_infomation', which returns the above structure, says that unsupported fields have -1 in them (you printed those numbers as unsugned, so you see 4294967295 instead). So the only valid numbers are 67107840 bytes and 16383 pages. These look quite reasonable to me. > -------- __dpmi_memory_info information --------- This structure is returned by a function __dpmi_get_memory_information, which is only supported by DPMI v1.0 hosts. PMODE doesn't support DPMI 1.0, so you get garbage (did you check if the function returns -1, an indication of a failure?). > 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.