Back in a Motel again and headed home soon so I can reply.
Wasn't familiar with the CodeProject Tutorial but am very, very familiar with the Jeff Glatt Tutorial, which has been considered by all as ground breaking on that topic. In fact, I wrote a derivitive of it here in my COM Tutorial #2....
In mine I provided both PowerBASIC and C versions of the same exact COM Object, with extensive discussion.
I'm surprised you are interested in this stuff. Not many are. I guess from my standpoint, the reason I was always interested in it, was the 'cross-language' thing. I always felt it was cool to be able to build an application out of various code building blocks where it doesn't matter if the various parts are written in different programming languages.
Where I feel my Tutorial #2 might be superior to Jeff Glatt's is that his is a special case of a COM interface/object with only one interface - IExample. What happens when there are numerous interfaces doesn't follow directly by extension when one has multiple interfaces, and the mechanics of switching/casting between the various interfaces is critical, and it took me some mental calories to figure it out. This issue is completely hidden by C++. One can only see what is going on in C. Therefore, for a full understanding of COM and its relation to C++ one must first understand it in C - in my opinion.
When I first started working on it my first efforts, which occupied many months of fooling around with it, were to attempt to 'dump' the memory contents of various blocks of memory to see how the various objects were constructed. The objects consist of several different memory allocations, with member variables and virtual function table pointers in one location, and the virtual function tables which contain pointers to the member functions in other places. Given a pointer to an object, one must understand where the virtual function table pointers to the various interfaces are located, and within the COM Object itself, how to switch among them. That Tutorial #2 explains all that.
That MSFlxGrd.ocx example I gave you a link to was an important milestone for me because at that point I felt like I understood the material. It took me several years of intense effort to get that far. I was greatly influenced by the work of Jose Roca on this stuff who I and many others consider to be something of a genius. In the very early 2000 time frame most PowerBASIC users did not know how to write fancy GUIs in PowerBASIC like could be easily produced in Visual Basic, and the reasaon for that was that Visual Basic made extensive use of these fancy ActiveX Controls such as grids and other things which weren't part of the standard Windows Controls. Jose personally detests C++ so had to figure all the low level details of this stuff out himself from the Microsoft documentation, and he had to build everything up from scratch using memory allocations and types/structs like Jeff Glatt did. Once he figured it out he made all his code freely available, and 3rd party PowerBASIC tools vendors incorporated his work into their IDEs which enabled a lot of PowerBASIC users to be able to build fancy GUIs with PowerBASIC, but without all the bloat of Visual Basic. It was kind of an ultimate solution, actually.
Well, maybe not. While the PowerBASIC code itself was small and tight, the ActiveX Controls provided by Microsoft were decidedly not. Fact is, they were pretty bloated, just like everything Microsoft touches. I recall writing a major application at work, which had previously been a major mainframe application, and I had written maybe 15,000 lines of code. It was a database type application, where a database on a server was accessed, and the data was viewed in grids throughout the application. My PowerBASIC code built to something like 500k, but the MSFlxGrd.ocx dependency was also something like 400k or 500k! That seemed out of kilter to me. At that point I wondered if I couldn't create a grid control myself that was smaller, or use something else.
The 'something else' option actually is an option. In the early 2000s when a lot of us moved from Visual Basic to PowerBASIC, we were all somewhat addicted to ActiveX Controls. But there is an alternate Windows Control architecture, and that would be 'Custom Control' architecture. At that time a PowerBASIC 3rd party vendor was selling a Grid Custom Control which was nice and it was just 50 k. I moved to that and used it for many years.
But my ultimate goal was to write my own ActiveX Grid Control using the COM/OLE architecture. This occupied my best efforts for many years. As an aside, I eventually accomplished that, and my most recent version of it I have built in x64 and it is a full featured grid control and its only something like 16k!!! But to accomplish that I had to write my own C Runtime, because, like I said, Microsoft bloats everything it touches.
But unless you have old Microsoft Visual Basic 6 Enterprise Edition installed on your system, you likely won't be able to test run that MSFlxGrd code I posted a link to. But I've posted something very similiar here couple years ago that you could run, and that would be about the same type code that utilizes the Microsoft Internet Explorer Shell.Explorer ActiveX Control. In that code I posted, if one were building with one of the old Mingw build chains, you could build a browser in about 12k or so. I'll see if I can find that link from this web site...
...and that's actually buildable in x86 or x64, as Microsoft provides the Shell.Explorer ActiveX Control (heart of Internet Explorer) in both x86 and x64 forms.