Intercepting COM Objects with CoGetInterceptor

Wednesday, February 28, 2018

A while back I wrote about COM interception with CoTreatAsClass. The idea there is to redirect a CLSID to another CLSID implemented by the interceptor. This has the advantage of automatic redirection in cases where a different implementation is desired. However, it makes it difficult to just wrap the original class because its creation becomes masked as well, and so CoTreatAsClass needs to be called again, removing the redirection just enough time to create the original object. This creates an inherent race condition, where new instances could be created in between and the interception "missed". The COM infrastructure includes other...
tags: , , , ,
no comments

Integrating COM IPC into Existing Executables

Friday, October 6, 2017

A few days ago at work, a requirement arouse to create some form of inter-process communication (IPC) between two cooperating processes where the source code for the executables themselves already existed, so such mechanism should integrate into the existing code as easily as possible, while providing bi-directional communication. Several options were brought up, including pipes and sockets. The processes are services and have no UI, so Window messages were not an option. Other ideas included shared memory with notifications using kernel event objects... and then I suggested COM. There was a brief silence and then people started murmuring things like "COM...
tags: , , ,
no comments

Hooking COM Classes

Monday, August 7, 2017

There are some common scenarios that benefit from the ability to hook operations. The canonical example is hooking Windows API functions for debugging purposes, or for malware detection. In this scenario, some DLL is injected into a target process and then hooks relevant functions. There are several ways to do that, but that is not the focus of this post; the interested reader can search the web for more information. In the Component Object Model (COM) world, things are not so easy. Since COM is object based, it's not generally possible to get the address of a COM interface method,...
tags: , , , ,
no comments

My Wish List for Windows “Blue”

Friday, May 17, 2013

Many rumors are flying around at this time about the upcoming release of Windows 8.1 (code named “Blue”, which represents a wave of product updates, including Windows Phone and others). I thought I‘d state my hopes for this release, not just in terms of user features, but also from a developer’s perspective. As a developer, I spend most of my time on my trusty laptop, not some tablet based device. Naturally, the desktop world is my friend. The Windows 8 Start screen is close to perfect for tablet devices, but for the desktop – it’s practically useless. With many...

Windows Runtime with C++/C#: Anatomy of a WinRT Class

Sunday, December 30, 2012

The Windows Runtime (WinRT) is based on COM (I referred to it in the past as a “better COM”), which means every method and property must be part of an interface. Also, COM does not support static members (only instance members) and does not easily support parameterized constructors. Inheritance is again an issue in classic COM – the closest thing is COM aggregation, and that’s not really inheritance in the usual sense of the word.Using C++/CX or a .NET language allows creating WinRT types that support methods, properties, constructors and static members, and even events (another feature that is...

Windows Media Foundation in Windows 8

Tuesday, November 20, 2012

Windows Media Foundation was introduced in Windows Vista as a future replacement for DirectShow, enhanced in Windows 7, and naturally, further enhanced in Windows 8. I’ve blogged about WMF before. While looking at the MSDN docs on WMF, it seems the content has not yet been updated for Windows 8. Windows 7 enhancements are considered there as such. Looking at the API reference, however, shows some new interfaces that are only supported starting with Windows 8.One such interface is IMFMediaEngine and its extended version, IMFMediaEngineEx. The docs hint that the former interface is the playback interface used by the...

Windows 8 Store apps with C++/CX: thoughts & tips

Friday, October 5, 2012

I’ve been working on Windows 8 apps lately using C++, not C#. I’ve been doing a lot of C# work in the past few years, and I must admit I love the elegance of C# and the productivity of .NET, not to mention the powerful toolset bound with Visual Studio. Still, ever since WinRT was introduced, the idea of using native code only had its appeal. Even if the app does not require special libraries, such as DirectX or C++ AMP, native code has less overhead and lower memory consumption compared to a .NET app.Naturally, I was using the...

Using C++/CX in Desktop apps

Saturday, September 29, 2012

In my first and second post on using WinRT in a desktop app, we’ve used the raw API and then WRL to create and access WinRT objects. It would be easier to access WinRT using the new C++/CX extensions. Can we do that from a desktop app? Let’s give it a try.We’ll start with a regular Win32 Console application project. The first thing we need to do is to enable the C++/CX extensions. Open project properties and navigate to the C/C++ / General node and set “Consume Windows Runtime Extension” to Yes:Building the project now causes the compiler to...

Accessing WinRT from Desktop Apps (Part 2)

Monday, September 24, 2012

In the previous post we’ve seen how to instantiate WinRT objects using the raw (Ro, pun intended) API. In this post, we’ll see some shortcuts to make our lives a little easier.These shortcuts are part of the Windows Runtime template Library (WRL). This is a helper library, similar in spirit to the Active Template Library (ATL) used for classic COM work.First we need to include the main WRL header, <wrl.h>. Also, we’ll include another header with some extra helpers, that are not included with the primary header:#include <wrl.h> #include <wrl/wrappers/corewrappers.h> Next, we’ll add using namespace statements to make our lives a...
no comments

Accessing WinRT From Desktop apps (Part 1)

Thursday, September 13, 2012

The Windows Runtime (WinRT) is the underlying runtime for Windows 8 Store Apps (“Metro”), but some of it can be actually used outside the Metro environment, in regular desktop apps, such as pure Win32, MFC, etc.There are several ways to go about it; most of the time we’ll use the Windows Runtime Library (WRL) to help out with some of the low level details. Or, for a true high level abstraction, we can use the C++/CX extensions to the C++ language (making our code non-standard). But, just for kicks, let’s see how we can access WinRT types with no...