Microsoft KB Archive/35626

= Memory Map Correction for Mac QuickBASIC Compiled Applications =

Article ID: 35626

Article Last Modified on 1/9/2003

-

APPLIES TO


 * Microsoft QuickBasic Compiler for Macintosh 1.0

-



This article was previously published under Q35626



SUMMARY
This article provides a corrected and more detailed memory map for applications compiled by Microsoft QuickBASIC Version 1.00 for the Apple Macintosh.

This update/correction applies to Appendix F, &quot;Memory Usage,&quot; on Pages 527-529 of the &quot;Microsoft QuickBASIC for Apple Macintosh: BASIC Language Reference&quot; manual.



MORE INFORMATION
If you are having trouble using the CLEAR statement to enlarge the stack or data areas to eliminate &quot;Out of Memory&quot; messages or other memory problems, you should base the arguments for the CLEAR statement on the values returned by the FRE(n) function (at run time), instead of specifying absolute numbers. There should only be one CLEAR statement per program.

Note that you should not assume that the screen and sound buffers will be in any specific location, since this may change in future implementations of the Macintosh hardware or operating system. In addition, you should not assume that the memory for the buffers is contiguous with the application space, the stack, and the application heap. In the future, the stack may move as well.

The following is the revised Macintosh memory map:       *******  Overall Macintosh Memory Map  *******

OS-dependent--> ++ | Screen and Sound Buffers  | ++

High Memory --> +-+ |     ROM Support            | |  Segment jump table        | +-+               |      Quickdraw Globals      | register(a5)--> +-+ |   Application Globals      | +-+               |                             |                |       Stack                 | :                            :                :.............................:                :                             :                |       Heap                  | |                            | Low Memory--->  +-+

The stack is stored in high memory, as shown in the memory map below. The stack in highest memory is set at compile time, and contains main program variables, variables in SHARED statements, variables in COMMON, and array descriptors. The remainder of stack is used dynamically at run time for GOSUB statements and subprogram calls.
 * Memory Map for a Macintosh QuickBASIC Compiled Application ****

The statement CLEAR,, changes StackLimit (StackLimit is shown in the map below). The stack grows downward in memory. If the stack pointer goes below StackLimit, an &quot;Out of Memory&quot; error should be reported; however, the stack overflow can go undetected if you compile without the &quot;Check Arrays and Overflow&quot; option.

FRE(-2) returns the value of CurrStack minus StackLimit, where CurrStack is the current value of the dynamic stack at the time FRE(-2) is invoked. The value returned by FRE(-2) is only an estimate, since the stack changes from moment to moment.

When dynamic subprograms are active, there is another link frame for each active invocation of a dynamic subprogram below the one link frame for the main program. Each additional link frame contains the local variables for the dynamic subprogram. High-> +---+  <+ Memory         |   Common Variables            |       | |                              |       |       +->  |...............................|    Main/SHARED |       | Other main program variables: |      program one link   |  All simple variable data,    |     variables frame     |    static arrays, string      |     in fixed |       |   descriptors, and array      |   block in Stack |       |        descriptors. |      |       |        |                               |       |       +->  +---+  <+                :                               :                :     Dynamic Stack     : :                              : CurrStack>  :...............................: :                              : StackLimit  --> :...............................: :                              : The heap comes next in memory, as shown below. A number of blocks are allocated out of the heap. The relative location of one block to another in the heap is unpredictable since they are allocated by the Macintosh Memory Manager, but the ordering of the blocks tends to be as shown:                :                               : Top (End)     :                               : of Heap >:...............................: :                              :                :    - Free Heap -      : :                              : The statement CLEAR , changes the size of the compiled program's Data block (shown below). You get an &quot;Out of Memory&quot; message at run time if the value for  would deallocate some of the compiled program's machine code. The area that remains over after Data and Stack space are allocated is available for heap space.                :                               : +---+ <--+                |    String space & DATA        |     | |...............................|    |  Compiled | File Buffers & Array Contents |    |   BASIC |...............................|    |-- Data |      Machine code for        |     |   block |      compiled program        |     | +---+ <--+                :                               : Note that the Static Subprogram Storage and BASIC Run-time Library Private Storage blocks (shown below) are just one block in the earlier Microsoft BASIC Compiler Version 1.00. In QuickBASIC compiled programs, they are split for better memory management during CHAIN and RUN:                :                               : +---+               |   Static Subprogram Storage   | |       block                  | +---+               :                               :                +---+                |  Block for BASIC Run-time     | | library private variables    | +---+               :                               : The Run-time Library block (shown below) is allocated by a GetResource(MBRL) call from the program's initialization code during startup before the program starts executing:                :                               : +---+               |   Run-time Library            | |  machine code block          | +---+               :                               : The Initialization block (below) is loaded when the compiled application is launched. The code that handles the MBPN (File Not Found) processing is also in this block:                :                               : +---+               |  Initialization machine code  | | block (CODE resource ID = 1) | +---+               :                               : Bottom of  ---> +---+ (start of) Application Heap. Low memory. Libraries, MBPC resources, CODE resources, MBLC resources, and other Macintosh objects (resources and toolbox data structures) are allocated as necessary in any portion of the heap that is free. In the above memory map, free memory could be in any of the areas not marked as a &quot;block.&quot;

FRE(-1) returns the total number of bytes not being used by these blocks and not used by other Macintosh objects. You CANNOT assume that there is one big block of size FRE(-1) because the free memory can be interleaved with locked blocks. FRE(-1) will cause the Memory Manager to compact the heap as much as possible before returning the total available memory. See Inside Macintosh for more information about the Macintosh Memory Manager.

FRE(n), where n is not equal to 0 or 1, returns the number of unused bytes in the BASIC data block. Of course, the machine-code portion of the block is never free. FRE(n) accurately reflects the amount of space available for new strings, dynamic arrays, and file buffers.

Additional query words: MQuickB

Keywords: KB35626

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.