The next piece is the HCOUNTER structure. Every value you wish to monitor gets one HCOUNTER, and all of them are managed by the HQUERY (or, by the Query class). However, wrapping the HCOUNTER poses a special challenge. You create it, but it must be filled by another process--the one that's being monitored. This means it needs to exist in Shared Global Memory. You never have a HCOUNTER; you have to use a pointer to an HCOUNTER, and allocate the HCOUNTER with GlobalAlloc(). This greatly complicates making a wrapper class.
At first, you might decide to store a HCOUNTER* as the class's sole data member, calling GlobalAlloc in the constructor and GlobalFree in the destructor. This method is problematic. You'll need to write a copy constructor as well, but how should that work? Normally, the copy constructor would allocate a new block of memory and copy the data from one to the other. The problem is that this block, by its very nature, is shared. Some other program is both looking at and writing to it. If you allocate a new block, they may be identical for a moment, but the other process will still be writing to the first one.
Another solution is to have just one memory block, and simply pass a pointer around to it. In this case, you can't have the destructor free the block. For example, if you were to return such an object from a function (which is something you will want to do), you create a new object by calling the copy constructor (copying just the pointer), and then the original object goes out of scope as the function ends (and its destructor is called, freeing the block). But removing the allocation/deallocation from the constructor/destructor leaves you with the wrapper class doing nothing at all. It was supposed to make working with a HCOUNTER simpler! You need a reference counted pointer to keep track of how many pointers to the block are being used, and to automatically delete the block only after all references to it are destroyed.
Pointer classes like this are commonly referred to as "smart pointers". The best known is auto_ptr, which is now part of the Standard C++ Library. Unfortunately, this leads some to believe that auto_ptr is right for every situation that calls for a smart pointer, but this isn't so. Auto_ptr has a very specific use, but this is not it.
Writing a reference counted pointer class is not particularly difficult, and is described in a number of reference books. You don't have to worry about this, however, as the work is already done for you by the good folks at Boost.org. Boost is a public organization developing an open source C++ library of commonly used tools.
One of the very first things added to Boost was the Smart Pointer library, which includes shared_ptr<>. Considering it's general utility, and growing use, it has a very good chance of being added to the Standard Library when the next C++ Standard is complete (circa 2005 or so). The more it's used now, the better the chances it has of becoming part of the Standard.