Sending input events to background applications in Win32

[bhua8122]

Our goal is the create a application sharing system that allows users to drag the applications off-screen into other people's desktops for them to use while maintaining control of the local desktop. Currently we plan to implement it by creating a virtual screen and placing the shared application there. VNC will then be used to stream windows to peers and input will be routed over.

The problem I am facing is that Win32 only has one event queue and allows input only to the active window/app. This is a deal breaker as we wanted to send input coming in from the network to a specific, background application on the virtual screen. We have to do this as the active window from the local user's perspective will the the one they are using on there real, physical desktop.

I want to write a wrapper for the Win32 DLL(s) and reimplement the window management with multiple event queues/multiple activate windows. I don't need multiple pointers (altough that has been done by CPN Mouse) to achieve this as I just need to route calls like SendInput to the desired background application (clicks, drags, over, up/down and keystrokes).

Since Wine is also a (re)implementation of Win32, I was hoping developers here will have some insight on where I should start looking and whether the entire modification is in just 1 DLL, a collection of them or whethere it is even feasible to do such a thing.

[vitamin]

I want to write a wrapper for the Win32 DLL(s) and reimplement the window management

Good luck! You won't get too far with this effort - some parts of it inside kernel.

The problem I am facing is that Win32 only has one event queue and allows input only to the active window/app.

What do you mean one queue? Each thread can have a message queue. And window doesn't have to be active to have focus. All though it's the case in 99.99% cases (otherwise things break).


Window management is the most convoluted and broken part of windows where most applications depend on one bug or the other. This is where term "bug is a feature" came from. Wine has lots of issues in that area because ... it does not do window management itself. This is what WM (KDE/Gnome) is for. And they don't always follow the brain-damaged M$ logic.

[bhua8122]

That is the thing, I don't want to give the background program focus.
I want to send key/mouse input to a background program without activating it or giving it focus. (i.e. effectively have multiple activated foreground windows with individual input [not message] queues). Notice that SendInput in Win32 does not allow you to specify the handle of the eindow receiving input, it alway goes to the activated window (one with focus).

If I am actually wrong about this, then great

[vitamin]

I want to send key/mouse input to a background program without activating it or giving it focus.

That exact thing lives in the kernel.

You can send messages to any window. But kernel parses hardware messages (mouse, keyboard) and generates messages to give to window that's currently under pointer/has keyboard focus. As well as generating event sequences for window state changes. Some of it in user32 some in kernel.

How exactly that part is done - you won't find in Wine. Wine does it in a totally different way. Hence all the problems in that area.

[bhua8122]

Thanks for your insights. would you be able to link me to the problems with Wine's implementation? If they are minor I might try running Wine on top of windows (NT based) and pass through all calls except the input handling, which I will try the patch Wine to accommodate multiple activated windows..

[bhua8122]

You can send messages to any window.

Does that mean I can send input events to any background window *without* causing it to become the active window? That is my main goal.

[vitamin]

You can send messages to any window.

Does that mean I can send input events to any background window *without* causing it to become the active window? That is my main goal.

SendMessage doesn't care if window is background or foreground.
In your example you used SendInput which generates fake hardware event which goes straight into kernel. There isn't much you can do about that.

Wine on top of windows (NT based) and pass through all calls except the input handling, which I will try the patch Wine to accommodate multiple activated windows.

Such core Wine pieces won't work without major modifications. You can look at the source yourself. And like I said, Wine does not manage windows that's WM's task.

[bhua8122]

The main problem is this:

Scenario: two windows, w1 and w2, are executing on computer pc1.
user u2 on pc2 is remotely controlling w2 from pc2 over LAN.
w1 is on desktop d1 (real display)
w2 is on desktop d2 (virtual screen of pc1)

user u1 is locally controlling w1, this means on pc1, w1 is the active window with input focus..

If I call SendMessage to send an input event to w2 (background window), will w2 become the new active window with focus, leaving u1 frustrated and confused when he/she next type a letter, and instead of it going into w1, goes to the 'invisible' w2?

[bhua8122]

I think you were right. At least you are correct about the individual message queues.

Using SendMessage I was about to send keydowns without changing the activated window.

I have yet to test clicks but hopefully it will also work!

The only issue is drawing and dragging, I am not really sure about those. Is there a dragstart and dragend? but what about the motion in between, how does one simulate those?

Thanks for pointing me in the right direction with regards to SendMessage. I would have been doomed to fail had I tried to reimplement parts of Win32!!!

[bhua8122]

Correction:

Using SendMessage I was *able* to send keydowns without changing the activated window.