Winit: Is it possible to wrap an existing window?

[LordBenjamin]

Is it possible to use winit to get a Window struct representing an existing window (not created by winit), given a RawWindowHandle?

i.e. an equivalent to the .NET NativeWindow.FromHandle(IntPtr) method

[goddessfreya]

Afaik, no.

[LordBenjamin]

Thanks for the response.

Are you able to provide any detail as to why this isn't supported?

• Outwith scope / ethos of winit
• Technically challenging / impossible
• Nobody has needed to do it yet
• Something else?

[LordBenjamin]

Looking at the implementation a bit more, the init method

• Creates a window using winuser::CreateWindowExW
• Wraps the resulting HWND using WindowWrapper(handle)
• Creates an actual Window struct using

let win = Window {
        window: real_window,
        window_state,
        thread_executor: event_loop.create_thread_executor(),
    };

Since real_window is a wrapper around the HWND, this could presumably be substituted for the handle of an existing window (within the process boundary)?

window_state looks like data that should be possible to retrieve from an existing window via the win32 API.

Not sure about thread_executor / the events loop and how this might map to an existing WindowProc. However, if the window was created externally, do we need to manage the event loop at all? (messages will presumably be being pumped by the host application)

[goddessfreya]

I don't think anyone's needed to do it before. What exactly would be the use case? Would the window be driven with winit's eventloop or be externally driven? I can't imagine this would be an easy task.

[Azorlogh]

This would be useful for audio plugins (VSTs), since they can only use the raw window handle given to them by the host.

[LordBenjamin]

What exactly would be the use case?

In a word - interop. My interest just now is mostly in using a Rust library to draw 3D graphics in a non-Rust host application. @Azorlogh's example of VST plugins is another use case.

Would the window be driven with winit's eventloop or be externally driven?

Using the .NET NativeWindow class as a reference, I'd suggest the event loop would be pumped by the host application (that created and owns the window), but that winit could subclass the window and listen to the loop, handling events on the Rust side as required.

[Osspial]

AFAIK the main use for making Winit able to handle foreign windows is so that, when Winit eventually gets a child/embeddable window API, you can parent Winit windows to foreign windows in a sane way. Is that correct? If so, it would probably be easier to have that API take a &impl HasRawWindowHandle than it would be to adapt Winit's logic to foreign-owned windows.

[LordBenjamin]

That sounds like another use case.

For me it's less about being able to parent a winit-owned window to a foreign window (or vice versa), but rather about being able to access data/events from a foreign window.

e.g.

• Create a window in C#
• Pass the window handle into a Rust library
• From the Rust library, query the window dimensions, react to the window paint events, etc for the same window that was passed in