What is the best way to insulate new C++ code from an older (binary) component using a different CRT?

I work on a large codebase for a Windows desktop application written in C++.

Many years ago, my company paid license fee to a much bigger company for use of a component which is incorporated into our software and provides a critical service. The component is a binary blob with some header files and was compiled using the VS2008 runtime.

Currently, as a result, the entire application is now dependent on the VS2008 runtime. We are unable to upgrade to modern C++, or newer versions of the libraries we use (we're stuck on Qt4 rather than Qt5 for example). For various reasons, there is little to no chance of said company ever providing updated blobs and, whilst we are planning to write our own replacement, it will take a lot of time.

In the meantime, I would like to be able to wrap this component up in some way and insulate it, so we can upgrade the rest of our code to a later runtime, and communicate with it using JSON or similar. Potentially at some point in the future we may replace the component with something of our own (or something open source) not written in C++ at all.

I can think of a number of ways of doing this, but I'm not sure which is best, and which will give us the most flexibility going forward. Reading about COM, it seems that this was the very purpose it was created for, but I don't know if COM is still actively developed and supported, and if it will tie us forevermore to the Windows ecosystem. DCOM is the non-Windows version but if anything that seems even more abandoned.

I'm interested in any suggestions as to the best way to proceed. Thus far my ideas are:

Very carefully design a DLL (which may or may not work, I can't tell from How do I build a runtime version agnostic DLL in C++?, but it looks like it will be suboptimal)
Use COM (see reservations above)
Run as a separate process, and pipe data via cin and cout (restricts to text data and might be slow?)
Run as a separate process, and run a simple client/server relationship (seems heavyweight)

Solution

COM is not actively developed mostly because it's finished. It is actively supported, though. For instance, when Windows went 64 bit, COM was also ported to 64 bits. It gets security updates when necessary.

DCOM is the distributed variant of COM. I wouldn't bother; you just design everything to run on one PC using a single user account. That's already how your app runs anyway.

VS2008 is entirely happy to use BSTR strings over (D)COM, and VS2019 has a convenient _bstr_t wrapper for that. (I don't remember if VS2008 already had _bstr_t).

You typically don't need to use all of the features of COM. COM was designed as an interop platform between many varied applications, but you have two parts of a codebase written by the same developers, which only need to work with each other. There's no need to dynamically discover COM interfaces etcetera. You can just share a .h file with the interface definitions.