Long memory address: How to improve memory management when using Microsoft Quick Basic or others Basic compilers.

Exención de responsabilidades de contenido KB retirado

Este artículo se refiere a productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Resumen

Los programadores que desee comprender cómo Microsoft QuickBasic y Basic Compiler de Microsoft organicen la memoria con el fin de escribir programas que hacen eficaces el uso de recursos del sistema. El lenguaje QuickBasic proporciona una variedad de tipos de datos y construcciones de código modular que le permiten administrar los datos y el código de sus programas.

Más información

En este artículo se trata los siguientes temas:


  1. Administración de código


    1. Programación modular
    2. Lo que sucede en el nivel de módulo en un módulo de soporte
    3. COMÚN, COMÚN COMPARTIDO, COMPARTIDO, DIM COMPARTIDA
  2. Administración de datos


    1. Metacommands $DYNAMIC y $STATIC
    2. Grandes arreglos
Apéndice A contiene un ejemplo de código para ilustrar los temas tratados en este artículo.


Apéndice B explica la. ASIGNAR el archivo creado cuando se vincula el ejemplo de programa del apéndice A. Puede utilizar el mapa del vínculo para determinar cómo cerrar cada módulo alcanzando el límite de 64K código y cómo cerrar la. Variables estáticas del programa EXE están obteniendo el límite de 64K en la DGROUP.


Los apéndices C y D describen en detalle la asignación de memoria para ejecutar programas en los siguientes tres entornos diferentes: el QB. Editor de EXE, un compilado. Programa EXE utilizando el módulo de tiempo de ejecución y una. EXE compilado con la opción independiente.

Definiciones

Un "módulo" se define como un archivo de código fuente individuales que contiene procedimientos básicos.


"Código de nivel de módulo" se define como las instrucciones dentro de un módulo que están fuera de un procedimiento SUB... END SUB, FUNCIÓN... END FUNCTION, o DEF FN... Bloque de definición de END DEF.


Un "módulo de apoyo" es un archivo de código fuente independiente del módulo principal, que contiene otros procedimientos SUB o FUNCTION.

ADMINISTRACIÓN DE CÓDIGO

Programación modular

