Monday, November 14, 2005

PowerCollections 1.0 for .NET 2.0 RTM

Wintellect has finally released the RTM version of PowerCollections 1.0. For those of you who don't have clue what I'm talking about: PowerCollections is a set of classes that extend the existing collections in the .NET 2.0 framework. People who know C++ and the Standard Template Library (STL) in particular will recognize some familiar collections like a Deque or a Set. I'm particular happy with the availability of the Pair class. I used it a lot through my C++ days and I don't quite understand why Microsoft isn't putting this class available in the .NET framework. Oh well, thank god that those kind folks of Wintellect are putting an effort in making this collections library available to the community. The library is entirelly written by Peter Golde, who is a former architect of the C# language, although .Brad Abrams is the actual inventor of the library. I recently bought his book Framework Design Guidelines : Conventions, Idioms and Patterns for Reusable .NET Libraries, wich is very, very, very good as expected. More background information regarding the PowerCollections can be found here.

Saturday, November 05, 2005

Rebase all your library assemblies

Back in the good old Win32 days it was considered a best practice to rebase all your DLLs. Every executable and DLL has a preferred base address. This base address is the memory address in the process address space where the module is loaded. When you create a native DLL with Visual C++, the default base address is set to 0x10000000 (0x00400000 for an executable). I guess that half of all the DLLs in the world are set for this default base address. When two DLLs with the same base address are loaded into the process address space, the first DLL loads at the preferred base address while the second DLL needs to be relocated. This operation is automatically performed by the PE loader of the Windows operating system. However, relocation of DLLs is a very expensive operation. The image of the DLL needs to be placed in memory and every entry in the relocations table must be transformed to reflect the new address range. Needless to say that rebasing all your DLLs greatly improves the startup time of your native applications. Have you ever had a customer on the phone, claiming that your aplication has crashed? Often the only information he or she can give you is a crash address. When you have properly rebased all your DLLs, it is very easy to determine the DLL that caused the crash. When you do not rebase the DLLs in your native applications, it is nearly impossible to determine wich DLL occupied the address space where the crash occured, due to the relocation mechanism. There are two methods to rebase a native DLL. The first method is to use the REBASE.EXE utility that comes with the Win32 SDK. The second method is to modify the preferred base address manually using either the project settings in Visual Studio or the /BASE switch of LINK.EXE. Th following table is the base address relocation scheme that I always use. The first letter of the DLL must match with a letter in the table. The key is to set the load address far enough apart so that you never have to worry about overlapping previously loaded DLLs. A–C 0x60000000 D–F 0x61000000 G–I 0x62000000 J–L 0x63000000 M–O 0x64000000 P–R 0x65000000 S–U 0x66000000 V–X 0x67000000 Y–Z 0x68000000 More information about this topic can be found in this ten year old article. It's an evergreen :-). Managed library assemblies do not contain any native executable code. Therefore you can think that rebasing managed DLLs is completely unnecessary. I strongly believe that it is still a best practice to rebase all your managed DLLs. Although you don't get this tremendous performance gain as with native DLLs, you avoid relocation when you use the NGEN utility on your assemblies. Note that executables do not need to be rebased because there are always loaded first. You cannot use the REBASE.EXE utility on managed modules because afterwards the CLR will not load your assemblies anymore. The only option you have is to manually specify the base address using the project settings in Visual Studio or the /BASEADDRESS compiler switch (VB and C#). The dialog below shows you how to set the base address of a class library created with Visual Studio 2005 (note that the default base address for managed assemblies is 0x40000000).

Tuesday, November 01, 2005

VistaDB 2.1 released

VistaDB just released the newest version of their database product. This company was recently in the (geek) news regarding their name collision with Microsoft Windows Vista. They claimed that their business would be wrongfully associated with the newest version of Windows, wich is due somewhere next year. Nonetheless, their product is an embedded database for .NET and Win32 applications. They claim that when developers use this product, they can build small and midsize database applications with the smallest footprint. For more information, you can read it at their website: They are trying to compete with existing embedded databases, such as CodeBase, MSDE, SQL Server 2005 Express, ..etc. In order to spread the word, an offer is launched for people like me who like to blog about .NET. A free version of VistaDB 2.1 for every .NET blogger who mentions their product. More information can be found at