Article ID: 119734
Article Last Modified on 10/30/2003
APPLIES TO
- Microsoft Visual Basic 3.0 Professional Edition
- Microsoft Visual Basic 3.0 Professional Edition
This article was previously published under Q119734
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:
112860 General Memory Management in Visual Basic 3.0 for Windows
Additional query words: buglist3.00 3.00 inconsistent
Keywords: kbbug KB119734
