wine for two, please.

Hi,

I dont know much about the message queue works on Wine but wondered if  
there was means of running two progams in the same context on wine in such  
a way that they use the same message queue and can therefore potencially  
interact.

As I understand it, running two instance of command line wine is more  
analogous to having two different computers running each app under windows.

My goal is getting NatSpeak dictated text messages freed from the confines  
of the wine instance of the app. This would seem to be one approach if  
wine can run more than one process at a time.

TIA.

[Marcus Meissner]

On Tue, Nov 01, 2005 at 08:03:07PM +0100, [e-mail] wrote:
> Hi,
>
> I dont know much about the message queue works on Wine but wondered if  
> there was means of running two progams in the same context on wine in such  
> a way that they use the same message queue and can therefore potencially  
> interact.
>
> As I understand it, running two instance of command line wine is more  
> analogous to having two different computers running each app under windows.
>
> My goal is getting NatSpeak dictated text messages freed from the confines  
> of the wine instance of the app. This would seem to be one approach if  
> wine can run more than one process at a time.

Running two "wine foo.exe" will act as if on the same machine, including
interchange of windows messages if the apps do that.

Ciao, Marcus

On Tue, 01 Nov 2005 21:54:51 +0100, Marcus Meissner  
 wrote:
> > My goal is getting NatSpeak dictated text messages freed from the  
> > confines
> > of the wine instance of the app. This would seem to be one approach if
> > wine can run more than one process at a time.
>
> Running two "wine foo.exe" will act as if on the same machine, including
> interchange of windows messages if the apps do that.
>
> Ciao, Marcus

Many thanks, that is indeed what happens.

And the best part: Dragon can actually type into editboxes on a  
concurrently running app!

None of the voice control stuff works, even internally, so I may get to  
looking into that mechanism later to see if it can be made to work. (eg  
"click file" should bring down the file menu) Indeed this seems to upset  
the dictation function and leaves it in an inconclusive state . Playing  
back some text seems to clear it tho'.

fixme:menu:GetSystemMenu not supported on other process window 0x1401f2
fixme:imm:ImmGetDefaultIMEWnd (0x1401f2 - 0x501f0 0x784c89d8 ): semi-stub
fixme:imm:ImmGetDefaultIMEWnd (0x1401f2 - 0x501f0 0x784c89d8 ): semi-stub

This does not look too far from working either.

Now the big one here is to get this output sent to Linux programs. I have  
been considering different routes to this end.

1/ Using winedebug  or spy output piped through grep then somehow  
injecting it into various X programs.

2/ Patching something into wine or better hooking into and existing  
mechanism  that could send the output to the X window with the input focus.

3/ Using wininet to open a link to a bespoke client on 127.0.0.1 that  
could redirect the output in X.

As you can see are barely thought out ideas just to map possible ways to  
explore.

Any comments on the merit of any of these approaches?

TIA

[Rob D]

At 01:54 PM 11/1/2005, Marcus Meissner wrote:

<snip>
> Running two "wine foo.exe" will act as if on the same machine, including
> interchange of windows messages if the apps do that.
>
> Ciao, Marcus

So I could create 2 wine apps that simply duplicate the window creation and 
message handling , and have them use FindWindow and the like to enable 
using SendMessage and such to synchronize the windows?

If so, that would MUCH simpler than the method I had started formulating.

[Rob D]

I was going to wait til tomorrow to test this, but couldnt wait.
This works perfectly for my app and couldnt have came at a better time.

I just created a simple Win32 dispatcher program for each screen and sent 
the window creation messages to the HWNDs from FindWindow instead of the 
local app and it creates the dialogs on any screen I want. Joy Joy!!!!!

It worked out perfectly since the threads that create windows have to send 
messages to the main loop for it to create them so that the dialogs dont 
from close when the thread exits anyway.

It is refreshing that after I went through all the battles of getting 
multihead display, gcc, and wine running on Solaris that FINALLY something 
would work so simply.

Thanks again to the whole Wine crew that made this possible!!!

At 04:26 PM 11/1/2005, Rob D wrote:
> At 01:54 PM 11/1/2005, Marcus Meissner wrote:
>
> <snip>
> > Running two "wine foo.exe" will act as if on the same machine, including
> > interchange of windows messages if the apps do that.
> >
> > Ciao, Marcus
>
> So I could create 2 wine apps that simply duplicate the window creation 
> and message handling , and have them use FindWindow and the like to enable 
> using SendMessage and such to synchronize the windows?
>
> If so, that would MUCH simpler than the method I had started formulating.

[Kuba Ober]

> I dont know much about the message queue works on Wine but wondered if
> there was means of running two progams in the same context on wine in such
> a way that they use the same message queue and can therefore potencially
> interact.
>
> As I understand it, running two instance of command line wine is more
> analogous to having two different computers running each app under windows.

Wouldn't those share the same wineserver, and thus be able to message to each 
other etc.?

Kuba