573414

Yet another reason to enable FxCop is it double checks some interop defines (Portability and Interop groups). After enabling FxCop on one of my home brewed interop libraries I was surprised that it complained I had some 64 bit portability problems with my HeapCreate and other Heap* API’s.

This API in particular caught me off guard because I did a 64 bit portability check of my interop library recently I specifically looked up that function. I verified that Heap* used DWORD’s for sizes which compile to 32 bit numbers on 64 bit.

After the FxCop warning I took yet another look and sure enough HeapCreate is defined to take in DWORD’s.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcekernl/html/_wcesdk_Win32_HeapCreate.asp

However in my experience FxCop is generally correct if a bit paranoid in places. After confirming it caught slip ups in a different interop API I decided to triple check my Heap* definitions. When in doubt go to the source (winbase.h in this case). Sure enough FxCop is correct and msdn is wrong. Doing a more refined search I found that the correct documentation is available on windowssdk.

http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/heapcreate.asp

I consider this further proof that FxCop is a great tool that should be used for any library development (home and most especially professionally).

In retro-spec if you take a very close look at the first link you’ll notice it’s actually the API for WinCE. I find it strange that it turns up higher in search results that the normal documentation.