• the footprint on 64-bit platforms can get nasty
• the explicitly allocated memory, instead of using a std::vector

So this is the code:

int** m_pCells; 

void Create()
{
   m_pCells = new int*[m_nSize];
   for(int i = 0; i < m_nSize; ++i)
      m_pCells[i] = new int[m_nSize];
}

Let's see how much memory it takes. The total size should be:

totalsize = sizeof(m_pCells) + sizeof(m_pCells[0]) * m_nSize + m_nSize * m_nSize * sizeof(int);

On 32-bit platforms, the size of a pointer is the same with the size of int and is 4 bytes. For the maximum size allowed for my grid, which is 50, the total size in bytes for the grid is: 4 + 4*50 + 50*50*4 = 10204.

On 64-bit platforms, the size of a pointer is 8 bytes, but the size of int is still 4 bytes. So for a grid with 50 rows and columns it needs: 8 + 8*50 + 50*50*4 = 10408 bytes. That's a 2% increase of required memory.

The memory footprint was the last thing I had in mind when I wrote this simple exercise. Well, of course there is a way to require only 4 more bytes on 64-bit platforms. And that is using an int* allocating m_nSize*m_nSize elements.

int* m_pCells;

void Create()
{
   m_pCells = new int[m_nSize * m_nSize];
}

void Destroy()
{
   delete [] m_pCells;
   m_pCells = NULL;
}

With this implementation, when you need to access the element at row i and column j, you have to use m_pCells[i * m_nSize + j].

As for the second argument, that explicitly using operator new[] to allocate memory instead of using a vector of vectors, well, what could I say? Sure, why not. Different people use different programming styles. As long as all implementation are correct and achieve the same goal with similar performance, I guess everyone is entitle to code as he/she wants. But if we go back to the memory footprint, I would also guess that the use of vectors would take more memory than pointers to int, because the size of a vector is several times the size of a pointer. But I wouldn't say that's an important issue here.

