如何将C++类非静态成员函数作为指针传入WinAPI完成注册

WinAPI 全部采用C风格的函数回调约定，要求传入的函数指针签名（包括调用约定、参数列表、返回值）完全匹配定义。C++非静态成员函数隐式携带this指针作为第一个参数，默认使用thiscall调用约定，和WinAPI要求的__stdcall调用约定、参数列表完全不匹配，直接传必然触发编译错误。
直接把所有成员函数改成静态的方案，本质是把类实例的状态全部赶到全局变量/静态存储区，会导致业务逻辑和静态上下文强耦合，后续多实例、多服务场景下维护成本极高。

这是Win32开发里绑定类实例和回调的通用标准写法，完全不会破坏原有类的设计：

1. 仅写一个签名完全匹配WinAPI要求的静态/全局跳板函数，这个函数不包含任何业务逻辑，只做参数转发
2. 提前把类实例的this指针存在WinAPI允许透传的上下文位置，跳板函数执行时取出这个指针，转为对应类的指针后直接调用实例的非静态成员函数
3. 所有业务逻辑全部写在非静态成员函数中，和普通类写法没有区别

针对你给出的Windows服务场景，ServiceMain回调本身没有提供自定义上下文参数，我们可以在类内维护一个服务名到实例指针的静态映射表，跳板函数通过传入的服务名找到对应实例指针完成转发即可，修改后的可运行代码如下：

#include <windows.h>
#include <winsvc.h>
#include <string>
#include <unordered_map>
#include <mutex>

class Test_service {
    std::wstring svc_name;
    SERVICE_STATUS_HANDLE svc_status_handle = nullptr;

    // 静态映射表：存储服务名到类实例的指针，多服务场景也能正常工作
    static inline std::unordered_map<std::wstring, Test_service*> instance_map;
    static inline std::mutex map_mutex;

    // 静态跳板函数：签名完全匹配LPSERVICE_MAIN_FUNCTIONW要求
    static void WINAPI service_main_bootstrap(DWORD dwNumServicesArgs, LPWSTR* lpServiceArgsVectors) {
        std::wstring current_svc_name = lpServiceArgsVectors[0];
        Test_service* instance = nullptr;
        {
            std::lock_guard<std::mutex> lock(map_mutex);
            if (instance_map.contains(current_svc_name)) {
                instance = instance_map[current_svc_name];
            }
        }
        if (instance) {
            // 转发到实例的非静态成员函数，所有业务逻辑在这里实现
            instance->serv_main_func(dwNumServicesArgs, lpServiceArgsVectors);
        }
    }

public:
    Test_service(const std::wstring& service_name) : svc_name(service_name) {
        // 构造时把当前实例注册到映射表
        {
            std::lock_guard<std::mutex> lock(map_mutex);
            instance_map[svc_name] = this;
        }

        // 注意：SERVICE_TABLE_ENTRY数组必须以NULL项结尾，原代码漏写该条目会触发运行时错误
        SERVICE_TABLE_ENTRY service_table[] = {
            {const_cast<LPWSTR>(svc_name.c_str()), service_main_bootstrap},
            {nullptr, nullptr}
        };
        StartServiceCtrlDispatcher(service_table);
    }

    // 所有业务逻辑保留在非静态成员函数中，可正常访问所有类成员
    void serv_main_func(DWORD dwNumServicesArgs, LPWSTR* lpServiceArgsVectors) {
        // 注册服务控制回调时可直接传this作为上下文，不需要再走映射表
        svc_status_handle = RegisterServiceCtrlHandlerExW(
            svc_name.c_str(),
            // 无捕获lambda可直接转为C风格函数指针，作为控制回调的薄跳板
            [](DWORD dwCtrl, DWORD dwEventType, LPVOID lpEventData, LPVOID lpContext) -> DWORD {
                auto* inst = static_cast<Test_service*>(lpContext);
                return inst->service_ctrl_handler(dwCtrl, dwEventType, lpEventData);
            },
            this
        );

        // 此处编写服务初始化、业务运行逻辑即可，和普通类成员函数写法没有区别
    }

    DWORD service_ctrl_handler(DWORD dwCtrl, DWORD dwEventType, LPVOID lpEventData) {
        // 服务控制逻辑（停止、暂停响应等），可直接访问类的所有成员
        return NO_ERROR;
    }

    ~Test_service() {
        // 析构时从映射表移除实例
        std::lock_guard<std::mutex> lock(map_mutex);
        instance_map.erase(svc_name);
    }
};

• 没有任何业务逻辑散落在静态函数中，静态方法只做几行的指针转换和转发，不会形成你担心的静态调用链问题
• 所有业务逻辑都在非静态成员函数内，可以正常访问类的私有成员、虚函数，完全符合面向对象的设计要求
• 没有未定义行为，完全符合WinAPI的类型要求，兼容所有Windows版本和编译选项
• 支持单进程多服务的场景，不需要修改架构即可扩展

注意：不要尝试将非静态成员函数指针强转为WinAPI要求的函数指针、或者通过内联汇编篡改栈帧传入this，这类写法属于C++标准未定义行为，在不同编译选项、不同编译器、不同系统版本下随时可能出现崩溃。

内容的提问来源于stack exchange，提问作者hgrev