delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/01/11/09:15:20

Date: 11 Jan 1994 08:45:08 U
From: "jbabcock" <jbabcock AT netrix DOT com>
Subject: FW: Mail Delivery Subsystem
To: "djgpp list" <djgpp AT sun DOT soe DOT clarkson DOT edu>

>> But what if you're writing a time-critical application and your algorithm
>> can cope with less memory at the expense of, say, accuracy? Is there some
>> "standard" way of telling the O/S that you only want real (fast) memory and
>> not virtual (slow, disk-swapped) memory?
>
>One possibility would be to point go32tmp at a disk (or RAM disk) with no
>free space, then carefully monitor available virtual memory and don't do
>anything which would trigger swapping.  Sounds dangerous, and I hope that
>there is a better way.  _go32_dpmi_get_free_memory_information will return the
>available "real" memory in some dpmi environments, but not all.  (It only
>returns virtual memory under os/2.)

I would like to pursue this issue a little further since it is directly
applicable to my application.  I would like to allocate nearly all of the
"real" memory (leaving a little for DOS scratch pad) in as large a block or
blocks as possible.  I will then do my own memory management for the allocated
blocks.  

The DOS system configuration will have 640K of conventional memory an a minimum
of 384K of extended memory.  Is there a way to short out the paging mechanism
of the go32 facility (perhaps by returning a failure to a page request)?  I
have traced through the code visually, and I could probably figure out what to
do given enough time. Could someone save me some time and point me in the right
direction?

-Jim.



- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019