Mail Archives: djgpp/2000/10/08/10:05:42
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]. Or maybe somebody know alternative DPMI
server - stub that can be bound to the executable without this limitation.
> In general, I would advise not to use PMODE unless you have a very
> good reason. (For starters, it doesn't support virtual memory.)
Agreed, and I know that it doesnt support virtual memory, but imagine
that the program _must_ be a single execuable (it depends not on me -
I would rather tune CWSDPMI parameters). 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 (e.g to have
select_file_box() with checkbox "enable/disable swap" :). 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.
> 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. Anyway I know that STL discussion is offtopic and
we shouldnt discuss it here, but i still have 2 questions marked above.
Sincerely,
Michael
- Raw text -