Date: Fri, 05 Feb 1999 16:23:44 +0100 From: Matthias Paul Subject: Re: DR-DOS Memory Maximizing? To: opendos AT delorie DOT com Message-id: Organization: Rechenzentrum RWTH Aachen X-Mailer: Pegasus Mail v3.22 Reply-To: opendos AT delorie DOT com On Thu, 04 Feb 1999 Bob Jonkman wrote: > > DEVICE=C:\OPENDOS\EMM386.EXE NOEMS DPMI=ON FRAME=NONE /V /R=AUTO /XMSUMB Depending on the drivers to be used, it might be a good idea to enable an EMS-frame by /FRAME=xxxx. For example, loading NWCDEX (or DRFAT32) in EMS takes much lesser memory than using DPMS. On most systems you will not need to sacrifice 64 Kb of UMB memory for the EMS page. If your ROM-BIOS has its setup utility at F000-F7FF, you can try something like the following: /USE=F000-F7FF /FRAME=E800 making a 64 Kb EMS frame available while using up only 32 Kb of UMB address space... I always have /DPMI=ON and /MULTI=ON enabled, but this depends on your configuration. It works very stable for me (using DR-DOS 7.03 BETA as of 12/1998). However, if you don't have DPMI applications and don't want to multitask, you can leave them off. > > DEVICE=C:\OPENDOS\DPMS.EXE Only load DPMS if NWCDEX, NWCACHE, SERVER, STACKER, LONGNAME (or DRFAT32) are actually using DPMS. If you don't need pre-emptive multitasking (see above), you can replace DPMS by CLOAKING which - at virtually the same memory footprint - provides a Cloaking server (e.g. for Logitech mouse drivers) *and* a Cloaked DPMS server, and can be loaded high. > > BUFFERSHIGH=40 > > FILESHIGH=40 > > ??? Are these new? I see nothing listed in the documentation about > these two commands. Besides more than a dozend other directives these too are both new since DR-OpenDOS 7.02 BETA2 (10/1997). However, BUFFERSHIGH= is only for compatibility with Microsoft's play on word on DR DOS original HIBUFFERS= directive. FILESHIGH= (HIFILES=) and FCBSHIGH= (HIFCBS=) are completely new and can be used to load all but 8 handles into upper memory, making third party tools for the same purpose obsolete (e.g. QEMM). Unfortunately they are still not documented, but you can find comprehensive details on these and other options in the README.TXT file of my (long outdated) IBMBIO ALPHA 3 package available from my web site (see footer). > > LASTDRIVE=Z > > LASTDRIVE is really only needed for Personal Netware. It's also needed for SUBST or redirector drives like with MSCDEX, NWCDEX (or DRFAT32). > > COUNTRY=1,,C:\OPENDOS\COUNTRY.SYS > > If you're running all US English programs on US English hardware you > probably don't need COUNTRY.SYS No, giving COUNTRY= (including the path to the COUNTRY.SYS file) in CONFIG.SYS has no impact on the memory footprint at all, since even an US English only system has to provide the necessary country data. COUNTRY= is used to override the default country, assumed hardware codepage, and country data with other data (stored in the COUNTRY.SYS file), but since there is currently only an US English kernel available, overloading that info with the already effective defaults does not change anything (at least if you use the standard COUNTRY.SYS file shipped with DR-DOS). In other countries, I strongly recommend to give the complete set of parameters with COUNTRY, like for example in Germany (here with Eurocurrency and DIN 28601 support): COUNTRY=21049,437,c:\drdos\country.sys BTW, since a few years Microsoft setup programs often replace the 437 by 850, the new "standard" codepage. However, since the hardware codepage of the video adapter obviously does not change (and still is 437), this setting is wrong, as the system now starts to mix up codepages 437 and 850 (assuming it would handle codepage 850 while actually codepage 437 is loaded). If you want to switch to codepage 850 the correct solution is to leave the hardware codepage as 437 here, load NLSFUNC and perform CHCP 850 in AUTOEXEC.BAT. This will avoid alot of problems with "invalid characters", especially using VFAT long filenames. Fortunately, under DR-DOS you don't need to worry of loosing too much memory by loading NLSFUNC since it takes less than a 1 Kb and by default will load into the HMA anyway. > > STACKS=9,256 Try STACKS=0,0. This may not work in all configurations (can cause crashes), but if it does, it saves memory. BTW, there are also HISTACKS= and STACKSHIGH= directives, but usually these will be assumed by default with DOS=HIGH,UMB. Aynway, for best results it would be best to optimize Dean's own configuration files rather than suggesting configuration options found on other systems... Matthias ------------------------------------------------------------------- Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany eMail: Web : http://www.rhrz.uni-bonn.de/~uzs180/mpdokeng.html -------------------------------------------------------------------