Microsoft KB Archive/37769

= Using Run-Time Module, RUN Makes Program Lose 70K Memory =

Article ID: 37769

Article Last Modified on 11/21/2006

-

APPLIES TO


 * Microsoft BASIC Compiler 6.0
 * Microsoft BASIC Compiler 6.0b
 * 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 Q37769



SYMPTOMS
When a program compiled without the /O option executes the RUN statement to run a second program, the run-time module (BRUNxx.EXE or BRTMxx.EXE) is unloaded from memory. However, the 70K of space for the run-time module fragments memory, and approximately 70K of RAM is unavailable to the program run with the RUN statement. When the second program quits or transfers control, the 70K of memory is available again.



STATUS
Microsoft has confirmed this to be a bug in Microsoft Basic Compiler versions 6.00 and 6.00b for MS-DOS, Microsoft Basic Professional Development System (PDS) versions 7.00 and 7.10 for MS-DOS, and Microsoft QuickBasic Compiler versions 4.00, 4.00b, and 4.50 (buglist4.00, buglist4.00b, buglist4.50) for MS-DOS. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

This problem doesn't occur in QuickBasic version 3.00.

This temporary fragmentation of memory can contribute to the cause of any one of the following errors when attempting to RUN another .EXE program: &quot;Out of Memory,&quot; &quot;Error R6005,&quot; or the MS-DOS message &quot;Not enough memory to Exec.&quot;



MORE INFORMATION
To work around this problem, you can make the program that uses the run-time module RUN another Basic program compiled with the BC /O (stand-alone) option, which in turn can RUN the desired .EXE program.

If the first Basic program is compiled with the BC /O (stand-alone) option, all but 200 bytes are available after the RUN statement. In this case, the 200 missing bytes are the expected overhead associated with the RUN statement.

The following are two different examples (1 and 2) that duplicate the problem:

 To duplicate the problem, do the following:

  Compile the following program WITHOUT the BC /O (stand-alone) option: ' TEST1.BAS PRINT FRE(-1) RUN &quot;TEST2&quot;   Compile the following program WITH the BC /O (stand-alone) option: ' TEST2.BAS PRINT FRE(-1)  Run TEST1.EXE. The following is sample output:

439432 (from TEST1)

429432 (from TEST2)

 Run TEST2.EXE alone. The following is sample output:

500232 (from TEST2)

There is about 70K more far heap available for TEST2 when it is run alone compared to when it is run from a Basic program using the BRUNxx.EXE module. </li>  The problem was originally reported using the RUN statement to execute a Microsoft C .EXE program.

To duplicate this problem, compile (without /O) and run the Basic program below, which RUNs a Microsoft C program. The C routine prints the approximate amount of memory free. When the Basic routine is compiled with the run-time module, about 70K is lost.

If you RUN the C program from the Basic routine compiled with /O and then compare with running the C program from MS-DOS, the memory numbers are within 200 bytes of one another.

The following Basic routine RUNS the C routine: RUN &quot;memtest.exe&quot; The following Microsoft C routine prints available memory: </li></ol>

/*  memtest.c   */ long l; unsigned int j,pp; main { union REGS inregs, outregs; inregs.h.ah=0x48; inregs.x.bx=0xffff; intdos(&inregs,&outregs); l=(long)(outregs.x.bx * 16L); /*amount available from far heap*/ j=_memavl;/*calculate approximate amount available from near heap*/ printf(&quot;approximate # of bytes available for allocation %ld\n&quot;,l+j); }
 * 1) include <dos.h>
 * 2) include <malloc.h>
 * 3) include <stdio.h>

Additional query words: QuickBas BasicCom buglist6.00 buglist6.00b buglist7.00 buglist7.10

Keywords: KB37769

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.