ID Number: Q72879
1.00
WINDOWS
Summary:
The following memory limitations apply to Microsoft Visual Basic
programming system version 1.0 for Windows.
Note: This information only applies when running the retail version of
Microsoft Windows version 3.0 or 3.1. Different memory limitations may
apply when running Visual Basic under the debug version of Windows
provided with the Microsoft Windows Software Development Kit (SDK).
More Information:
Each Function, Sub, or event procedure can have up to 64K of
pseudocode (pcode).
Visual Basic 1.0 is limited to about 1300 procedures per application
(or project). If you exceed this limit, Visual Basic may drop you back
to the last edited procedure, or may possibly terminate and return you
to Windows.
Memory for data and controls is allocated separately from pseudocode,
as described further below.
How an .EXE Loads Its Forms and Code into Memory
------------------------------------------------
When you run a Visual Basic .EXE file, the application starts out by
immediately loading the following items into memory: the startup form,
the code in all the modules, and the code behind all the forms. Even
if your application code never loads the form itself, it will load the
form's code. This is part of the reason why large Visual Basic
applications may take a little longer to start than some other
applications.
The application uses a Load or Show statement to load forms other than
the startup form, and uses an Unload statement to unload forms. When
the application unloads a form, it unloads the form and its controls,
but not the associated code. You cannot swap parts of code out of
memory. The only swapping possible is the automatic page swapping
Windows does in enhanced mode.
Arrays
------
Each array of any data type at any level (local or global) gets its
own data segment, up to 64K in size. Arrays larger than 64K cause a
"Subscript Out of Range" or "Overflow" error.
Huge arrays (arrays larger than 64K) are not directly supported in
Visual Basic, but you can support huge arrays through the use of a
Windows dynamic link library (DLL). For more information about support
for huge arrays, query on the following words in the Microsoft
Knowledge Base:
huge and array and DLL
Form Level or Module Level Variables
------------------------------------
In the general Declarations section of a form or module (that is, at
the form or module level), all of your variables, except for arrays,
are placed together in one 64K data segment.
Local Level Variables
---------------------
In event, Sub, or Function procedures (that is, at the local level),
all non-static variables are placed on the project's stack at run
time. The project's stack can be up to 16K in size. You will get an
"Out of Stack Space" error at run time if the stack exceeds 16K. At
the local level, you can keep variables off the stack by allocating
them with the Static statement (or you can use module level, form
level, or global level variables).
Local variables in all event, Sub, and Function procedures in the
whole project share the same 16K stack at run time. Using fixed length
local strings, or nesting procedure calls, can quickly consume this
stack space. If you need to use local fixed length strings, you can
save stack space by allocating them with the Static statement (or else
declare them at the module level, form level, or global level).
Global Level Variables
----------------------
In the global module, your program gets one 64K data segment for
simple (non-array) global variables. (Global fixed length strings are
stored in this 64K data segment.) You will get an "Out of Memory"
error if you exceed the 64K data segment for simple variables in the
global module.
For more information about the scope of variables (local level,
form/module level, and global level scope) see pages 84-86 of the
"Microsoft Visual Basic: Programmer's Guide" version 1.0 manual.
Memory Used by Controls and Properties
--------------------------------------
Note that in the discussion below, each menu item that you design into
a Visual Basic program is considered as a separate control.
The properties for all controls on a form and the properties of the
form itself go into a single data segment limited to 64K bytes, except
the following:
- List property of a list box
- List property of a combo box
- Text property of a text box
The List property gets its own data segment, limited to 64K bytes,
for each list box and combo box. The Text property of a text box has a
default size limit of 32K, which can be increased to 64K with a call
to a Windows API function.
A list box is limited to 5440 items or 64K total size, whichever comes
first.
Other memory limits relating to the properties of controls and forms
include:
- Each item in the List property can be up to 1K in size; any item
over this limit is truncated.
- The Caption property of a control can be up to 1K in size, any
caption over this limit is truncated.
- The Tag property of a control can be up to 32K in size, any tag
over 32K causes an "Out of Memory" error.
There is one name-and-symbol table up to 32K in size per form, module,
or global module. A name-and-symbol table contains the actual text of
Sub function and Sub procedure names, variable names, line numbers,
line labels, and an additional 4 bytes overhead for each of these
names and symbols.
If the 32K size limit is exceeded for a name-and-symbol table, an "Out
of Memory" error will occur. To solve this, break up the form or
module into multiple forms or modules. (Note: You cannot do this with
the global module; only one global module is allowed. If you exhaust
the global module's name-and-symbol table, there is no workaround
other than to use shorter variable names.)
The stack is 16K in size, with just one stack per application. The 16K
stack size cannot be changed. Note that an "out of stack space" error
can easily occur when your program uses uncontrolled recursion.
Memory Limits May Differ Under the Debug Version of Microsoft Windows
---------------------------------------------------------------------
If you run Visual Basic on the debug version of Microsoft Windows
provided with the Microsoft Windows SDK, all properties (including
List and Text properties) go into a single segment, up to 64K in
size per form or module. Other memory management limits may also
differ under the debug version of Windows. The debug version of
Windows is created by copying a set of dynamic link library (DLL)
files from the Windows SDK into your \WINDOWS\SYSTEM subdirectory.
These special DLLs perform additional error checking, including a
check for stack overflow.
Example 1: "Out of Stack Space" for Local Non-Array Variables
-------------------------------------------------------------
In the Form_Click event procedure, place the following code:
Dim a As String * 4096
Dim b As String * 4096
Dim c As String * 4096
Dim d As String * 4096
These brief statements together are enough to cause an "Out of Stack
Space" error at run time. This shows that using large fixed length
strings consumes stack space quickly.
If you place the above four statements in the general Declarations
section, no error occurs, because in that case the variables are
placed in the 64K data segment for the form (instead of in the stack).
Example 2: Using Static Statement to Avoid "Out of Stack Space"
---------------------------------------------------------------
In the Form_Click event procedure, place the following code:
Static a As String * 4096
Static b As String * 4096
Static c As String * 4096
Static d As String * 4096
You will NOT get an "Out of Stack Space" error with only these
statements in a new project by themselves. This shows you that fixed
length strings that are static do not go on the stack.
Example 3: Local Arrays Can Have Up to 64K Each
-----------------------------------------------
In the Form_Click event procedure in a new project, place the
following code:
ReDim ar1(32000) As Integer
ReDim ar2(32000) As Integer
ReDim ar3(32000) As Integer
ReDim ar4(32000) As Integer
These statements will not give an error at run time. Each array
allocated locally in the procedure is given its own 64K data segment,
and each array almost completely fills its 64K data segment. (Each
integer takes 2 bytes of memory.)
You will exceed 64K bytes and get an "Overflow" error message if you
dimension the array with a subscript of 33000. Using a subscript of
32765 gives a "Subscript Out of Range". 32750 works without error.
Example 4: "Out of Memory" in Global Module
-------------------------------------------
In the GLOBAL.BAS module, place the following code:
Global a As String * 4096
Global b As String * 4096
Global c As String * 4096
Global c As String * 4096
Global d As String * 4096
Global e As String * 4096
Global f As String * 4096
Global g As String * 4096
Global h As String * 4096
Global i As String * 4096
Global l As String * 4096
Global j As String * 4096
Global k As String * 4096
Global m As String * 4096
Global n As String * 4096
Global o As String * 4096
Global p As String * 4096
This will produce an "Out of Memory" error. This shows that the global
module only gets one 64K data segment for non-array variables. (Arrays
each get their own 64K data segment.)
Additional reference words: 1.00