Oliver's /dev/null replacement

In the scope of WinDirStat I had to take the little hurdle of branching in the past. Now, supposedly I could have simply opened a support request to the staff, but then I thought of it again, since I had done it locally on a Linux machine before. There was a problem, though: I wasn’t able to establish a shell connection to the CVS server. So the only thing left was to go the “classic” way. As mentioned before, I had done similar things before on a Linux machine, but that was at the same time the CVS server. So no fiddling around with protocols, establishing connections and so on.

This time it was a bit trickier, although not too tricky. But in order to save me (and perhaps others) from searching the command line options again and again, here it is for archival and for those who may face the same problem in future. This assumes that you have CVS access with your SF.net-username:

set CVS_RSH=plink.exe
cvs -z6 -d:ext:username@project.cvs.sourceforge.net:/cvsroot/project ↵
 tag -b -f -R -D yyyy-mm-dd BranchName ModuleName

The green parts are the variable parts. “ModuleName” can also be a “.” (dot), which means all modules.

// Oliver

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