DOCUMENT:Q88991 06-DEC-1999 [vbwin] TITLE :Visual Basic for MS-DOS: Memory Management Questions & Answers PRODUCT :Microsoft Visual Basic for Windows PROD/VER:MS-DOS:1.0 OPER/SYS: KEYWORDS: ====================================================================== ------------------------------------------------------------------------------- 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 1999.