🏗️ AXHook

📜 Preface & Motivation

This framework was originally developed around 25 years ago during the era of enterprise systems engineering to solve complex integration challenges—due mostly to 32 to 64 bits conversion back then, as well as attempts to make OLE containers more stable to crashes in components. Since then, the Windows operating system has evolved significantly; however, developers still face persistent hurdles and interest in running 32-bit and 64-bit COM components interchangeably, as well as seamlessly running in-process components out-of-process (or vice versa) to protect container applications from crashes.

The reason for publishing this code now (while I'm still alive and in my right mind) is to share my early architectural experiences with a new generation of developers who might be curious about COM internals, out-of-process/in-process bridging, and legacy Windows interoperability mechanisms.

---

⚠️ Notice & Disclaimer

Note on Naming & History: This repository is named AXHook to highlight its core interception engine and avoid confusion with the .NET System.Windows.Forms.AxHost class. However, you will notice the internal source files, solutions, and namespaces are heavily built around the original project name AXHost (stemming from the "ActiveXout" architecture that allowed GUI out-of-process servers like Word, Excel, and IE to run "visually" inside ActiveX Containers). This code was written long before Microsoft released the first version of .NET in 2002.

To preserve the historical integrity of the project (and the sanity of the build pipeline), the original AXHost project structure and C++ namespaces have been left exactly as they were written more than two decades ago.

---

🛡️ Current Status & No Warranty

The only modernizations made to this codebase were the minimal adaptations required to achieve a clean, zero-error build on the modern Visual Studio Insiders (2026 v145 toolchain), alongside basic functional testing.

Because the underlying Windows environment and operating system security models have evolved massively over the last two decades, this architecture has not undergone extensive modern stress testing. However, it turns out that despite this, the core COM subsystem has remained largely unchanged—primarily because Microsoft hasn't touched or evolved it in 25 years, effectively abandoning out-of-process bridging architectures to history, as well as in-process COM, ActiveX, ATL, and MFC developments.

📦 Code Completeness & Archaeological Disclaimer: This codebase was restored from old backup media. As such, it represents a raw, frozen snapshot of an active work-in-progress from two decades ago—embarrassing bugs, incomplete edge cases, and architectural quirks included!

I make no claims that this is the absolute final or bug-free iteration of the original internal project. Think of this repository as software archaeology rather than a turn-key modern production library. If you find a bug (or a bizarre late-90s hack), feel free to open an Issue or submit a Pull Request!

NO WARRANTY: This code is provided "AS IS" without any warranties, guarantees, or promises of stability in modern production environments. The author assumes no liability for any system instability, crashes, or unintended behavior caused by these hooks. Use, modify, and experiment at your own risk.

If this code works for you, that's great! If it doesn't work, well... keep in mind I didn't write it (or at least, the person maintaining this repository takes zero responsibility for your legacy COM adventures today!). Use entirely at your own risk as an architectural reference.

---

🔍 Overview

The header files (AXHook.h, AXHost.h, AXHostOleControlSite.h), binaries, source files, and corresponding multi-language samples form a complete architectural framework for overriding standard COM instantiation. They allow developers to seamlessly bridge between 32-bit and 64-bit environments, elevate in-process DLL components to out-of-process servers, or conversely, collapse out-of-process executable COM/OLE servers to run visually "in-process" within the client's memory space.

---

🚀 Fast Track (Quick Start)

If you just want to see the cross-bitness bridging in action before diving into the underlying architecture, follow this exact sequence:

1. Install the Core Binaries: Run the provided Setup.msi (or build the Setup project from source and install it). This step is mandatory, as it normalizes and copies the bridging DLLs into your Windows system directories.
2. Open the Samples: Load the Samples solution in Visual Studio. (Note: You must run Visual Studio as Administrator for the COM registration steps to succeed).
3. Build the ActiveX Control: Build the MFCActiveXControl project for both the x64 and Win32 target platforms.
4. Build and Run the Test App: Build the MFCDialogTest project for both the x64 and Win32 target platforms. Once built, run either version of the executable.

What You Should See

Once the test application is running, click the testing buttons to spin up out-of-process COM instances. Because this architecture perfectly bridges process boundaries, you will witness something that Windows OLE/COM natively forbids:

Below, you can see six MFCDialogTest applications running simultaneously, each displaying its build platform and Process ID. Hosted inside each application is an ActiveX control of the same or opposite build platform, displaying its own architecture (32 or 64 bits) as well as a distinctly different Process ID.

---

⚙️ Deep Dive: Core Header Files & Architecture

1. AXHook.h (The Interception & Hooking Engine)

• Purpose: Acts as the primary entry point for enabling and configuring the engine dynamically or statically.
• Mechanism: Manages the interception layer (AxHostEnable) using injection techniques (via Detours integration) to hook API calls such as CoCreateInstance and redirect them to custom surrogate logic.
• Flags & Controls: Exposes fine-grained execution flags (AXHOST_32, AXHOST_64, AXHOST_MULTI, AXHOST_ALL) that dictate whether components run locally, across process boundaries, or shared within a single multi-use surrogate instance.

2. AXHost.h (COM Server & Surrogate Management)

• Purpose: Defines the server-side architecture and custom class factory interfaces (IAXHostClassFactory, IGetClassObjectFactory).
• Mechanism: Implements the IClassFactory2 interface hack, utilizing CreateInstanceLic with an encoded BSTR key (L"{Target_CLSID}{PROCESID-MULTI-GET-...}") to pass parameters, Process IDs, and configuration flags across process boundaries without requiring custom RPC interfaces.
• Watchdog & Safety: Houses the logic for process health checks (OpenProcess), zombie prevention, and reference-count probing via structured exception handling (SEH).

3. AXHostOleControlSite.h (MFC Container & Window Reparenting)

• Purpose: Solves the notorious UI hosting and message-loop challenges of embedding legacy ActiveX controls and out-of-process windows.
• Mechanism: Overrides MFC's default OLE container manager (CAXHostOccManager) and control site behaviors (CAXHostOleControlSite, MyOleClientSite, MyOleControlSite).
• UI Synchronization: Automatically manages window parenting, hooks message loops to monitor HWND validity, and enforces the WS_CLIPCHILDREN window style to eliminate visual artifacts and drawing glitches during cross-process UI embedding.

---

🔬 Source Implementation Details (AXHost.cpp, AXHost_Server.cpp, AXHook.cpp)

• Surrogate Execution (AXHost_Server): Acts as the external execution boundary that hosts third-party DLLs securely, ensuring that unhandled exceptions or fatal faults within legacy COM components cannot bring down the primary client application.
• Running Object Table (ROT) Management: Internal mapping utilities track active instantiations across process boundaries, ensuring proper cleanup and preventing duplicate server spin-ups when multi-use flags are enabled.
• PEB Spoofing & Automation Arguments: Automatically injects necessary flags (such as /automation) into command-line strings during dynamic loading sequences to satisfy legacy component startup expectations.

---

💻 Multi-Language & Framework Sample Breakdown

The repository provides fully realized test harnesses across multiple languages and frameworks, proving the versatility of the architecture:

1. Native C++ Samples (Samples/CPP/)

• 1. AXHook CreateObject Sample: Demonstrates a direct, drop-in replacement for standard native component creation using the engine's initialization routines.
• 2. AXHookMulti CreateObject Sample: Illustrates how to configure multi-use flags to host multiple COM components inside a single shared surrogate instance, optimizing memory overhead.
• 3. AXHook Custom CreateObject Sample: Showcases advanced configuration parameters, manual flag overriding, and error handling for custom component lifecycles.
• 4. AXHost API: Tests direct interaction with the underlying export functions of the AXHost engine.

2. Managed C# & .NET Samples (Samples/C#/)

• 1–3. CreateObject & Multi Samples: Provide managed equivalents using the AxHostNET wrapper library, leveraging dynamic typing (dynamic) to consume native components without needing explicit primary interop assemblies (PIAs).
• 4. AXHost API: Validates dynamic loading and unloading (LoadLibrary / FreeLibrary) of the native hooking DLLs from a managed CLR execution context.

3. Visual Basic Samples (Samples/VB/)

• Tailored for legacy automation environments and VB.NET codebases, mirroring the C# sample structure to provide out-of-the-box integration blueprints for classic enterprise scripts and macros.

4. MFC & Dialog-Based UI Samples (Samples/MFC/ & AXHostWebBrowserTest)

• AXHostWebBrowserTest & MFCDialogTest: These projects implement complex UI hosting scenarios, such as embedding the legacy InternetExplorer WebBrowser control or custom ActiveX controls inside standard MFC dialog windows.

• Container Integration: Codebases like MFCApplication1 demonstrate the mandatory OLE initialization step (enabling custom control container and site overrides via AfxEnableControlContainer(&_AXHostOccManager);).

5. Cross-Bitness Binary Test Cases (Samples/AxRun Binaries/)

• Legacy 32-bit App using latest 64-bit ActiveX: Tests the engine's ability to bridge architectural divides downwards or upwards, allowing older host processes to drive modern controls seamlessly.
• Modern 64-bit App using legacy 32-bit ActiveX: Validates the inverse scenario—allowing modern 64-bit applications to instantiate rotting 32-bit legacy dependencies without crashing due to bitness restrictions.

---

For deeper architectural insights, refer directly to header files, inline source documentation, and individual sample projects.

---

🎩 A Tip of the Hat & "Premium" Support

I am a retired veteran of the software industry currently living on a fixed Social Security income—to the point where I can hardly afford my internet bill and AI helper!!! In fact, as I've already been forced to sell everything tangible and have nothing else left to sell, I am now offering up this codebase as a digital relic from my active systems engineering days.

This repository is provided strictly as a historical read-only reference. There is no active maintenance, and I will not be responding to questions, bug reports, or pull requests regarding this code—unless your request includes a transaction ID proving you sent a donation to the wallet below.

If this 25-year-old architectural time capsule just saved your modern, well-funded enterprise project from a catastrophic legacy integration failure, please consider a tip of the hat. Donations are genuinely needed, deeply appreciated, and are the only way to get this old developer to come out of retirement to look at your issue!

• BTC (Bitcoin): 3CVm3CZ3JoRv7jW8ypkYfUED599hdorJgJ

Thank you!

---

Copyright Igor G. Tebelev TIG(c) 2026