X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f Message-ID: <000101c1a18a$9c328580$c03dfea9@atlantis> From: "Matthias Paul" To: 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 Content-Type: text/plain; charset="iso-8859-1" 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 Content-Transfer-Encoding: 8bit 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 -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org