CppCon 2018: Victor Ciura “These Aren't the COM Objects You're Looking For”

CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/Cpp...
-
Windows COM is 25 years old. Yet it is relevant today more than ever, because Microsoft has bet its entire modern WinRT API on it (starting with Windows 8/10). But, if you’re familiar with the “old” COM with its idioms and SDK helper classes, you’re in for a treat. With the advent of modern C++ 17, using COM objects and new Windows APIs in your applications feels like a completely new experience.
In this session, we’ll explore how using modern C++ features can radically transform the shape of your COM code. By eliminating a lot of boilerplate, your code will be much more readable and maintainable. Classic COM idioms around activation and QueryInterface() can feel totally different with modern C++ helpers. A beautiful example of modern COM usage is C++/WinRT (now part of Windows SDK). This is a standard C++ language projection for the new Windows Runtime API.
COM memory management, data marshalling, string handling can all feel quite mechanical in nature and very error prone, so a little help from modern C++ facilities would be more than welcomed. Error handling and debugging can be cumbersome for COM like APIs; we’ll explore some tricks to improve this experience, as well.
-
Victor Ciura, CAPHYON
Software Developer
Victor Ciura is a Senior Software Engineer at CAPHYON and Technical Lead on the Advanced Installer team (www.advancedins...).
For over a decade, he designed and implemented several core components and libraries of Advanced Installer.
He’s a regular guest at Computer Science Department of his Alma Mater, University of Craiova, where he gives student lectures & workshops on “Using C++STL for Competitive Programming and Software Development”.
Currently, he spends most of his time working with his talented team on improving and extending the repackaging and virtualization technologies in Advanced Installer IDE, helping clients migrate their Win32 desktop apps to the Windows Store (MSIX).
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/reg...
*-----*

[@DarrinCullop]

Thank you for posting all of these talks online!
I feel like I should mention that the code displayed at 8:41 has a bug in it. It will only call CoUninitialize if the call to CoInitializeEx returns S_OK. However the documentation states "each successful call to CoInitialize or CoInitializeEx, including any call that returns S_FALSE, must be balanced by a corresponding call to CoUninitialize".
The fix would be to change the line that says "mClose = (hRes == S_OK)" so that it reads "mClose = SUCCEEDED(hRes)".
Source: docs.microsoft.com/en-us/windows/desktop/api/combaseapi/nf-combaseapi-coinitializeex

[@DarrinCullop]

Apparently, around 12:50 someone in the audience found the same issue.

[@darranrowe174]

At around the 8:45 mark, the helper class is shown with the code:
HRESULT hRes = ::CoInitializeEx(nullptr, aComFlags);
mClose = (hRes == S_OK);
There is also the talk about being the first to initialise COM on a thread. So basically, this is saying that CoUninitialise should only be called if CoInitialize(Ex) returns S_OK.
This goes against what the documentation for CoUninitialise (docs.microsoft.com/en-us/windows/desktop/api/combaseapi/nf-combaseapi-couninitialize) says. It says that CoUninitialise must be called for every SUCCESSFUL call to CoInitialize(Ex), and this includes any that returns S_FALSE too, since they are success values.
"A thread must call CoUninitialize once for each successful call it has made to the CoInitialize or CoInitializeEx function, including any call that returns S_FALSE. Only the CoUninitialize call corresponding to the CoInitialize or CoInitializeEx call that initialized the library can close it."
This means that the COM library is reference counted.
So as an example, if you call CoInitializeEx 3 times and create an instance of an object, you need to call CoUninitialize 3 times for the COM library to unload that instance of the object forcefully. This is also testable. If you load the object, then the COM library will load in any associated DLLs. When you unload the library, it will free any outstanding DLLs. In the situation that I described before, the COM library will only unload the object on the third call to CoUninitialize.

[@Fetrovsky]

I am glad that odious participation is encouraged. Now I'm even more sorry I didn't attend.

[@mfkman]

Just for info: A UTF16 character can be 2 or 4 bytes, UCS2 is always 2. WIndows wide character strings are UCS2 encoded, not UTF16.

[@RaptorFactor5]

The documentation disagrees with you:
docs.microsoft.com/en-us/windows/desktop/LearnWin32/working-with-strings
docs.microsoft.com/en-us/globalization/encoding/surrogate-pairs