🚀 go-pugleaf

"Michaelson Eitan" <m_eitan@netvision.net.il> wrote in message
news:3f0ce6eb@newsgroups.borland.com...

> When you compare a VC++ Standard GUI application
> (Win32 application that directly calls CreateWindow()
> act'), with a simple "TForm& Button" Borland
> Application, it's about 10 times as big.

That is because VC++ typically uses runtime libraries that ship with the OS
itself, whereas none of Borland's runtime libraries do at all.  VC++ users
can get away with making their executables appear smaller because they can
disable static linking and utilize the libraries that ship with the OS.
Although you can disable static linking under Borland's compiler as well,
the libraries are not shipped with the OS so you have to distribute them
yourself with your executable, which actually ends up being a bit larger
than if you had static linked in the first place.

However, the executables from both compilers are actually similar in size
when compiled with similar compiler options.  If you were to enable runtime
packages and such under Borland's compiler, the executable size would
shrink.  Likewise, if you enable static linking under VC++, the executable
will grow.

Let's not also forget that you are comparing apples and oranges here, so to
speak.  Or more accurately, an API-only executable to a VCL-enabled
executable.  The VCL is quite a large library.  Even if you use only a piece
of it, you still have to include the entire library.  It is also possible to
create an API-only executable using Borland's compiler and not use the VCL
at all, thus shrinking the executable size a bit just like VC++ does.

> Oh...And yes, the debug data was removed from all the
> compared executables.

That is irrelevant under Borland, because debug info is not stored in the
executable, it is stored in a seprate TDS file.


Gambit