Q88991: Visual Basic for MS-DOS: Memory Management Questions & Answers
Article: Q88991
Product(s): Microsoft Visual Basic for Windows
Version(s): MS-DOS:1.0
Operating System(s):
Keyword(s):
Last Modified: 06-DEC-1999
-------------------------------------------------------------------------------
The information in this article applies to:
- Microsoft Visual Basic for MS-DOS 1.0
-------------------------------------------------------------------------------
SUMMARY
=======
1. Q. I am receiving the error message "subscript out of range." What is causing
this problem?
A. In the Microsoft Visual Basic for MS-DOS (VBDOS) environment and in a
compiled application, a "subscript out of range" error message may occur on a
dimension (DIM) statement. This error is usually caused by one or both of the
following conditions:
a. If you have an array whose total size is greater than 64K, you must use
the /ah switch. To compile an application, add the /ah switch to your
command line. To use the /ah switch in the VBDOS environment, add /ah to
the command line when you invoke VBDOS.EXE.
b. Also, if you are working with a huge array (that is, over 128K), the
length of each element of the array must be a power of 2 bytes (2, 4, 8,
16, 32, 64, and so on). Frequently this is not the case with arrays of
user-defined types and arrays of fixed-length strings. If an element of a
huge array is not a power of 2 bytes, the user-defined type or fixed-
length string must be increased to the nearest power of 2. For example, an
array of fixed-length strings where each string is 60 bytes long must be
changed to an array of fixed- length strings where each string is 64 bytes
long.
2. Q. I am running out of memory in the VBDOS environment. What can I do to help
alleviate this problem?
A. When you are running in the VBDOS environment, it is best to have as much
expanded memory available as possible. VBDOS.EXE stores subprograms and
functions of less than 16K of code in expanded memory. To make more
conventional memory available, VBDOS provides an /s switch to reduce the
amount of conventional memory used by VBDOS.EXE. For example, you can start
VBDOS.EXE by typing "vbdos /s:340" (without the quotation marks) at the
command line. We recommend that you start VBDOS.EXE with an /s value between
320 and 350. This provides a good compromise between available memory and
speed. The lower the /s value, the slower the environment runs.
Running out of DGROUP or conventional memory is the most common cause of "out
of memory" messages in the VBDOS environment. Possible reasons for running
out of DGROUP include the following:
a. Too many subroutines or functions: Each SUB or FUNCTION procedure uses 46
bytes of DGROUP in the environment. Remove all routines that are not being
called or used.
b. Static arrays: Static arrays are stored in DGROUP. The only way to have a
static array in VBDOS.EXE is to have a dimension (DIM) statement for a
common shared array before the COMMON SHARED statement that contains it.
By positioning the DIM statement after the COMMON SHARED statement, the
array becomes dynamic and therefore is not stored in DGROUP.
c. Variable overhead: There is a 4-byte overhead in DGROUP for each variable.
This overhead occurs for each module. Therefore, in a multiple-module
program that has many common shared variables, this overhead is duplicated
for each module you have. To reduce the overhead, reduce the number of
variables and modules.
For more information on memory management, please refer to Appendix B of the
"Programmer's Guide." Please note that the README.DOC file provided with
Visual Basic for MS-DOS contains some corrections to this appendix.
Possible reasons for running out of conventional memory include the
following:
a. Not enough expanded memory for all your Basic routines: To work around
this problem, you must increase the amount of expanded memory available to
your program.
b. Subroutine or functions that are over 16K: To work around this problem,
decrease the size of each SUB or FUNCTION procedure until it is less than
16K. The size of each routine can be determined by pressing F2 in the
environment.
c. Large arrays: To work around this problem, decrease the number of
dimensions in your arrays. Nonvariable-length- string arrays of less than
16K can be stored in expanded memory by using the /ea switch when you
invoke VBDOS.EXE and Quick libraries. Your Quick library should include
only the routines that you need.
For more information on memory management, please refer to Appendix B of the
"Programmer's Guide." Please note that the README.DOC file provided with
Visual Basic for MS-DOS contains some corrections to this appendix.
3. Q. My program runs in the VBDOS environment; however, when the program is
compiled, an "out of memory" message is generated. How can I correct this
problem?
A. If a program runs successfully in the VBDOS environment but runs out of
memory at compile time or run time, there may be a problem with arrays. In
the VBDOS environment, arrays are dynamic by default. This means that the
arrays are created at run time and are stored in far memory. In a compiled
application, arrays are static by default. This means the arrays are created
at compile time and are stored in near memory (DGROUP), of which there is
only 64K.
To make all your arrays dynamic in a compiled application, use the metacommand
REM $DYNAMIC at the beginning of your program before the dimension (DIM)
statements of your arrays. If you have any arrays that are included in COMMON
SHARED statements, The DIM statements for these arrays should come after the
COMMON SHARED statements in which they are included.
For more information on the $DYNAMIC metacommand, please refer to the "A-Z
Reference" in the "Reference" manual.
For more information on memory management, please refer to Appendix B of the
"Programmer's Guide."
4. Q. When I try to compile my program, I receive a "program memory overflow"
error message. How can I correct this problem?
A. If a program runs successfully in the VBDOS environment but generates a
"program memory overflow" error message at compile time, the program needs to
be broken down into multiple modules.
In the VBDOS environment, each subroutine, function, event, or module-level
code is allocated 64K for code. In a compiled application, the entire file is
allocated only 64K. This difference allows a much larger code module or form
run in the environment than can run in a compiled application.
To make your compiled programs run, you must reduce them in size by moving
some code to another module. For more information on multiple-module
programming, please refer to Chapters 6 and 16 of the "Programmer's Guide."
Additional query words:
======================================================================
Keywords :
Technology : kbVBSearch kbAudDeveloper kbZNotKeyword3 kbVB100DOS
Version : MS-DOS:1.0
=============================================================================
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1986-2002.