Xref: news2.mv.net comp.os.msdos.djgpp:943 From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: cwsparam parameter meanings Date: Fri, 09 Feb 1996 10:36:49 CST Organization: Rice University, Houston, Texas Lines: 38 Message-ID: <311b7821.sandmann@clio.rice.edu> References: <311aca97 DOT sandmann AT clio DOT rice DOT edu> Reply-To: sandmann AT clio DOT rice DOT edu NNTP-Posting-Host: clio.rice.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp > My users will, when I make my next release, have the option of running their > favorite text editor from within my program. > Hardly anyone knows how much memory their editor requires, so it seems > necessary to either set the DOS memory to a fairly large value, or to > experiment to see how small it can be. Would the following work? > > 1. Set the minimum application memory desired before 640K paging to more than > physical memory to force paging immediately. > 2. Have the application ask for 640K of memory to guarantee that all the > pageable DOS memory gets used. > 3. Attempt to run the editor and see if it fails for lack of memory. No, this won't work, since in this case it won't save much DOS memory at all. With the configuration described above, CWSDPMI would figure out it was supposed to DOS memory page, but then see it couldn't satisfy the DOS memory saving request. At that point it would not save ANY DOS memory (so the saved paragraphs drops to what's left over after allocating 4k aligned memory). It does a static allocation, and figures it should provide DPMI memory first and DOS memory second (since maybe the app can run in a degraded fashion without the DOS memory - ie it couldn't spawn a shell or an editor). If you know that users may run some arbitrary program, I would probably put the saved DOS memory at something like 256Kb (ie 16384 paragraphs) and leave the minimum application memory at 256K. In this case, if the user has more than 256K extended then you let them run an arbitrarily fat editor (no extra DOS memory usage by CWSDPMI). If they have less than 256K of extended memory free then they get about 1/2 the DOS memory to run the 32-bit program in. Paging causes performance to potentially suffer on machines with not enough extended memory, but that's life. Another possibility would be to distribute with the default, but if their editor won't load in the 60K the default gives, have them increase the number of paragraphs by 1000 or so and try again. While it would have been possible to try and make CWSDPMI more smart about these things and auto configure, it just wasn't worth the effort. Users with less than 4Mb machines really can't expect great performance without tuning. The goal was to get GCC to run on a machine with no extended and only 256K free DOS memory (however slowly) and DJGPP/CWSDPMI should be able to do that with the current setup.