Anyway, these arguments remember me the joke (or maybe it's serious) about the rules of optimization:

1. Don't optimize.
2. Don't optimize yet (for experts only).

(Of course there are super experts that can ignore these rules.)

The rules are:

• the grid has an equal number of rows and columns, that can vary from 5 to 50
• cells are colored with six colors
• coloring the grid always starts from the top left cell
• adjacent cells having the same color form a single shape; game ends when this shape covers the entire grid
• to change the color of the growing shape, use the six buttons available on the right side of the grid
• grid must be covered within a number of moves; if you exceed that number of moves you lose
• when you win, you automatically get to the next level
• you can change the size of the grid from the menu

Here are the available downloads: the sources, and the executable.

Mandelbrot Fractal
A Mandelbrot set is a set of points in the complex plane, whose boundary forms a fractal. The fractal, known as Mandelbrot fractal, is obtain by associating a color with each point in the complex plane (or rather a subset of it). The color is chosen based on the result of computing the value of the complex quadratic polynomial Z(n+1) = Z(n)^2 + c for a number of iterations (100, 200, etc.). You can read more about it on Wikipedia.

The program that I shown exhibits traits of both functional (for computing the fractal) and object oriented (for displaying the fractal) paradigms. It is a variation of the program available here, for which I kept the functional part (computing the Mandelbrot set is not very fast, I must warn you), but redone the user interface part. You can use the mouse to drag the fractal and the wheel to zoom in and out.

You can download it from here.

Game of Life
I blogged about this two years ago, when F# was still far from a final release. In the meantime, syntax has changed, classes have changed, so if you try to run that implementation of mine you’ll run into some errors. I have updated the code to run correctly with Visual Studio 2010.

You can download it from here.

Detected memory leaks!
Dumping objects ->
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {381} normal block at 0x001FFC30, 54 bytes long.
Data: < x > 0C 00 B9 78 12 00 00 00 12 00 00 00 01 00 00 00
d:\marius\vc++\memoryleakstest\memoryleakstestdlg.cpp(163) : {380} normal block at 0x001FFBF0, 4 bytes long.
Data: <@ > 40 FC 1F 00
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp(306) : {374} client block at 0x001FFA38, subtype c0, 68 bytes long.
a CWinThread object at $001FFA38, 68 bytes long
Object dump complete.

Some of them can be fixed immediately, because when you double click on them Visual Studio will take you to the line where the allocation was made. Some of them are harder to spot, because Visual Studio is not able to do the same. Question is how do you find the source of those allocations? Luckily, there is this global variable called _crtBreakAlloc, that can be used to force the debugger to stop the execution when a certain block is allocated.

In order to use that, you should follow several steps:

• First, you have to find a reproducible sequence that produces the same memory allocation number. When memory blocks are allocated, they are identified with a number, called allocation number. This number is reported by Visual Studio in brackets when it lists the memory leaks (e.g. {381}).
• Second, you have to put a breakpoint somewhere in your program to force a stop at the beginning of the execution. That means you could use function main(), your CWinApp derived class constructor, function InitInstance() or other, depending on your application type and how early in the execution of the program the block that leaks is allocated. The smaller the allocation number is, the earlier in the execution the allocation occurs.
• Run your program in debugger.
• When the program stops (at the first breakpoint) open the Watch window and add the following expression: {,,msvcr90d.dll}_crtBreakAlloc in the Name column. In the Value column (which by default should have the value -1) write the allocation number. Take notice that msvcr90d.dll (which is the DLL that contains the C++ runtime library) is specific to Visual Studio 2008 (and is the debug version). If you use another version of Visual Studio, you have to use the appropriate DLL.
• Continue debugging.
• When the block identified by the allocation number set in the Watch window is allocated, the debugger will stop the execution and jump to a line from dbgheap.c.
  
  In order to see the line in your code that triggered the allocation, open the Call Stack window and find, from top down, the first function from your own code.
  
  That will lead you to the source of the memory leak.

To read more about this topic see:
How to: Set Breakpoints on a Memory Allocation Number
How to use _crtBreakAlloc to debug a memory allocation

Now, I want to make a prediction about her current and next predictions: she got the result of tonight’s match wrong, Germany will win. And then, she’ll have to chose between Netherlands and Germany and will pick the Netherlands. Now, the prediction is not that much about who wins (it doesn’t matter actually who wins), it’s about how Paul makes the picks.

How did I do this prediction? Well, I see patterns. And here is Paul’s prediction pattern. She is giving two jars, arranged by the teams order:
Germany – Australia
Germany – Serbia
Ghana – Germany
Germany – England
Argentina – Germany
Germany – Spain

She’s picking left, right, right, left, right, right. The next match will be between Netherlands and Germany and she will pick left, thus Netherlands.

Let’s see how good I am with predictions.

UPDATE: OK, psychic Paul was right once again. But I still predict that it will pick left, thus, Uruguay for Germany’s next match.

SECOND UPDATE: so Paul has picked Germany over Uruguay, and Spain over Netherlands. That completely ruins my prediction.

Now, the same rule applies in the COM world. Your coclasses can either be thread-safe or not. If the are thread-safe, you can access one object from different threads at a time, otherwise not. Here enter the apartments. So what is an apartment? An apartment is an environment in which COM objects can live. It’s not a thread, nor a process, but it handles access from COM clients to COM objects. There are several types of apartments: single-threaded apartments (STA), multi-threaded apartments (MTA) and neutral-threaded apartments (NTA).

Single-Threaded Apartments
An STA allows only one thread at a time to access a COM object. This is achieved using a hidden window with a message pump. Calls from clients living in different threads are queued with the message pump. Only when the current call from a thread ends, the next call can proceed.

Assume you had a COM object called CoUserGroups that implements an interface IUserGroups that provides two methods: one called Add that adds a new user group, and one called Delete that deletes a user group. Since both methods work on the same list of user groups, adding and deleting is not possible at the same time without synchronizing access. But since such synchronization was not implemented, the COM object specifies that it can leave only in an STA, and let the apartment do the synchronization of calls from clients living in different threads.

Multi-Threaded Apartments
An MTA allows any number of threads to access a COM objects. However, the COM objects must be thread-safe, otherwise your application will behave unexpectedly and even crash.

Going back to the previous example, if CoUserGroups was implemented in a thread-safe manner, then it would be possible for clients living in different threads to access it. In this case there would be no need for an apartment level synchronization. The COM coclass specifies that it can live in an MTA and when simultaneous calls from different threads are received they are directed immediately to the COM object. This situation is shown in the next image.

Neutral-Threaded Apartments
NTAs, like MTAs, allow multiple threads to enter one apartment, but once a thread entered the apartment it acquires an apartment wide lock that will block the other threads, until the current thread exists the apartment. Calls into NTA (from STA or MTA in the same process) do not generate context switches; the thread leaves the apartment in which it executes and enters the NTA without any context switch, which increases performance. This model was introduced with COM+ (in Windows 2000) and is meant for components with no user interface.

A process can contain several apartments:

• zero or one MTA
• zero or one NTA
• zero, one or several STAs; the first STA created for a process is called the main STA

As a COM client, you specify the apartment you want to join with a call to CoInitializeEx(). This methods must be called from each thread.

HRESULT CoInitializeEx(void * pvReserved, DWORD dwCoInit);

The second parameters is a set of flags specifying the initialization options for the thread. To join the unique MTA, use COINIT_MULTITHREADED. To join a new or existing STA, use COINIT_APARTMENTTHREADED. Function CoInitialize() calls CoInitializeEx() specifying COINIT_APARTMENTTHREADED for the flags.

How to specify the threading model allowed for a coclass?
A coclass can specify the type of apartment it can join. If you’re using ATL you can specify that when you create the coclass. The next image shows the available options:

What they mean:

• Single: object wants to join the main STA (the first STA created into the process)
• Apartment: object wants to join one of the STAs in the process
• Both: object wants to join either an STA or the MTA
• Free: object wants to join the MTA
• Neutral: object wants to join the NTA

ATL adds the appropriate value to the registry script it creates for your coclass. COM depends entirely on the registry, and the threading model is also specified in the registry. Here is an example:

HKCR
{
	NoRemove CLSID
	{
		ForceRemove {80CFA233-86CC-44E3-9A62-BC498D8F2A0E} = s 'CoUserGroups Class'
		{
			ForceRemove Programmable
			InprocServer32 = s '%MODULE%'
			{
				val ThreadingModel = s 'Apartment'
			}
			TypeLib = s '{B8965B61-2A5A-4F34-B9F8-D8859452D345}'
			Version = s '1.0'
		}
	}
}

When that is merged into the Windows Registry, it looks like this:

The possible values in registry are:

• no value specified: equivalent of ATL ‘Single’
• Apartment: equivalent of ATL ‘Apartment’
• Free: equivalent of ATL ‘Free’
• Both: equivalent of ATL ‘Both’
• Neutral: equivalent of ATL ‘Neutral’

If you want to read more about COM apartments I suggests articles like this one.

Now, yesterday I had a problem with Google Documents (which no longer worked on my WinXP machine with any browser, as it continuously unsuccessfully tried to download a 237 bytes file called download.gz) and I though that deleting the cache might help. So I opened Google Chrome options dialog and then the Clear Browsing Data dialog. It looks like this.

I was stunned to see the dialog started with the phrase “Obliterate the following items”. For God’s sake what is obliterating? I want to delete the cache, I don’t care about obliterating, and whatever that means. I don’t want to fetch a dictionary and look-up for the meaning of the word. Excuse me Mr. Google Programmer, that I (probably like many of the people of this world who are not native English speakers) don’t know what “obliterate” means. Yes, it does sound archaic, it does sound like J.R.R. Tolkien but it stops me doing my work. All I wanted to do was selecting what to delete and delete. Instead I spent time figuring whether that means to select what to keep or select what to delete (luckily it didn’t say purge). I had doubts so I had to search for the meaning of the word. Sure, now I know one more (fancy) English word, but overall, I lost one minute doing anything else but deleting the cache.

So, my recommendation to you Mr. Google Programmer is to read Joel Spolsky’s book. I’m sure there are things you can learn from it. And start using simple words and sentences that everyone understands.

As for what “obliterate” means, here it is:

• Mark for deletion, rub off, or erase
• Make undecipherable or imperceptible by obscuring or concealing
• Remove completely from recognition or memory
• Do away with completely, without leaving a trace

After installing Office 2010 64 bit and then 32 bit and both crashing every other 5 minutes, I returned to Office 2007. But then I got the help of Microsoft Support who provided a couple of scripts to clean-up the Windows Registry of anything related to Office 2007 and Office 2010. (The script for Office 2007 is available here; the one for Office 2010 is not yet published). I have then installed Office 2010 32 bit on a clean Registry and now all applications in the package work like a charm. No hanging, no crashing whatsoever. And I must say I was impressed by the support people, how they helped, how they called to check if everything was working, etc. The kind of support I wish to see everywhere.

I also learned that installing the 64 bit version is not recommended unless you really have some demands, like working with huge files, over 2GB (though I’m not sure what are the scenarios when one has Excel files bigger than 2GB). Add-ins for Office 32 bit might not work with the 64 bit version. (Though the add-ins I had in 2007 worked without any update when I installed Office 2010 32 bit.) More information about the 64 bit of Office 2010 can be found in this TechNet article.

• To enable the automatic show of the add-in window when a build/clean/deploy operation starts, check Pop-out automatically when starting a build
• To enable the automatic hiding of the add-in window when the build/clean/deploy operation ends, check Auto hide when the build ends
  • you can set a delay interval for the hiding, varing from 0 to 300 seconds; if the delay is 0, the window is hidden immediatelly after the build ends
  • to keep the window shown when error(s) occurred during the build/clean/deploy operation, check DO NOT auto hide when an error occurs

Here is a screen short of the properties window. It opens from the Settings button.

The add-in is available on the Visual Studio Gallery.

• inproc: the COM server is loaded into the client process; in this case accessing the COM methods is as simple as using an interface pointer when the client and the in-proc server are in the same thread
• local: the COM server and the client are loaded in different processes on the same machine; communication is achieved with the use of proxies and stubs via Lightweight RPC
• remote: the COM server and the client are loaded in different processes on different machines; communication is achieved with the use of proxies and stubs via RPC

In order for the COM Library to be able to locate and instantiate the COM objects correctly, different information is stored in the Windows Registry. The most important information is located under the keys CLSID, TypeLib, Interface and AppID from HKEY_CLASSES_ROOT. The images below show examples for IIS.

HKEY_CLASSES_ROOT\CLSID
Every coclass from the COM server has at least an entry under this key, specifying the CLSID and the ProgID. The CLSID is a GUID that uniquely identifies the class, and the ProgID (programmatic identifier) is a string that identifies the class in a more human readable form. Each ProgID is mapped to a CLSID. The following image shows the mapping for the IIS ProgID.

For each COM class, there must be a key under HKEY_CLASSES_ROOT\CLSID, with the CLSID as the name. The most important sub-keys here are:

• ProgID: the programmatic identifier, mapped on the CLSID; cam contain a version number (as a suffix)
• VersionIndependentProgID: a programmatic identifier without the version information
• InprocServer32: specifies the path of the DLL for the inproc servers
• LocalServer32: specifies the path of the COM executable for the local (out-of-process) servers
• TypeLib: indicates the LIBID of the type library that contains the coclass

Here are several screenshots from registry for IIS CLSID.

HKEY_CLASSES_ROOT\TypeLib
Each type library has a key under HKEY_CLASSES_ROOT\TypeLib, with the name of the LIBID. The sub-keys provide information about the physical location of the type library file (.tlb file) and others, such as flags (FLAGS key) the directory that contains the help file for the type library (HELPDIR key). A LIBID is a GUID that uniquely identifies a type library. A *.TLB file is a binary version of an IDL file. This is used by languages such as VB, Java, Javascript and many others in order to be able to use the COM objects.

The following image shows the type lib information for IIS.

HKEY_CLASSES_ROOT\Interface
Information for all interfaces defined in an IDL file (type library) must be added to the registry. Under HKEY_CLASSES_ROOT\Interface must be a key with the IID of the interface. The IID (interface identifier) is a GUID that uniquely identifies an interface. The most important sub-keys are:

• TypeLib: the LIBID of the type library containing the interface
• ProxyStubClsid32: the CLSID of the marshaller used to marshal the interface; value {00020424-0000-0000-C000-000000000046} identifies oleaut32.dll, which is the universal marshaler.

The following images show the registry entry for the interface IISBaseObject.

HKEY_CLASSES_ROOT\AppID
An AppID (application identifier) is a GUID that uniquely identifies a COM server and is used to describe security and activation settings; it is used for out-of-proc (local or remote) scenarios. Usually the AppID is the same with a CLSID of a coclass from the COM server (without the risk of collision, because the CLSID and the AppID server different purposes). The most important settings are:

• AccessPermission: defines the ACL of users that can access the server
• AuthenticationLevel: defines the authentication level
• DllSurrogate: identifies the surrogate that can host the DLL; if no value is specified, the default dllhost.exe surrogate is used
• LaunchPermissions: defines the ACL of users that can launch the application
• RemoteServerName: identifies the remove server machine

The following images shows the values for an AppID key.