BUG: Recompiling VB Project May Produce Larger .EXE File

 Last reviewed: June 21, 1995
Article ID: Q119734
The information in this article applies to:
  • Standard and Professional Editions of Microsoft Visual Basic for Windows, version 3.0

SYMPTOMS

When you compile a Visual Basic project (by choosing Make EXE File from the File menu) more than once without making any modifications to the project, the size of the subsequent .EXE file may be different. In other applications, successive compilation of an application's unaltered files results in executable files of the same size. However, in Visual Basic the .EXE file usually increases in size with each compilation.

CAUSE

Each Visual Basic application receives one data segment of up to 64K (minus overhead) to store global variables and global constants. Space for the global string constant descriptors is allocated in this data segment. The actual text for global string constants is stored in a segment of up to 32K (minus overhead), allocated separately from dynamic memory.

A Visual Basic custom control (.VBX) is allocated space in the same 32K segment for any strings created with the Visual Basic API VBCreateHlstr. If the custom control does not deallocate this space, because it needs to reference these strings when it is unloaded or because it does not clean up properly, the data in the segment may exceed 32K. Visual Basic allocates another segment to hold the excess data any time the data exceeds 32K and links this new segment to an internal list of dynamic data segments.

While it is legal to allocate another segment to custom controls, the global string constant data is limited to one segment. Visual Basic gets confused because the global string constant data segment has another segment attached to it, and an .EXE file of a larger size is usually generated as a result. In some cases, the global string constant data segment is even lost, resulting in a smaller .EXE file.

WORKAROUND

If you encounter the above situation, the only way to make consistent .EXE files so that any differences in size can be attributed to a problem like the one described in this article is to compile from the command line. In Program Manager, choose Run from the File menu and enter a Visual Basic command line like the one below in the Command Line text box: 

     VB.EXE /Make SAMPLE.MAK SAMPLE.EXE
Because it is impossible to tell how much of the segment custom controls using VBCreateHlstr may need and because Visual Basic needs some of the space to manage the segment, you should also try to use as little space as possible for global string constants, thus attempting to avoid allocating another segment. To eliminate this possibility, you should try and reduce the space needed to store global string constant data to well under 32K. This space can be reduced by using fewer global string constants and by making the strings shorter.

STATUS

Microsoft has confirmed this to be a bug in Visual Basic version 3.0. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

MORE INFORMATION

Executable files compiled from the command line for the same unmodified project are normally the same size, but they are not necessarily identical. Executable files produced by Visual Basic contain some uninitialized data, and when they are saved, they contain whatever happened to be at that location on the disk. You will see these differences within the .EXE files when comparing them with a binary-file comparison utility like DIFF.

For further information on what Visual Basic places in its .EXE files, please see the following article in the Microsoft Knowledge Base: 

   ARTICLE-ID: Q112860
   TITLE     : General Memory Management in Visual Basic 3.0 for Windows

Additional reference words: buglist3.00 3.00 inconsistent
KBCategory: kbenv kbbuglist
KBSubcategory: EnvtDes

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.

Last reviewed: June 21, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.