So after a bit more research into this, I think it's impossible to move the HWND from this class while keeping RAII cleanup, but we can remove GHOST_WindowWin32 and GHOST_SystemWin32. I think there are a lot of maintainability benefits of removing the latter two as it makes pointer ownership much cleaner, and between the two HWND is the less risky thing to use after it's resource has been freed.

Sorry for asking for the removal of passing in a HWND just to ask you to add it back in to instead remove the GHOST_ dependencies, the former was a lower hanging fruit to understand at the time.

Note removing the GHOST_System dependency will also remove the need for GHOST_EventTrackpad as the event generation would be moved out too.

DM_ASSERT is a tad misleading, assert is expected to be a noop in release. DM_CHECK_RESULT_AND_EXIT_EARLY was suggested as better but not ideal alternative when I asked other maintainers.

I tend to prefer not using macros, but in this case I think it's the right call given the constraints.

I'd pull out the "could fail" dmanip setup code into a factory function and make this constructor private. This cleans up following code that could assume everything is initialized if the function can be called.

Example of a check that could be made obsolete with the above factory function suggestion.

Since this loop is called every frame, I think we should track the viewport's DIRECTMANIPULATION_STATUS and only call UPDATE when the status is DIRECTMANIPULATION_RUNNING or DIRECTMANIPULATION_INERTIA.

In GHOST_DirectManipulationHelper::create the current pattern is to create the Helper, and the populate it. Because of this it may be in a partially initialized state during destruction, and these cleanup calls would be null pointer dereferences.

My preferred fix here would be to not allow Helper to ever be in a partially initialized state. What this would mean is that in create instead of passing references to the helper's members, you would pass local variables to initialize with and initialize helper with those.

Just as an example (removing error checking for clarity).

// Before:
GHOST_DirectManipulationHelper *GHOST_DirectManipulationHelper::create(HWND hWnd, uint16_t dpi)
{
  GHOST_DirectManipulationHelper *helper = new GHOST_DirectManipulationHelper(hWnd);

  HRESULT hr = ::CoCreateInstance(CLSID_DirectManipulationManager,
                                  nullptr,
                                  CLSCTX_INPROC_SERVER,
                                  IID_PPV_ARGS(&helper->m_directManipulationManager));

  hr = helper->m_directManipulationManager->GetUpdateManager(
      IID_PPV_ARGS(&helper->m_directManipulationUpdateManager));
  ...
  return helper;
}

// After:
GHOST_DirectManipulationHelper *GHOST_DirectManipulationHelper::create(HWND hWnd, uint16_t dpi)
{
  Microsoft::WRL::ComPtr<IDirectManipulationManager> directManipulationManager;
  HRESULT hr = ::CoCreateInstance(CLSID_DirectManipulationManager,
                                  nullptr,
                                  CLSCTX_INPROC_SERVER,
                                  IID_PPV_ARGS(&directManipulationManager));

  Microsoft::WRL::ComPtr<IDirectManipulationUpdateManager> directManipulationUpdateManager;
  hr = directManipulationManager->GetUpdateManager(
      IID_PPV_ARGS(&directManipulationUpdateManager));
  ...
  return new GHOST_DirectManipulationHelper(hWnd, directManipulationManager, directManipulationUpdateManager, ...);
}

I'd remove this, no need to repeat what should be in Window's documentation.

Instead of polling this every frame, pass in the dpi during initialization and update it when WM_DPICHANGED occurs. This gets us halfway to removing the GHOST_Window dependency.

This state machine, and why it's necessary, should be commented. Your explanation in the prior inline comment should work here.

Nitpick: phrasing "next updates" is a bit awkward, I'd use "following updates".

Instead of pushing event here, save the accumulated state. Add a function GetTouchpadInfo to the helper which grabs the accumulated state, returns e.g. a TOUCHPAD_INFO struct. When that state is pulled, it should be zeroed sans the fractional part.

This allows us to remove GHOST_System and the remainder of GHOST_Window from the touchpad handler.