Using Run-Time Module, RUN Makes Program Lose 70K Memory (37769)

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: "Out of Memory," "Error R6005," or the MS-DOS message "Not enough memory to Exec."

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:
1. Compile the following program WITHOUT the BC /O (stand-alone) option:
```
         ' TEST1.BAS
         PRINT FRE(-1)
         RUN "TEST2"
```
2. Compile the following program WITH the BC /O (stand-alone) option:
```
         ' TEST2.BAS
         PRINT FRE(-1)
								
```
3. Run TEST1.EXE. The following is sample output:
  439432 (from TEST1)
  429432 (from TEST2)
4. 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.
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 "memtest.exe"
						
```
The following Microsoft C routine prints available memory:

/*   memtest.c   */ 
#include <dos.h>
#include <malloc.h>
#include <stdio.h>
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("approximate # of bytes available for allocation %ld\n",l+j);
}

Using Run-Time Module, RUN Makes Program Lose 70K Memory (37769)

SYMPTOMS

STATUS

MORE INFORMATION