Programación modular se ocupa de la división de programas en módulos independientes (es decir, los archivos fuente independiente que contiene procedimientos SUB o FUNCTION). Los motivos para hacerlo son los siguientes:


  1. Una vez que haya escrito un bloque de código como un módulo, que fácilmente se puede incorporar a futuros proyectos.
  2. La depuración es más fácil. Problemas pueden encontrarse mucho más rápidamente y pueden estar contenidos en un área específica del programa.
  3. El compilador (BC. (EXE) y el medio ambiente (QB. (EXE) tienen una limitación de código de 64 K por módulo. Un estilo de programación modular permite crear programas mayor que 64 KB, desde cada módulo, aunque sea parte de un programa, puede ser de hasta 64 KB de tamaño.
Si un programa es grande, puede ser necesario dividir en varios módulos. Esto se consigue fácilmente rompiendo procedimientos SUB o FUNCTION fuera del módulo principal y colocarlos en los módulos de compatibilidad. Estos módulos se compilan por separado con BC. EXE y vinculado con el módulo principal como en el ejemplo siguiente.


Considere un programa Main.BAS, que se divide en tres módulos:


  1. PRINCIPAL. BAS (que llama a un procedimiento externo)
  2. MODULE2. BAS (que contiene procedimientos SUB o función)
  3. MODULE3. BAS (que contiene procedimientos SUB o función)
Los tres módulos son, a continuación, se compilan por separado para producir los siguientes archivos de objeto:


  1. CONTINUIDAD DEL NEGOCIO PRINCIPAL. BAS; ---> MAIN. OBJ
  2. MODULE2 BC. BAS; ---> MODULE2. OBJ
  3. MODULE3 BC. BAS; ---> MODULE3. OBJ
Para generar el archivo ejecutable (. Se utiliza el programa (EXE), la línea de comandos siguiente:
    LINK Main.OBJ+Module2.OBJ+Module3.OBJ; ---->  Main.EXE
Main.EXE es el programa ejecutable terminado. Cuando se compila en el entorno de QuickBasic (QB. (EXE), el entorno automáticamente compila cada módulo y las vincula entre sí para producir el mismo. Archivos de OBJ y terminado el programa ejecutable.


Para hacer una. Exe incluido en el QB. Entorno de EXE, haga lo siguiente:


  1. Elija el menú Ejecutar.
  2. Elija el archivo EXE que... opción.
  3. Elija la opción archivo de EXE independiente para crear un archivo independiente. Si no se selecciona esta opción, el programa requiere que el módulo de tiempo de ejecución de BRUN4x.EXE en tiempo de ejecución.
  4. Presione la tecla ENTRAR.
El entorno de QuickBasic le ofrece una manera fácil de realizar las operaciones siguientes, que se describen más adelante:


  1. Cree un nuevo módulo de SUBs
  2. Editar subrutinas y módulos
  3. Eliminar SUBs
  4. Mover SUBs de un módulo a otro módulo
En QB. EXE para crear un módulo independiente (archivo de código fuente) para las subrutinas, para ello:


  1. Elija el menú archivo.
  2. Elija el archivo crear... opción.
  3. Escriba el nombre del módulo.
  4. Presione la tecla ENTRAR.
A continuación, se creará un archivo con el nombre especificado, y estará en la memoria con los otros módulos. Para guardar todos los módulos cargados, siga estos pasos:


  1. Elija el menú archivo.
  2. Elija la opción Guardar todo.
Cuando los módulos se guardan juntos, QuickBasic crea un archivo (con la extensión. MAK) que realiza un seguimiento del módulo principal y otros módulos que se utilizan por el principal. Para cargar todos los módulos de una sola vez, haga lo siguiente:


  1. Elija el menú archivo.
  2. Elija el programa abierto... opción.
  3. Seleccione el módulo principal del programa como el archivo que desea abrir.
Para ver y seleccionar SUBs para modificarlo, haga lo siguiente:


  1. Elija el menú Ver.
  2. Elija las subrutinas... opción.
  3. Resalte el módulo o SUB que desea editar.
  4. Ficha hasta edición en activo o editar en división.
  5. Presione la tecla ENTRAR.
Para eliminar un procedimiento SUB, haga lo siguiente:


  1. Elija el menú Ver.
  2. Elija las subrutinas... opción.
  3. Resalte el SUB que desea eliminar.
  4. Ficha hasta la opción Eliminar.
  5. Presione la tecla ENTRAR.
Para mover un SUB en un módulo diferente, haga lo siguiente:


  1. Elija el menú Ver.
  2. Elija las SUBRUTINAS... opción.
  3. Resalte el SUB que desea mover.
  4. Ficha hasta la opción Mover.
  5. Presione la tecla ENTRAR.
  6. Seleccione el módulo que desee el SUB en.
  7. Presione la tecla ENTRAR.
Para obtener más información acerca de cómo utilizar el QB. Entorno de EXE, consulte el manual "Microsoft QuickBasic: aprendizaje de uso" para la versión 4.50, o consulte el manual "Microsoft QuickBasic 4.0: aprendizaje y uso" para las versiones 4.00 y 4.00b y las versiones de compilador básica 6,00 y 6.00b.

Lo que sucede en el nivel de módulo en un módulo de soporte

Un módulo de soporte técnico, cuando se compila, genera un objeto (. Archivo OBJ) que está vinculado con un módulo principal para crear un archivo ejecutable. El código de nivel de módulo del módulo principal es el único código ejecutado directamente por QuickBasic. El código de nivel de módulo de los módulos de compatibilidad no puede ser llamada, ejecución o encadenada. Este código de nivel de módulo de los módulos de compatibilidad sólo se utiliza para:


  1. Controladores de eventos o interceptación de errores
  2. Metacommands
  3. Escriba definiciones comunes y DIM SHARED instrucciones
Puede colocar instrucciones de reventado ON evento GOSUB y ON ERROR GOTO dentro de los procedimientos de subprograma [donde evento ON significa ON KEY(n), ON COM(n), ON TIMER(n), etcétera.]. Sin embargo, la línea o la etiqueta de línea es el destino de la captura eventos o error GOTO o GOSUB debe ser el código de nivel de módulo en el mismo módulo que dicho subprograma. Esto es porque QuickBasic no permite GOSUBs o instrucciones goto desde un subprograma a otros módulos o subprogramas y QuickBasic permite sólo instrucciones ON evento GOSUB y ON ERROR GOTO saltar desde un subprograma para el código de nivel de módulo.


El compilador metacommands ($INCLUDE REM, REM $STATIC y $DYNAMIC REM) también puede utilizarse en el nivel de módulo. REM $INCLUDE pega fuente extra en el módulo en tiempo de compilación. REM $DYNAMIC y $STATIC REM declaran matrices posteriores como $DYNAMIC (asignado en tiempo de ejecución) o $STATIC (asignado en tiempo de compilación).


Puede utilizar el tipo... Instrucciones de tipo de extremo, DIM y compartidas comunes en el código de nivel de módulo. Matrices y variables pueden compartirse entre los módulos mediante la instrucción común COMPARTIDA en el nivel de módulo.

COMUNES, comunes compartidos, SHARED y COMPARTIDA DIM

La instrucción SHARED proporciona un acceso de procedimiento SUB o FUNCTION a las variables declaradas en el nivel de módulo principal de ese módulo (sin pasarlos como parámetros). No da acceso a las variables declaradas en los módulos de compatibilidad.


La declaración común, hace variables disponibles en el nivel de módulo entre módulos. El atributo SHARED de la declaración común (es decir, COMPARTIDA común) es necesario para compartir las variables con subprogramas o funciones. Debe coincidir con la lista de variables en las instrucciones común y compartido común en, escriba las instrucciones común y compartido común de cada módulo.


Cuando se utiliza la instrucción común (o COMPARTIDA común), se dimensiona diferentemente matrices estáticas y dinámicas. Las matrices estáticas en común deben ser dimensionado antes de la declaración común en todos los módulos con esa instrucción común. Matrices dinámicas en común deben ser dimensionado después de la declaración común en el módulo de principal y no deben ser declaradas en los módulos de soporte.


Hay dos diferencias entre el uso de la instrucción SHARED y la instrucción DIM compartidos:


  1. Para que una variable sea accesible por todos los subprogramas en un módulo, utilice DIM compartidos en el nivel de módulo.
  2. Para compartir una variable de nivel de módulo con un subprograma específico, coloque la variable en una instrucción de SHARED en el subprograma. La instrucción SHARED va directamente después de la primera línea del subprograma.

ADMINISTRACIÓN DE DATOS

Arreglos de discos $DYNAMIC y $STATIC

La configuración predeterminada para almacenar matrices es $STATIC REM, que almacena todas las matrices en DGROUP (el segmento de datos predeterminado). Para cualquier básico. EXE programa, DGROUP está limitada a 64K. Si utiliza las matrices estáticas, puede obtener más memoria en DGROUP realizando los arreglos de discos dinámicos, que mueve en el montón far. Para hacer que una matriz dinámica, la dimensión de la matriz después de la $DYNAMIC REM metacommand o la matriz con una variable en el subíndice de la dimensión.


Todas las matrices dinámicas se almacenan en el montón far excepto las matrices de cadenas de longitud variable. Cadenas, matrices de cadenas de longitud variable y variables simples siempre se almacenan en DGROUP. Para almacenar cadenas en el montón far, es necesario acotar una matriz dinámica de cadenas de longitud fija. Acotación de las cadenas como de longitud fija en matrices dinámicas ayuda a liberar espacio de almacenamiento que de lo contrario podría han seguido en DGROUP, que está limitado a 64K.

Grandes arreglos

Grandes matrices son matrices mayores de 64 KB. Al utilizar matrices grandes, se debe invocar el QB. Editor de EXE y continuidad del negocio. Compilador EXE con la opción /AH. La matriz de gran tamaño debe ser declarada como una matriz dinámica, con una variable en el subíndice de matriz o con la anterior $DYNAMIC REM metacommand. La opción /AH permite matrices dinámicas de datos numéricos, cadenas de longitud fija y tipos definidos por el usuario hasta ocupar toda la memoria disponible.


El número de bytes de un solo elemento de una matriz de gran tamaño preferiblemente debe ser una potencia de 2, con el fin de evitar la pérdida de memoria y habilitar matrices será mayor que 128 K, tal como se explica a continuación.


Se asigna espacio para una enorme matriz de forma contigua en el montón far, con la restricción de que ningún elemento de matriz simple (o registro) puede dividirse a través de un límite de 64K. Si un tamaño de registro no es una potencia de 2, la matriz se asigna en un desplazamiento suficientemente alto, con respecto a la dirección de base del segmento de la matriz (devuelto por la función VARSEG), que ningún elemento de la matriz se divide a través del límite exactamente 64 k por encima del segmento base. El valor devuelto por la función VARPTR para el primer elemento de la matriz, a continuación, indica que tanto el desplazamiento de la matriz y también el tamaño de un espacio creado en el montón far. Esta brecha fragmenta el montón far y memoria desperdiciada, no utilizada. El tamaño de la brecha es igual a (65.536) MOD (tamaño de registro de matriz). [En el peor de los casos, la brecha puede tener hasta (tamaño de registro de matriz) menos 1 tamaño.]


Se produce un error "Subíndice fuera del intervalo" al asignar una enorme matriz mayor que 128 K si los elementos de la matriz tienen un tamaño que no es una potencia par de 2. Arreglos de discos de mayores que 128K debe tener un tamaño de elemento es una potencia de 2 (2, 4, 8, 16, 32, 64, etc.), puesto que las matrices se almacenan de forma contigua y no se permite ningún elemento único arreglo de discos se pueden dividir en un límite de 64K.


El último aspecto principales de administración de memoria QuickBasic es QuickBasic que intenta hacer un uso eficiente de la memoria, lo que puede producir cadenas de longitud variable, matrices de cadenas de longitud variable y matrices dinámicas para moverse en la memoria de la instrucción en tiempo de ejecución. (Otras variables tienen una ubicación fija que se determina en tiempo de carga EXE.) Además, si realiza una instrucción de cadena, pueden mover los datos pasados en un bloque común. Esto significa que los resultados de la VARPTR, VARSEG, VARPTR$ o función SADD siempre debe utilizarse inmediatamente después de que se llama a la función.

APÉNDICE A: PROGRAMA DE EJEMPLO

Este programa de ejemplo muestra los temas tratados en este artículo. Este programa proporciona un ejemplo de formas para matrices de una dimensión y para pasar variables entre módulos y subprogramas. El programa consta de dos módulos, cada uno de ellos define un subprograma.

Módulo principal (EXAMPL1. BAS)

DECLARE SUB OtherModSub ()DECLARE SUB Subdemo ()

TYPE PowerOfTwo
I AS INTEGER ' 2 Bytes
L AS LONG ' 4 Bytes
S AS SINGLE ' 4 Bytes
D AS DOUBLE ' 8 Bytes
St AS STRING * 14 ' 14 Bytes

END TYPE ' 32 Bytes Total, a power of 2, 2^5

REM $STATIC
DIM A(100) AS INTEGER ' Static array, stored in DGROUP.

COMMON SHARED A() AS INTEGER ' Share the variables with the other
COMMON SHARED B AS STRING * 20 ' module and its SUBprograms.
COMMON SHARED X() AS INTEGER

REM $DYNAMIC
DIM X(100) AS INTEGER ' Dynamic array, stored in far heap.
DIM PTwo(4000) AS PowerOfTwo ' Dynamic huge array, stored in far heap
' Each element is a power of two, 2^5.

DIM NonFixedLen(10) AS STRING ' Dynamic array, but since it is not
' fixed length it is stored in DGROUP.

REM $STATIC
DIM SHARED M(100) AS LONG ' These variables are shared with all
DIM SHARED Equals AS STRING * 10 ' the SUBprograms in this module,
' and are stored in the DGROUP.

Num = 40

DIM DynArray(Num) AS SINGLE ' The array is dynamic since it is
' DIMensioned with a variable, so
' it is stored in far heap.

Plus$ = " + "
Equals = " = "
M(1) = 7
A(1) = 4

CALL Subdemo ' CALLs the SUBprogram of this module.
CALL OtherModSub ' CALLs the SUBprogram of the support module.
END

'SUBprogram of the Main Module:

SUB Subdemo

SHARED Plus$, NonFixedLen() AS STRING, Num

PRINT STR$(Num) + Plus$;
PRINT STR$(M(1))+ Equals + STR$(A(1));
A(1) = M(1)


END SUB

Módulo de soporte (EXAMPL2. BAS)

REM $STATIC
DIM A(100) AS INTEGER ' Only the static array is DIMensioned
COMMON SHARED A() AS INTEGER ' before the COMMON SHARED statement.
COMMON SHARED B AS STRING * 20
COMMON SHARED X() AS INTEGER ' The dynamic array is only DIMensioned
' in the main module.

Panic: ' The label for ON ERROR has to be at
resume next ' the module level.


' SUBprogram of the Support Module:

SUB OtherModSub
PRINT A(1)
ON ERROR GOTO Panic
END SUB

APÉNDICE B: VÍNCULO. EXPLICACIÓN DEL ARCHIVO DE MAPA

A continuación se presenta una. Archivo de mapa creado cuando se vincula el ejemplo del programa en el apéndice A. . Archivo de asignación desde un vínculo exitoso Muestra cercanía esté alcanzando el límite de 64K código de segmento de código de un módulo y cómo cerrar las variables estáticas para toda la. Programa EXE son alcanzando el límite de 64K en la DGROUP. Para generar un mapa de listado de un programa, incluya un nombre de archivo de mapa en el tercer argumento del comando de vínculo, como en el ejemplo siguiente:
   LINK EXAMPL1.OBJ+EXAMPL2.OBJ,,EXAMPLE.MAP;
Notas para el vínculo. MAPA que se muestra más abajo son las siguientes:


  1. EXAMPL1_CODE es el segmento de código para EXAMPL1. BAS.
  2. EXAMPL2_CODE es el segmento de código para EXAMPL2. BAS.
  3. El segmento de código de cada módulo debe ser menor que 64K. Cuando el segmento de código se está aproximando al 64 K, divida el módulo en dos o más módulos. Para encontrar la longitud de un segmento de código, busque en la columna longitud. Por ejemplo, la longitud del segmento de código para EXAMPL1. BAS es 15A bytes hexadecimales, 346 en notación decimal.
  4. FAR_MSG es el grupo de administración lejano que contiene texto de mensajes de error. NO es el montón far. Se asigna el montón far en tiempo de ejecución.
  5. Según el punto de origen en la parte inferior del mapa de vínculo, DGROUP comienza en 06DC:0, que es el hexadecimal 06DC dirección de párrafo, con un desplazamiento de 0. Es el mismo que el hex de 06DC0 dirección de bytes (como un párrafo contiene 16 bytes). Por lo tanto, en este ejemplo, DGROUP comienza donde comienza el BR_DATA.
  6. DGROUP termina en la dirección de la parada de la pila.
  7. Para saber el tamaño DGROUP del programa, tomar la dirección de la parada de la pila y restar la dirección de inicio del primer elemento de datos en el DGROUP. Por ejemplo, el tamaño de DGROUP del programa es 7F9F hexadecimal menos hexadecimal 6DC0, que equivale a 11DF de bytes hexadecimales (4575).
  8. Todas las direcciones en el. MAPA son sólo relativas al inicio de la. Programa EXE. La dirección de carga absoluta se determina por DOS en tiempo de ejecución. Las instrucciones VARSEG y VARPTR pueden utilizarse en el programa en tiempo de ejecución para mostrar las direcciones absolutas de las variables.

EXAMPLE.MAP

 Start  Stop   Length Name                   Class
00000H 00159H 0015AH EXAMPL1_CODE BC_CODE
00160H 001C1H 00062H EXAMPL2_CODE BC_CODE
001C2H 03931H 03770H CODE CODE
03932H 03A0CH 000DBH INIT_CODE CODE
03A10H 041B2H 007A3H _TEXT CODE
041C0H 065EFH 02430H EMULATOR_TEXT CODE
065F0H 065F0H 00000H C_ETEXT ENDCODE
065F0H 065F7H 00008H FAR_HDR FAR_MSG
065F8H 06C44H 0064DH FAR_MSG FAR_MSG
06C45H 06C46H 00002H FAR_PAD FAR_MSG
06C47H 06C47H 00001H FAR_EPAD FAR_MSG
06C50H 06DBFH 00170H EMULATOR_DATA FAR_DATA

06DC0H 06DC0H 00000H BR_DATA BLANK
06DC0H 06DEFH 00030H BR_SKYS BLANK
06DF0H 06EFBH 0010CH COMMON BLANK
06EFCH 070E3H 001E8H BC_DATA BC_VARS
070E4H 070E9H 00006H NMALLOC BC_VARS
070EAH 070EAH 00000H ENMALLOC BC_VARS
070EAH 070EAH 00000H BC_FT BC_SEGS
070F0H 0710FH 00020H BC_CN BC_SEGS
07110H 07122H 00013H BC_DS BC_SEGS
07124H 07124H 00000H BC_SAB BC_SEGS
07124H 0712BH 00008H BC_SA BC_SEGS
0712CH 0712FH 00004H BC_SAE BC_SEGS
07130H 07345H 00216H _DATA DATA
07346H 0761FH 002DAH _BSS DATA
07620H 0771CH 000FDH BR_DATA DATA
0771EH 0771EH 00000H XIB DATA
0771EH 07741H 00024H XI DATA
07742H 07742H 00000H XIE DATA
07742H 0774DH 0000CH DBDATA DATA
0774EH 0775BH 0000EH CDATA DATA
0775CH 0775CH 00000H XIFB DATA
0775CH 0775CH 00000H XIF DATA
0775CH 0775CH 00000H XIFE DATA
0775CH 0775CH 00000H XPB DATA
0775CH 0775CH 00000H XP DATA
0775CH 0775CH 00000H XPE DATA
0775CH 0775CH 00000H XCB DATA
0775CH 0775FH 00004H XC DATA
07760H 07760H 00000H XCE DATA
07760H 07760H 00000H XCFB DATA
07760H 07760H 00000H XCF DATA
07760H 07760H 00000H XCFE DATA
07760H 0779FH 00040H CONST DATA
077A0H 077A0H 00000H BC_DATA BC_DATA
077A0H 077A0H 00000H XOB BSS
077A0H 077A0H 00000H XO BSS
077A0H 077A0H 00000H XOE BSS
077A0H 07F9FH 00800H STACK STACK

Origin Group
06DC:0 DGROUP
065F:0 FMGROUP
Program entry point at 03A1:00C8

Apéndice C: Donde QuickBasic 4.00, 4.00b, y 4.50 almacenar sus arreglos de discos

Hay una diferencia entre los programas que se ejecutan como compilado almacenamiento para la matriz. Ejecutarán programas y archivos EXE en el entorno de QuickBasic versiones 4.00, 4.00b y 4.50 (QB. (EXE). En el QB. Entorno de EXE, una matriz que es estática, no en común y no se compone de cadenas de longitud variable, se almacena en el montón far (en lugar de DGROUP, como en. Programas EXE).


Esto cambia la administración de memoria en el programa, dependiendo de dónde se ejecuta el programa.


Así, en los programas que se ejecutan dentro del entorno QuickBasic 4.00, 4.00b o 4.50 (QB. (EXE), se almacenan las matrices como sigue:


  1. Todas las matrices $STATIC en común se almacenan en DGROUP y se pueden hacer referencia con direcciones near.
  2. Todas las matrices de cadenas de longitud variable también se almacenan en DGROUP y también pueden hacer referencia con direcciones near.
  3. Todos los otros arreglos de discos se almacenan como objetos lejos y requieren direcciones lejanas. Esto incluye arreglos de discos de $STATIC que no están en una declaración común, y pueden mover estas matrices en memoria como las matrices $DYNAMIC.
En QuickBasic 4.00, 4.00b y 4.50 programas que se ejecutan como compilado. Archivos EXE, arreglos de discos se almacenan como sigue:


  1. Todas las matrices $STATIC se almacenan en DGROUP y se pueden hacer referencia con direcciones near.
  2. Todas las matrices de cadenas de longitud variable $DYNAMIC también se almacenan en DGROUP y también pueden hacer referencia con direcciones near.
  3. Todas las demás matrices $DYNAMIC se almacenan como objetos de extremo.

APÉNDICE D: MEMORIA MAPAS

Este apéndice contiene una asignación de memoria general y tres mapas de memoria detallada de tiempo de ejecución.

Diagrama de memoria general

El siguiente diagrama resume cómo QuickBasic compilado los programas se cargan en la memoria en tiempo de ejecución:
          High Memory (640K maximum)
+-----------+
| | The far heap stores dynamic arrays. The far
| (Far) | heap consists of the rest of high memory
| Heap | available after MS-DOS and the Basic
| | program's DGROUP segment and code
--- +-----------+ segment(s) are allocated.

| | | The stack is used to store temporary data,
| | Stack | such as variables that are passed to a
DGROUP | | subprogram procedure. The default stack
Up to |- - - - - -| size is 2K.
64K | | The DGROUP (default data segment) is used
| | (Near) | to store all static arrays, strings,
| | Data | simple variables, and the stack. DGROUP
--- +-----------+ can be up to 64K in size.
:
+-----------+
| Code | The code segments store the executable code.
| Segments | Each module can have up to 64K for its
+-----------+ code segment.
Low Memory

Las siguientes figuras 1, 2 y 3 describen con más detalle la disposición de código y datos en la memoria en tiempo de ejecución.

Figura 1

La primera figura (más abajo) muestra el mapa de memoria de tiempo de ejecución cuando el programa se ejecuta dentro de la QB. Entorno de EXE versión 4.x:
                   +-------------+
| Quick |
| Library |
+-------------+
|Communication| User-specified size
| buffers |
+-------------+
| | This area contains items, such as
| FAR heap | large/huge arrays and user code,
| | dynamic arrays.
+-------------+

User Data ------->Run-time heap| Files buffers, etc.
End DS:xxxx +-------------+
| String heap |
+-------------+
| User Program|
DGROUP | Data |
+-------------+
UP to | User Stack |
64K +-------------+
| Quick Lib |
| Data |
+-------------+
| QuickBasic |
User Data | Static |
Start DS:0 ------->| Data |
+-------------+
| QuickBasic | QB.EXE
Low Memory ------->| Code |
+-------------+
| MS-DOS | MS-DOS Operating System
+-------------+
0000:0000 ------->

Figura 1 (anteriormente): la asignación de memoria para QB. Entorno de EXE 4.x

Figura 2

Esta segunda figura (más abajo) muestra el mapa de memoria en tiempo de ejecución, tal y como aparece cuando se utiliza el módulo de tiempo de ejecución BRUN4x.EXE con el método de compilación independiente (asegúrese de archivo EXE...):
                   +-------------+
| BRUN4x.EXE | Separately loaded run-time code
+-------------+
|Communication| User-specified size
| buffers |
+-------------+
| | This area holds less-frequently-
| | used items, such as dynamic
| FAR heap | arrays, the user environment
| | table.
| |
| |
+-------------+
User Data ------->Run-time heap|
End DS:xxxx +-------------+
| String heap |
+-------------+
| User Stack | Preset to 2K
+-------------+
| Named | Named COMMON areas
| COMMON |
DGROUP +-------------+

| BC_DATA | User program variables
Up to +-------------+
64K | BC_CONST | User program constants
+-------------+
| Blank COMMON|
+-------------+
| _DATA | QuickBasic run-time data areas,
User Data | CONST | used during user code execution
Start DS:0 ------->| _BSS |
+-------------+
| User Code | User program separately linked
Low Memory ------->| | with BRUN4x.LIB
+-------------+
| MS-DOS | MS-DOS Operating System
+-------------+
0000:0000 ------->

Figura 2 (parte superior): la memoria del módulo de tiempo de ejecución de BRUN4x.EXE para un. EXE

Figura 3

Esta tercera figura (más abajo) muestra el mapa de memoria de tiempo de ejecución cuando se utiliza la opción de soporte - biblioteca por sí solo (BCOM4x.LIB) con el método de compilación independiente (asegúrese de archivo EXE...):
                   +-------------+
|Communication| User specified size
| buffers |
+-------------+
| | This area contains less frequently
| | used items, such as large
| FAR heap | numeric arrays, the user
| | environment table, dynamic
| | arrays.
| |
+-------------+

User Data ------->|Run-time heap| Files, buffers, etc.
End DS:xxxx +-------------+
| String heap |
+-------------+
| User Stack | Preset to 2K bytes
+-------------+
| Named | Named COMMON areas
| COMMON |
DGROUP +-------------+
| BC_DATA | User program variables
Up to +-------------+
64K | BC_CONST | User program constants
+-------------+
| Blank COMMON| Library and user definitions
+-------------+
| _DATA | QuickBasic run-time data areas,

User Data | CONST | used during user code execution
Start DS:0 ------->| _BSS |
+-------------+
|Run-time code| Run-time code linked into file
+-------------+
| User Code | User program separately linked
Low Memory ------->| | with BCOM4x.LIB
+-------------+
| MS-DOS | MS-DOS Operating System
+-------------+
0000:0000 ------->

Figura 3 (arriba): independiente (biblioteca BCOM4x.LIB) memoria para una. EXE
Propiedades

Id. de artículo: 45850 - Última revisión: 17/01/2017 - Revisión: 1

Comentarios