Wow, look at that Quality Central article. Now look at the reply. Now look closer at the affected version and the date when it was reported.
It’s unbelievable, but now – after working a while with Borland C++ Builder 6 (BCB6) – I found out by accident, that a huge portion of the final size of the executables created by BCB6 is made up of exports. And I am not talking about DLLs here, for which it is normal to export functions – I am talking about ordinary programs which under normal circumstances don’t even have an export table. What the heck were the Borland engineers thinking and why the heck wasn’t this fixed with one of the updates? This ignorance is amazing. Apart from the threat of crackers or other reverse engineers who just get half the job done by Borland kindly exporting my symbols and with name for them, there are other concerns. How about the garbage in my executable? Shouldn’t this alone be convincing enough to rid us users off this “feature”? Also I have serious doubt that the so-called “smart-linking” is totally unaffected by this, since exported symbols cannot be subject to optimization. They’re needed, because they are exported. This may not reflect the actual necessity of the symbol to remain in the binary, but now that it is exported, it has to be left in the binary.
From experience I can only tell that Delphi doesn’t build so huge binaries for similarly sized projects. But then, Delphi also doesn’t export hundreds and hundreds of garbage symbols.
At least there are people in the Delphi community who have solved some of the common usability and speed issues you have had for about a decade now with Borlands Win32 products. Andreas Hausladen is one of them and he offers such nice tools as DDevExtensions and DelphiSpeedup. Both also work, despite the name, on Borland’s C++ products. And even better, Andreas has provided a tool which offers a partial solution to the above discussed problem: LibExportRemover. This tool literally comments out those export declarations in the LIB (OMF) files of the package LIBs. In the case I am facing, about 1000 exports – and even many Windows system DLLs have less exports than the resulting EXE in my case – can be attributed to the excellent Virtual Treeview component. Don’t mistake it: I am not blaming the component, but the compiler and the linker and the rest of those tools behaving so silly.
// Oliver