Date: Sun, 08 Oct 2000 17:24:34 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: michael AT idisys DOT iae DOT nsk DOT su Message-Id: <1858-Sun08Oct2000172434+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: <20001008141510.8288.qmail@idisys.iae.nsk.su> (michael AT idisys DOT iae DOT nsk DOT su) Subject: Re: Memory amount and PMODE References: <20001008141510 DOT 8288 DOT qmail AT idisys DOT iae 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 AT idisys DOT iae DOT nsk DOT su > Date: 8 Oct 2000 14:15:10 -0000 > X-Newsgroups: comp.os.msdos.djgpp > > In article <7263-Sat07Oct2000203046+0300-eliz AT is DOT elta DOT co DOT il> you wrote: > > It looks like PMODE indeed doesn't support more than 64MB. > > Is there a way to make sure it cannot be changed with run/compile-time > variables [first question]. Sorry, I don't understand: what would you like to make sure, exactly? > Or maybe somebody know alternative DPMI > server - stub that can be bound to the executable without this limitation. Well, as Charles Sandmann already told you, the next release of CWSDPMI, which is coming very near to its release, will feature a stub that can be bound to the program to make a stand-alone executable. > The problem with virtual memory > is even deeper: this program starts from floppy to repair file system on > the local hard drive, so i cannot use default c:\cwsdpmi,swp, It would > be nice to have ability to enable/disable swap and change swap file path > (if there's a network drive for example) in the run-time If you are going to repair a file system, is it really wise to trust that file system enough to put a swap file on it? Anyway, the sources of CWSDPMI are freely available, so you could, in principle, do anything. > Because > I dont know if it possible with CWSDPMI or any other appropriate > DPMI server [second question] I have no arguments to convince the > customer, because to have additional executable is a very big minus > for him. It is not clear to me what are the circumstances in which your program needs to work, and what is it required to do, so I really cannot say anything intelligent about this. E.g., if you need to run on Windows, you don't need to worry about the swap file at all. > > I don't know. But it strikes me that, since you have 128MB installed, > > there's no need to dig so deep into the library internals. It is much > > easier (and more portable!) to change your data structures and/or > > algorithms so that it will use the available memory much more > > efficiently. > > I'm trying to do my best with structures/algorithms :) but when I see the > library looses 30-50% of memory after sequence of reallocations (defragments), > and this memory could be used for drive cache, I understand this is the > part killing efficiency. But that's exactly what I meant: if your current algorithms/data structures result in poor memory performance, you should try to change the algorithms and/or data structures before digging into the library internals and obscure DPMI memory allocation aspects.