Microsoft KB Archive/101880

Knowledge Base

How to Increase Free Near Heap to Work Around 'Out of memory'

Article ID: 101880

Article Last Modified on 8/16/2005

---

APPLIES TO

• Microsoft Visual Basic for MS-DOS
• Microsoft BASIC Professional Development System 7.0
• Microsoft BASIC Professional Development System 7.1
• Microsoft QuickBasic 4.0
• Microsoft QuickBASIC 4.0b
• Microsoft QuickBasic 4.5 for MS-DOS

---

This article was previously published under Q101880

SUMMARY

This article gives suggestions on how to work around the following errors:

Out of memory (code 7)
Stack plus data exceed 64K (L2041)

These suggestions apply to both interpreted and compiled programs.

MORE INFORMATION

Diagnosing Near Heap Depletion

The error "Out of memory" happens when you run out of either near heap or far heap space. Usually, you run out of near heap space. Determine which area is depleted by printing out the amount of free space in each area as shown below:

   ' show number of free bytes far heap:
   PRINT FRE(-1)
   ' show number of free bytes near heap:
   PRINT STACK    ' for VB-DOS and Basic PDS
   PRINT FRE(0)   ' for QuickBasic
                

If you find that you have the same amount of free hear and far heap space, far heap is depleted. You should print these values as near as possible to the point in your program immediately before the "Out of memory" error occurs.

Increasing Free Near Heap

Add the REM $DYNAMIC (or '$DYNAMIC) statement to the top of each module and form. This statement allows you to change the number of elements in your arrays at run time (by using REDIM). Even more important, the statement causes the arrays to store in far heap rather than near heap. Arrays of variable-length strings are an exception; they are always in the near heap whether or not they are dynamic.

   DIM a(1000) AS INTEGER  ' static array, stored in near heap
   REM $DYNAMIC
   DIM b(1000) AS INTEGER  ' dynamic array, stored in far heap
                

Convert arrays of variable-length strings into arrays of fixed-length strings to allow REM $DYNAMIC to store this data in far heap. For example:

   ' example arrays of variable-length strings
   DIM a$(2000)
   DIM b(2000) AS STRING
   ' example array of fixed-length strings, up to length 16 each
   DIM c(2000) AS STRING * 16
                

Use the RTRIM$ function to remove trailing spaces from fixed-length strings when you retrieve them from the array. For example

   a$(1) = "hello"
   PRINT "<" + a$(1) + ">"          ' prints <hello>
   c(1) = "hello"
   PRINT "<" + c(1) + ">"           ' prints <hello   >
   PRINT "<" + RTRIM$(c(1)) + ">"   ' prints <hello>
                

Using fixed-length arrays typically increases the storage required for each string because space is reserved for the maximum possible length. If you require an array larger than 64K, invoke the interpreter or compiler with the /Ah option. Otherwise you receive "Subscript out of range," error 9.

VBDOS /Ah -- Visual Basic for MS-DOS
QBX /Ah -- Basic PDS
QB /Ah -- Microsoft QuickBasic
BC /Ah ... -- compiler for all 3 products

If you require an array larger than 128K, specify the length for each string in the array as a power of 2 (2, 4, 8, 16, 32, and so on). otherwise you receive the error "Subscript out of range."

   DIM a(8000) AS STRING * 17  ' causes error "Subscript out of range"
   DIM b(8000) AS STRING * 16  ' okay
                

Create arrays of one element out of large variables that are not already arrays and are not variable-length strings. This causes REM $DYNAMIC to store them in far heap rather than near heap. User defined type variables and fixed-length strings are good candidates. For example,

    TYPE aType
      s AS STRING * 1000
      a(100) AS LONG
   END TYPE
   DIM t1 AS aType              ' stored in near heap
   t1.s = "hello"
   PRINT t1.s
   DIM t2(0) AS aType           ' stored in far heap
   t2(0).s = "hello"
   PRINT t2(0).s

   DIM f1 AS STRING * 2000      ' stored in near heap
   DIM f2(0) AS STRING * 2000   ' stored in far heap
                

After adding REM $DYNAMIC to a support module (a .BAS file other than your start-up file), you may encounter a side effect problem with the symptom of error "Subscript out of range." This happens on arrays defined with DIM SHARED at the module level of a support module. Similarly, after adding REM $DYNAMIC to a form, you may encounter the error "Executable code not allowed in module level of a form." These errors are due to REM $DYNAMIC changing DIM SHARED from a compile-time statement to a run-time statement for arrays.

To work around the "Subscript out of range" side effect problem, define the array at the module level and allocate the array in a SUB or FUNCTION. Use a STATIC variable to keep track of whether the array has been allocated. For example:

    REM $DYNAMIC
   DIM SHARED b() AS INTEGER

   SUB s ()
      STATIC is_alloc AS INTEGER
      IF NOT is_alloc THEN
         DIM b(1000) AS INTEGER
         is_alloc = -1  ' true
      END IF

      b(100) = 123
      PRINT b(100)
   END SUB
                

To work around the Visual Basic error "Executable code not allowed in module level of a form," define the array at the module level and use REDIM to allocate the array from the Form_Load event handler.

Additional query words: VBmsdos QuickBas BasicCom B_VBmsdos 1.00 b_basiccom 7.10 b_quickbas 4.50

Keywords: KB101880

---

Send feedback to Microsoft

© Microsoft Corporation. All rights reserved.