Hardcode

It appears that the version of Microsoft ADO that ships with Vista has broken the compatibility with previous versions. The notable difference I have just found is that the ConnectionString property of the Connection object does return a modified connection string excluding the password that was set before :).

So beware of code that initialize a new connection based on the connection string of an existing connection - it will stop working in Vista.

While developing a similar OLE container, I'm having the same problem as the Visio team had here. Luckily they have some weird fixes to the problem instead of explaining it so that other developers can fix the issue also. So currently I am trying to contact the Visio team for some more details.

The issue is with an MSWord OLE object with an enhanced metafile cache that simply dissapears when used with a COMPLEXREGION clipping region and a rotation transform (via SetWorldTransform).

Did you know about them ? :)

int? i = 5;

i = null; 

They were introduced for improved interoperability with databases, so you'd map directly to a nullable column.

At last, they renamed the technology to something more catchy :D Silverlight. It's still not RTM and still no word on whether there will be an official way to run apps on the desktop.

Here the HATRED cracking group is making fun of the poor cracking performed by another group, ViTALiTY. Assembly code included and commented.

This is the code as it looks after SecuROM has molested it. This
was once a real routine in the virgin executable and clearly plays
some sort of role as a part of the game code. Partially relocated
routines is a common SecuROM feature and you will see it have been
fixed in several previous hatred releases. We were impressed that
ViTALiTY was able to crack an executable with this feature so we
decided to take a closer look.

OH MY GOD!

004ACB80 B8 00000000 MOV EAX,0
004ACB85 C3 RETN

What a sophisticated fix. Seems ViTALiTY have decided that this
routine is not important and since they were unable to rebuild the
original code they simply inserted a MOV EAX,0 RETN which means
that the entire routine is now disabled. It is not for us to judge
whether this routine is an essential part of the game code. If the
ViTALiTY crack appears to run flawlessly then it probably isnt
but the fact remains that this code was in the original executable
and therefore it should also be in the cracked executable. This is
an undeniable fact and any unbiased cracker you ask will agree.

And the follow-up.

Beginner's guide 

How to move a dialog from a .RC file to another one while moving the symbols also:

- File / New / Resource Script 

- beware to not overwrite your existing resource.h - make a copy somewhere

- right click on the new .rc file / resource includes / change the symbol header file

- copy your previous resource.h to its original filename

- copy the dialog resource from the resource tree / paste in the other resource tree

- the symbols are automagically transferred!

- remember to #include your new .rc file in the main one 

Which ones are global and which ones are local ?

- System Handles (such as files, sections, mutexes, semaphores, processes, threads, jobs, ...) are bound to a process and are only valid in it's scope. They may be inherited with CreateProcess() (depends on how the handles were created) to other processes or - as you mentioned - duplicated into the scope of another process. In kernel mode attaching to another process makes it's handle table available.

- User Handles (HWND, HICON/HCURSOR, HACCEL, ...) are global for all processes that share the same window station. They don't need to and can't be marshalled. However, system security may prevent access to objects belonging to threads of other desktops or when other restrictions are active (such as UI restrictions by jobs)

- GDI Handles are session-global. However, it's only possible to access global GDI handles, such as stock objects, and GDI objects created by the process itself. But the handles are unique, so it's impossible that there are same handles for different processes that are assigned to two different objects. 

Description found here. 

It appears that maps.live.com has bird's eye imagery for the entire San Francisco Bay Area! Here's a very detailed view of Googleplex.
 

WPF is so terribly bloated, check below the top of the stack with the mouse click handler:

... and right above it's the WndProc handler that receives the click. 

operator&   Releases any encapsulated interface pointer, replacing it with NULL, and returns the address of the encapsulated pointer. This allows the smart pointer to be passed by address to a function that has an out parameter through which it returns an interface pointer.

There's still the cases when the behavior above is wrong, for example when you need to pass an interface pointer "by reference" (to a VB method with ByRef var As class). In this case, writing &pObject destroys the object and sends a NULL pointer.

Obviously, they did this so you will be able to write { CObjectPtr pObject; CreateNewObject( &pObject); }. There's no way in Visual C++ 6.0 to get directly a l-value pointer of the interface (in later versions I've just seen they added a Interface*& GetInterfacePtr() throw(); )

In case you didn't know, C++ from Visual Studio 6.0 onwards has accessors similar to the C# ones, using the following constructs:

(from msdn) 

Contrary to what they are saying, these are not restricted to be used only with COM objects.