X-Authentication-Warning:	delorie.com: mailnull set sender to opendos-bounces using -f
Message-ID:	<000101c1a18a$9c328580$c03dfea9@atlantis>
From:	"Matthias Paul" <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
To:	<opendos AT delorie DOT com>
References:	<000001c19e43$6c5b3a40$c03dfea9 AT atlantis> <000601c19f8f$55a06800$c03dfea9 AT atlantis>
Subject:	Re: More than 32 Mb of EMS memory
Date:	Sun, 20 Jan 2002 09:12:51 +0100
Organization:	University of Technology, RWTH Aachen, Germany
MIME-Version:	1.0
X-Priority:	3
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook Express 5.50.4522.1200
X-MIMEOLE:	Produced By Microsoft MimeOLE V5.50.4522.1200
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id g0K8GgY18067
Reply-To:	opendos AT delorie DOT com

Hi DR-DOS folks,

Further testing has revealing a few oddities and drawbacks:

I configured SemWare´s powerful editor TSE 2.50e for DOS
to utilize zero XMS, but up to 65535 Kb of EMS memory.

Running this under DR-DOS 7.03 EMM386 3.27 without /MULTI
and /DPMI worked like a charm, I was able to load files up
to the 64 Mb limit, shelling out and using EMS DIR showed,
that TSE was not using disk swapping and actually allocated
the EMS memory (one chunk for the file data of all files
combined).

However, trying to run a second instance of TSE soon bailed
out with an "out of memory" message, although I was still
able to allocate more EMS memory using the QEMM EMS.COM
utility.

Also, running TSE under DR-DOS EMM386 with either /MULTI or
/DPMI would hang the system if more than (8 Mb or) 16 Mb of
memory were allocated by TSE. At the moment, I don´t know
why this is, at least EMS.COM can still allocate larger
chunks without problems.

Using a RAM disk driver like TDSK which can use EMS, I was
able to allocate up to 32 Mb of EMS only, a second RAM
disk driver gave the "out of EMS memory" message.
This seems to have to do with the fact that DR-DOS EMM386
limits the available EMS memory to 32 Mb max and only 2048
pages at least for the INT 67h/43h LIM_ALLOC_PAGES call.
AFAIK, this is to work around problems with applications
(like the CheckIt! system test utility) which would not
work otherwise. Once the official 32 Mb EMS are allocated
the call returns that no more pages were available, although
they still are. But this keeps applications from trying
to allocate more. EMS.COM apparently uses INT 67h/5700h
and INT 67h/5A00h to do most of its job, this even works
without a predefined page frame (EMM386 /FRAME=NONE).

To summarize, there are a few oddities and compatibility problems
in the current implementation (which could certainly be fixed
or worked around), but the general idea of extending EMS beyond
32 Mb still stand. With minor changes in the implementation
(and maybe a switch to control the behaviour of the memory
manager at runtime), it should be possible to let most existing
drivers or programs which are totally unaware of such an extension
(even those which only support EMS 3.x and need a page frame to
map in their data), make use of the feature, just by providing
some kind of semi-infinite available EMS memory. I guess, once
they have successfully allocated some EMS memory, most drivers
will not care if there is actually more than a total of 32 Mb
allocated EMS memory floating around in the system.

I would be very interested in other ideas and experiences, also
with other memory managers...

Greetings,

 Matthias

--

<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org

- Raw text -