Date:	Sun, 08 Oct 2000 17:24:34 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
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

> 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.

- Raw text -