X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f Message-ID: <000601c19f8f$55a06800$c03dfea9@atlantis> From: "Matthias Paul" To: References: <000001c19e43$6c5b3a40$c03dfea9 AT atlantis> Subject: Re: More than 32 Mb of EMS memory Date: Thu, 17 Jan 2002 20:16:56 +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 g0HJhOT00590 Reply-To: opendos AT delorie DOT com On 2002-01-16, I wrote: > However, if you load a 3rd party XMS-provider which detects more > than 64 Mb of memory, the DR-DOS EMM386.EXE will also be able to > handle more memory and provide this as EMS from a shared pool > with XMS memory. > For example, if you load the MS-DOS 7.10 HIMEM.SYS before the > DR-DOS 7.03 EMM386.EXE, HIMEM.SYS will detect more than 64 Mb of > memory (256 Mb on my system) and provide this as XMS memory. > DR-DOS EMM386.EXE will then happily take over this memory and > provide means to allocate up to this much memory as VCPI or EMS > memory in chunks with up to 64 Mb each. Using the QEMM EMS.COM > utility I just tried this up to ca. 250 Mb EMS memory on my system, > but I guess even more would be possible on a system equipped with > more physical memory. The last two sentences were not correct... I thought the allocation limit would be 64 Mb per handle, but this was only my first impression due to the faulty display of the EMS.COM tool (from QEMM 7.50) which I was using to test this. (For those who don´t know, EMS.COM is not any kind of memory manager, I´m still using DR-DOS EMM386 to provide EMS memory, of course. EMS.COM is just a small tool which can be used to list the currently allocated handles ("EMS DIR"), or allocate new handles ("EMS CREATE handle_name size"), etc. It also provides options to load and save the contents of an EMS handle from/to a disk file.) Using only the physically available memory on my machine (256 Mb), I was able to allocate EMS memory in multiple chunks up to this limit (240 Mb actually here), or even with a single call with up to 240 Mb in size. Mind again, that the original EMS 4.0 specification maxes out at 32 Mb total and 32 Mb max per handle. I ran a few simple "stress tests" like: EMS LOAD test1 d:\tmp\srcfile.img EMS SAVE test1 d:\tmp\dstfile.img FC /B srcfile.img dstfile.img with srcfile.img being various files with up to 240 Mb in size. Due to the 16 Kb granularity of EMS allocations, the resulting file dstfile.img might become up to 16383 bytes larger than the srcfile.img file, but it is easy to accomodate this for the test. Of course, I tried various combinations of such tests and so far it always returned the data unaltered, that is, DR-DOS EMM386 is actually able to correctly handle EMS allocations with more than 32 Mb per call, and with much more than 32 Mb of total EMS memory allocated. Going further, I used Marko Kohtala´s XMSSIZE 1.00 utility (part of the distribution of his resizeable RAM disk SRDISK 2.08) to make MS-DOS 7.10 HIMEM.SYS - which I load before DR-DOS 7.03 EMM386.EXE 3.27 - believe, that I would have short to 2 Gb of physical memory installed, although I have not. (BEWARE: Memory is still allocated from the bottom up, so you will not normally see it crashing immediately, but you should never forget that the memory is not physically there, so this can be used to range check the implementation, but not to check the data. Be extremely careful and never use any disk cache while running these tests, and go back to a valid setup ASAP.) Faking a 2 Gb system, I was able to allocate all this memory through the DR-DOS EMM386 EMS API. As I predicted from the EMS 4.0 specification, the maximum possible allocation per chunk was 1 Gb (FFFFh pages a 16 Kb = 1.073.725.440 bytes). Since I only had less than 1 Gb free space on disk, I experimented with two 900 Mb chunks instead: EMS CREATE handle_a 900M EMS CREATE handle_b 900M EMS SAVE handle_b d:\tmp\dstfile.img (volume must have enough free space or system will crash!) Of course, the contents of the DSTFILE.IMG file is worthless, because the corresponding memory does not physically exist, but this simple tests leads to the strong assumption that EMM386.EXE is actually able to handle such large chunks of EMS memory without problems. I was not able to increase the size of the faked memory beyond the 2 Gb limit. If I tried, EMM386 rebooted when loading. This could indicate that some kind of signed arithmetic is used by EMM386 internally, which overflows at 2 Gb instead of the physical limit of 4 Gb, but it could also be a problem elsewhere, for example in the chipset (Intel 430HX) or the mainboard implementation (missing address wire?). The mainboard (ASUS T2P4 Rev.3.10 from 1997) is designed to only handle up to 512 Mb of physical memory, so I cannot be sure about it. Maybe someone with a newer board and/or more physical memory installed can try and push the limit up to the CPU´s limit of 4 Gb and test the DR-DOS EMM386 EMS implementation under these conditions (it should allow to allocate up to 4 handles with almost 1 Gb associated EMS memory for each of them :-)? BTW. The per-task-limit under the multitasker remains at 64 Mb total memory (EMS+XMS), but still beyond the original EMS 4.0 specification. Finally a few more notes for those who want to experiment, just because the DOSBOOK documentation is partically misleading in regard to EMS support: EMM386 FRAME=NONE will *not* disable EMS, it will only disable the 64 Kb page frame. Most drivers and applications need the frame to map in their EMS data, and will not be able to use EMS with FRAME=NONE. However, since EMS 4.0+ it is possible to temporarily map in a 16 Kb page (almost) anywhere else (for example at an 16 Kb boundary inside the application itself). Only very few applications make use of this, QEMM´s EMS.COM appears to be one of them, because you can still allocate and load/save disk data to/from allocated EMS handles while using FRAME=NONE. A few environments like DESQview and Windows 3.x are known to be able to make use of this as well and map in EMS memory elsewhere, even below 640 Kb. To completely disable EMS, you must specify the NOEMS option. AFAIR this will also disable VCPI. Experimenting with memory allocations under the multitasker some may also want to change the default setting, which makes all allocations before the multitasker global and all allocations made inside each domain under the multi- tasker local, so that they are automatically freed when killing a task - even if the running applications forget deallocating the memory themselves. There are two undocumented DR-DOS EMM386.EXE options named /EMS=AUTO|LOCAL|GLOBAL and /XMS=AUTO|LOCAL|GLOBAL If you set them to GLOBAL, allocations made inside a task will not be freed automatically and will remain allocated even when exiting the multitasker. One possible use for this is when you want to resize a RAM disk under the multitasker (assuming the RAM disk driver does not block this under a multitasker). Greetings, Matthias -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org