If you write and compile QuickBASIC applications OR if you are a user of a QuickBASIC compiled application, this is for you.
QuickBASIC compiled applications have a tendency to run out of memory with the Deskwriter. Usually that is because either the memory was not allocated correctly or not enough Finder memory (GetInfo) was allocated. If you are a user, only solutions 1, 2 and 3 are available to you unless you know the author of the program and can convince them to follow solution #4.
Solution #1: Use the HP Spooler. It uses High Memory instead of your application's memory and is lightning fast as well.
Solution #2: For older versions of HP drivers, SuperLaserSpool also does not require your application's memory.
Solution #3: Increase Finder memory allocation (GetInfo) by about 250K. If that works, you're home free. If it doesn't, then the problem is within the program itself and you might as well set the memory allocation back and follow another option.
Solution #4: If you wrote the application yourself, read my article about QuickBASIC memory management in Ariel Publication's "Inside Basic" (late 1992). You can order that issue (or better yet subscribe and back date to any pervious issues you wish) by calling 509-923-2249. Ask for Ross and mention me. He'll fix you up.
Here is the text only version of the memory article:
Handle Your Memory
before…
It Handles You
by Ray DiBugnara
Semicon Components, Inc.
If you think that a heap-stack collision has something to do with Archie’s old jalopy in farmer Tuttle’s hay field, this article is for you!
All applications occupy finite memory space and must allocate that space with some degree of precision or else the data stack and the application heap may collide and the computer bombs! This, of course, refers to the infamous Bomb Box and/or everything locking up, going fuzzy, crackling like the sound of melting computer chips and, unfortunately, your valuable data being dispatched to RAM heaven.
QuickBASIC gives you some of the answers you need with its “FRE(n)” statement but, alas, I find that it’s a bit lacking and the QB manual very vague at best. Many QB’ers just program away hoping that the “basic” in BASIC language forgives them of any programming indiscretions and that their memory problems will just remain “a memory”.
The Macintosh, however, can supply all (and more than all) the information you will need to make your applications run like you know what you’re doing (even when you don’t). All you need is a little knowledge on the subject. Knowledge is power! (A 4MB upgrade doesn’t hurt either.)
I have included a simplified Application Memory Map which gives you all the locations you need to worry about. Below that diagram are listed the memory locations to “PEEKL()” into for that information.
What ever you do, don’t “POKE” anything into these locations unless you enjoy the sense of discovery, the fireworks of a spectacular crash and the smell of burning plastic (I exaggerate for effect)! The following map applies to a compiled application:
(Sorry…the map didn't paste but each sector is arrayed as shown in the list below)
applTop#=currentA5#+32+144
currentA5#=PEEKL(&H904)
curStackBase#=PEEKL(&H908)
applLimit#=PEEKL(&H130)
heapEnd#=PEEKL(&H114)
applZone#=PEEKL(&H2AA)
The returned memory values read from highest location (applTop#) to lowest (applZone#). You won’t necessarily need them all but it’s nice to know where they are. The value “currentA5#” is a pointer within the global section.
When running in the QB Interpreter mode, only the FRE(n) statements return useful information to your program. From here on, a fully compiled QB application is assumed.
unUsedData# = FRE(0)
unUsedHeap# = FRE(-1)
unUsedStack# = FRE(-2)
By the way, while these numbers are all supposed to be returned as long integers (2^31 max), bugs in the QB compiler cause overflow errors with values much smaller than that so machines with more than 4MB of RAM may have problems. Use the double precision variables to be safe and send letters to Microsoft (and your congressman if you think it will help) to expedite QuickBASIC 2.0! Convert back to long integer for the CLEAR statement, however.
Steps to Managing your Memory
Step 1: How much data space do I need?
Every time any variable is DIMensioned, you use up Data space. Any variable or array not DIMensioned but used anyway still uses up Data space.
Data bytes to reserve for variables:
% = 2 & = 4 ! = 4
# = 8 $ = 12 + 1/character
Strings use a minimum of 12 per element but, as they fill up, take more and more space. For example:
alpha$="" takes up just 12 bytes of data.
alpha$="0123456789" takes 10 + 12 bytes.
alpha$="" recovers the 10 extra bytes.
alpha$(10) requires 120 bytes just for starters.
alpha$=fatAlpha$ makes 2 fat alphas.
You must calculate or, at least, estimate the amount of data space you will require. Then add 10K because I bet you forgot the…!
Add up all these data requirements and call that total:
dataSpaceNeeded#
Step 2: How much unused heap is needed?
Unused heap is where many DA’s and printer drivers reside. Ever have a Laserwriter or Deskwriter complain that there’s not enough memory? Worse yet, ever have one not even give you the decency of a complaint?
Now, I call this region “unused” because it wasn’t used originally by your application until it got used (huh?). Sooner or later, though, it’s going to be used by one of the memory sucking little utilities that makes the Macintosh so much fun to use.
Besides DA’s and the like…this region is also where all your EDIT FIELD declarations reside. (You too can be a memory sucker.) For each EDIT FIELD declaration you will need in bytes:
12 + 1/character...but 196 minimum
An edit field with 1000 characters takes up 1012 bytes while an edit field with 12 characters uses 196 bytes. Remember: if your edit field has just had 5000 bytes typed into it, when you save that using:
saveEditField$=EDIT$(n)
The string saveEditField$ will now also contain 5000 bytes of text which directly subtracts from the data space as well. In this example, a total of 10000 bytes are now kept busy.
An edit field can contain about 32000 bytes (2^15 less overhead)…the same as a string variable. You need to make a knowledgeable guess as to how much space to reserve. I like to reserve as a default 256 bytes because 256 = 2^8 and that sounds like real heavy computer lingo.
After adding up all your edit field requirements, allow at least another 100000 bytes for drivers and DA’s. More if you want bullet proof operation with top heavy System Folder “portfolios.” Call this total:
unUsedHeapSpaceNeeded#
Step 3: How much Stack space do I need?
Now that’s a good question. Your application will seldom need more than the default value (about 14000) but…do you want someone else deciding this for you? Besides, some library and MBLC codes require stack space as do some other piggyback utilities such as spelling checkers, etc.
Also, if you CHAIN to other modules, the stack must be large enough to pass on the largest STORAGE entry too. If you keep getting Error 7 at the CHAIN statement, you need more stack space. To find out how much more, re-compile the application with “Create Program List File” option turned on. Then examine that list under STORAGE in the Symbol and Label Tables looking for MAIN. Your main module needs to clear enough extra stack space for the largest STORAGE entry.
FRE(-2) tells you only how much stack is unused, but, combined with stackUsed#, you can get the total stack picture:
stackUsed#=curStackBase#-applLimit#
Unless we’re CHAINing, we’ll just make things easy on ourselves and let:
stackSpaceNeeded#=36000#.
Step 4: How much code space do I use?
There is no direct readout of how much space your application code takes since the heap pointers don’t see the divider between the code space and the data space.
If you “sink” a test CLEAR to get, if you pardon the pun, a “core” sample, you can find this out easily.
CLEAR,10000&,10000&
codeSpaceNeeded#=heapEnd#-applZone# -10000#
The 10000# of course is the data space we reserved with the CLEAR so the rest of the used heap must be application code. This only works accurately if no variables have been declared yet.
Step 6: How much Globals space is taken?
Not much actually. If you want, you can just ignore this space. However, if you’re a real computer nerd, you’ll include it. This region includes the jump table, application parameters, application globals and QuickDraw globals. Just call it globals and be done with it:
globalSpaceNeeded#=applTop#-curStackBase#
Step 7: How much room do I have?
When you set the size for an application in the Finder (using Get Info), you allocate how much space your application will get. If you are not using Multifinder or System 7, then your application will get all the remaining RAM.
Applications you wrote that worked fine without Multifinder might run out of memory in Multifinder because, instead of getting all the RAM there is, you now only get all the RAM that the compiler thought you needed. Usually it’s right too unless you trick it with big arrays, etc.
Your application needs to know how much memory it has. Now a word of caution: the Finder’s Get Info size is in long bytes instead of short bytes where: 1,000K long bytes equals 1024K short bytes. The West Coast tends to prefer the fatter long bytes while the East Coast gravitates toward the leaner short bytes. (So does you computer by the way.)
Actually, Apple felt they needed to round things off because 1000K looks a lot more tidy than 1024K. Exactly how they explain away that 783K looks better than 802K I’ll never know.
From the Application Memory Map, the total memory your application has to fondle is (in East Coast short bytes):
totalApplSpace#=applTop#-applZone#
Now, you could stop the program right here if you already knew there wasn’t enough space (you “hard wired” a minimum value right into your program) and exit with an alert, etc.
If, on the other hand, you are going to dynamically size your data arrays and/or unused heap based upon available memory like the pros do, then you will want to make some decisions.
Add It All Up…
globalSpaceNeeded#
stackSpaceNeeded#
unUsedHeapSpaceNeeded#
dataSpaceNeeded#
codeSpaceNeeded#
TOTAL: totalApplSpaceNeeded#
If totalApplSpace#>totalApplSpaceNeeded#, life is treating you well. You can take the extra space and add it to dataSpaceNeeded# to dimension larger arrays and/or you can add it to unUsedHeapSpaceNeeded# (by not adding it to dataSpaceNeeded#) to speed up printing, etc. If the data space doesn’t get it, then the unused heap space automatically will.
dataSpaceNeeded&=CLNG(dataSpaceNeeded#)
stackSpaceNeeded&=CLNG(stackSpaceNeeded#)
CLEAR,dataSpaceNeeded&,stackSpaceNeeded&
If there is not enough data space, put up an Alert telling the user how much more memory is needed and then quietly exit.
A word about CLEAR. In the QB Interpreter (called the Environment for some strange reason), there is no life after CLEAR! CLEAR erases all RETURN’s, WEND’s, etc. so if a CLEAR is in a subroutine, you will never find your way back unless the program is compiled first. (So that’s why I got a RETURN without GOSUB error!) Moral is; put CLEAR’s at the beginning of the program. If you should need any of the pointers after CLEAR, you have to fetch them again since they were cleared as well.
Another word about ERASE. This is an incredible tool for reducing memory space or re-sizing arrays. When you are finished with a dynamic array, just erase it and you get back all that data space. (Just try that one ZBasic!)
Conclusion
Well, there you have it (I think). Memory “mangle-ment” made easy. (Well, at least possible.) If all this seems such a pain, then just reserve 1000K in the Finder and CLEAR,400000&,40000& and be done with it. When you are ready to publish your application, drag out this article again and then clean up the memory.
The following SUB() can be used to show you your memory status at any time by making calls to it. The Option key activates it when a call is made to it otherwise it is ignored:
CALL ShowMemory("This Is A Sample Title Listing")
END
SUB ShowMemory(title$) STATIC
'•Version 0.40 by Ray DiBugnara, Bolton, MA
'•Title$=short string to be displayed on first line of display
' If option key is held down while call is made to ShowMemory, it does.
IF (PEEK(379)<>4 AND PEEK(379)<>6) THEN EXIT SUB 'looking for option key
