Dragon v7 pref on wine 0.9

Hi,

I have managed to get this app working on 0.9 with just four dlls in  
winecfg.

Two I believe to br trivial problems due to lack of version info in the  
buildin dlls.

The two giving real, ugly issues are ole32 and rpcrt4. Symptoms are  
similar.

I would like to attack ole32 first since the rest of the ole stuff works  
and oleaut32 seems to have work very nicely now compared to 20050524,  
great news there.

Things go well at first then I get the following output:

trace:loaddll:load_builtin_dll Loaded module  
L"c:\windows\system\oleacc.dll" : builtin
fixme:oleacc:AccessibleObjectFromWindow 0x10070 0  
{618736e0-3c3d-11cf-810c-00aa00389b71} 0x7876e504
trace:loaddll:load_native_dll  Loaded module L"C:\Program  
Files\ScanSoft\NaturallySpeaking\Program\chartp.dll" : native
trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\Program  
Files\ScanSoft\NaturallySpeaking\Program\DgnMyCmds_enu.dll" : native
trace:loaddll:load_native_dll  Loaded module L"C:\Program  
Files\ScanSoft\NaturallySpeaking\Program\DgnMyCmds_enu.dll" : native
err:ole:RPC_StartRemoting Couldn't register endpoint  
L"\pipe\OLE_000000160000002a"
trace:loaddll:load_native_dll  Loaded module  
L"C:\windows\speech\vcmshl.dll" : native
trace:loaddll:load_native_dll  Loaded module  
L"C:\windows\system\rpcltc1.dll" : native
err:ole:ClientIdentity_QueryMultipleInterfaces  
IRemUnknown_RemQueryInterface failed with error 0x800706ba
err:ole:ClientIdentity_QueryMultipleInterfaces  
IRemUnknown_RemQueryInterface failed with error 0x800706ba
err:x11drv:X11DRV_CreateWindow invalid window height 571100824
err:x11drv:X11DRV_CreateWindow invalid window width -1592141001
err:ntdll:RtlpWaitForCriticalSection section 0x7befd264 "loader.c:  
loader_section" wait timed out in thread 0019, blocked by 002d, retrying  
(60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7befd264 "loader.c:  
loader_section" wait timed out in thread 002b, blocked by 002d, retrying  
(60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7befd264 "loader.c:  
loader_section" wait timed out in thread 0028, blocked by 002d, retrying  
(60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7befd264 "loader.c:  
loader_section" wait timed out in thread 0027, blocked by 002d, retrying  
(60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7befd264 "loader.c:  
loader_section" wait timed out in thread 0024, blocked by 002d, retrying  
(60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7befd264 "loader.c:  
loader_section" wait timed out in thread 002c, blocked by 002d, retrying  
(60 sec)
^X
[1]+  Stopped                 WINEDEBUG="+loaddll" wine natspeak

The app. get part way through starting but the main window remains part  
drawn and the app locks up. I need to ctnl-Z the CLI to break in.

This leaves two processes running. wineserver -k takes out the server but  
leaves a zombie wine-preloader that I have to powerdown to kill!

Can anyone suggest how to pin this error down?

TIA .

[Mike McCormack]

[e-mail] wrote:
> This leaves two processes running. wineserver -k takes out the server 
> but  leaves a zombie wine-preloader that I have to powerdown to kill!
>
> Can anyone suggest how to pin this error down?

Yes, I already told you that it's a kernel bug.  If you use the latest 
Linux kernel 2.6.14 (unpatched) it won't happen.  It's been fixed for me 
since 2.6.7.

Mike

On Sun, 06 Nov 2005 01:38:37 +0100, Mike McCormack   
wrote:
> [e-mail] wrote:
> > This leaves two processes running. wineserver -k takes out the server  
> > but  leaves a zombie wine-preloader that I have to powerdown to kill!
> >  Can anyone suggest how to pin this error down?
>
> Yes, I already told you that it's a kernel bug.  If you use the latest  
> Linux kernel 2.6.14 (unpatched) it won't happen.  It's been fixed for me  
> since 2.6.7.
>
> Mike

Indeed you did , but I didnot think it applies in this case since I have  
been using 2.6.9 since sept 2004 until early 2005 when I moved to 2.6.11.

It is a patched kernel so that may explain it.

Thanks again for the reply.

[Robert Shearman]

[e-mail] wrote:
> Hi,
>
> I have managed to get this app working on 0.9 with just four dlls in  
> winecfg.
>
> Two I believe to br trivial problems due to lack of version info in 
> the  buildin dlls.
>
> The two giving real, ugly issues are ole32 and rpcrt4. Symptoms are  
> similar.
>
> I would like to attack ole32 first since the rest of the ole stuff 
> works  and oleaut32 seems to have work very nicely now compared to 
> 20050524,  great news there.
>
> Things go well at first then I get the following output:
>
> trace:loaddll:load_builtin_dll Loaded module  
> L"c:\windows\system\oleacc.dll" : builtin
> fixme:oleacc:AccessibleObjectFromWindow 0x10070 0  
> {618736e0-3c3d-11cf-810c-00aa00389b71} 0x7876e504
> trace:loaddll:load_native_dll  Loaded module L"C:\Program  
> Files\ScanSoft\NaturallySpeaking\Program\chartp.dll" : native
> trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\Program  
> Files\ScanSoft\NaturallySpeaking\Program\DgnMyCmds_enu.dll" : native
> trace:loaddll:load_native_dll  Loaded module L"C:\Program  
> Files\ScanSoft\NaturallySpeaking\Program\DgnMyCmds_enu.dll" : native
> err:ole:RPC_StartRemoting Couldn't register endpoint  
> L"\pipe\OLE_000000160000002a"
> ...
>
> The app. get part way through starting but the main window remains 
> part  drawn and the app locks up. I need to ctnl-Z the CLI to break in.

This indicates to me that you are using the native rpcrt4 from DCOM95, 
which doesn't support the named pipe transport and so is incompatible.

Lesson to be learned: when you start mixing builtin and native DLLs that 
depend on each other strange things can happen.

On Mon, 07 Nov 2005 00:19:08 +0100, Robert Shearman   
wrote:
> [e-mail] wrote:
> > Hi,
> >
> > I have managed to get this app working on 0.9 with just four dlls in   
> > winecfg.
> >
> > Two I believe to br trivial problems due to lack of version info in  
> > the  buildin dlls.
> >
> > The two giving real, ugly issues are ole32 and rpcrt4. Symptoms are   
> > similar.
> >
> > I would like to attack ole32 first since the rest of the ole stuff  
> > works  and oleaut32 seems to have work very nicely now compared to  
> > 20050524,  great news there.
> >
> > Things go well at first then I get the following output:
> >
> > trace:loaddll:load_builtin_dll Loaded module   
> > L"c:\windows\system\oleacc.dll" : builtin
> > fixme:oleacc:AccessibleObjectFromWindow 0x10070 0   
> > {618736e0-3c3d-11cf-810c-00aa00389b71} 0x7876e504
> > trace:loaddll:load_native_dll  Loaded module L"C:\Program   
> > Files\ScanSoft\NaturallySpeaking\Program\chartp.dll" : native
> > trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\Program   
> > Files\ScanSoft\NaturallySpeaking\Program\DgnMyCmds_enu.dll" : native
> > trace:loaddll:load_native_dll  Loaded module L"C:\Program   
> > Files\ScanSoft\NaturallySpeaking\Program\DgnMyCmds_enu.dll" : native
> > err:ole:RPC_StartRemoting Couldn't register endpoint   
> > L"\pipe\OLE_000000160000002a"
> > ...
> >
> > The app. get part way through starting but the main window remains  
> > part  drawn and the app locks up. I need to ctnl-Z the CLI to break in.
>
> This indicates to me that you are using the native rpcrt4 from DCOM95,  
> which doesn't support the named pipe transport and so is incompatible.
>
> Lesson to be learned: when you start mixing builtin and native DLLs that  
> depend on each other strange things can happen.

Thanks for the reply but I'm afraid I dont follow.

Maybe I was not explicit enough.

When I use native rpcrt4 it _works_ , it is when I try to go fully  
build-in that I get the problems.

I understand what you are saying about mixing built-in and native and it  
would not seem too surprising if this gave issues.

bash-3.00#find /home/wino/.wine -iname rpcrt4* -exec ls -l {} ;
-rw-r--r--  1 wino users 0 Oct 28 23:35  
/home/wino/.wine/c/windows/system/dcom98/oldole/rpcrt4.dll
-rw-r--r--  1 wino users 320784 Jun 12  1998  
/home/wino/.wine/c/windows/system/rpcrt4.dll
-rw-r--r--  1 wino users 320784 Jun 12  1998  
/home/wino/.wine/c/windows/temp/IXP000.TMP/rpcrt4.dll

I did install DCOM98 , is there anything above that makes you still think  
this is a dcom95 version of rpcrt4.dll?

TIA

[Robert Shearman]

[e-mail] wrote:
> On Mon, 07 Nov 2005 00:19:08 +0100, Robert Shearman 
>   wrote:
> > [e-mail] wrote:
> > > Hi,
> > >
> > > I have managed to get this app working on 0.9 with just four dlls 
> > > in   winecfg.
> > >
> > > Two I believe to br trivial problems due to lack of version info in  
> > > the  buildin dlls.
> > >
> > > The two giving real, ugly issues are ole32 and rpcrt4. Symptoms 
> > > are   similar.
> > >
> > > I would like to attack ole32 first since the rest of the ole stuff  
> > > works  and oleaut32 seems to have work very nicely now compared to  
> > > 20050524,  great news there.
> > >
> > > Things go well at first then I get the following output:
> > >
> > > trace:loaddll:load_builtin_dll Loaded module   
> > > L"c:\windows\system\oleacc.dll" : builtin
> > > fixme:oleacc:AccessibleObjectFromWindow 0x10070 0   
> > > {618736e0-3c3d-11cf-810c-00aa00389b71} 0x7876e504
> > > trace:loaddll:load_native_dll  Loaded module L"C:\Program   
> > > Files\ScanSoft\NaturallySpeaking\Program\chartp.dll" : native
> > > trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\Program   
> > > Files\ScanSoft\NaturallySpeaking\Program\DgnMyCmds_enu.dll" : 
> > > native
> > > trace:loaddll:load_native_dll  Loaded module L"C:\Program   
> > > Files\ScanSoft\NaturallySpeaking\Program\DgnMyCmds_enu.dll" : 
> > > native
> > > err:ole:RPC_StartRemoting Couldn't register endpoint   
> > > L"\pipe\OLE_000000160000002a"
> > > ...
> > >
> > > The app. get part way through starting but the main window remains  
> > > part  drawn and the app locks up. I need to ctnl-Z the CLI to break in.
> >
> > This indicates to me that you are using the native rpcrt4 from 
> > DCOM95,  which doesn't support the named pipe transport and so is 
> > incompatible.
> >
> > Lesson to be learned: when you start mixing builtin and native DLLs 
> > that  depend on each other strange things can happen.
>
> Thanks for the reply but I'm afraid I dont follow.
>
> Maybe I was not explicit enough.
>
> When I use native rpcrt4 it _works_ , it is when I try to go fully  
> build-in that I get the problems.
>
> I understand what you are saying about mixing built-in and native and 
> it  would not seem too surprising if this gave issues.
>
> bash-3.00#find /home/wino/.wine -iname rpcrt4* -exec ls -l {} ;
> -rw-r--r--  1 wino users 0 Oct 28 23:35  
> /home/wino/.wine/c/windows/system/dcom98/oldole/rpcrt4.dll
> -rw-r--r--  1 wino users 320784 Jun 12  1998  
> /home/wino/.wine/c/windows/system/rpcrt4.dll
> -rw-r--r--  1 wino users 320784 Jun 12  1998  
> /home/wino/.wine/c/windows/temp/IXP000.TMP/rpcrt4.dll
>
> I did install DCOM98 , is there anything above that makes you still 
> think  this is a dcom95 version of rpcrt4.dll?

Here is a dependency tree for the status in RPC_StartRemoting:
RPC_StartRemoting -> RpcServerUseProtseqEpW
RpcServerUseProtseqEpW -> RpcServerUseProtseqEpExW
RpcServerUseProtseqEpExW -> RPCRT4_use_protseq
RPCRT4_use_protseq returns RPC_S_OK.

Analysing all of the above functions shows that the *only* status that 
will be returned by builtin rpcrt4 is RPC_S_OK, therefore builtin rpcrt4 
is not being used. (The fact that it doesn't return anything but 
RPC_S_OK is a bug though. )

On Mon, 07 Nov 2005 02:56:18 +0100, Robert Shearman   
wrote:
> I did install DCOM98 , is there anything above that makes you still  
> think  this is a dcom95 version of rpcrt4.dll?
>   Here is a dependency tree for the status in RPC_StartRemoting:
> RPC_StartRemoting -> RpcServerUseProtseqEpW
> RpcServerUseProtseqEpW -> RpcServerUseProtseqEpExW
> RpcServerUseProtseqEpExW -> RPCRT4_use_protseq
> RPCRT4_use_protseq returns RPC_S_OK.
>  Analysing all of the above functions shows that the *only* status that  
> will be returned by builtin rpcrt4 is RPC_S_OK, therefore builtin rpcrt4  
> is not being used. (The fact that it doesn't return anything but  
> RPC_S_OK is a bug though. )

Sorry, you are of course right. It was late and I had tried so many  
combinations I forgot what I had written in the original post.

I was encouraged by the fact that a lot of issues in oleaut32 had been  
fixed and wanted to push on with testing ole32 which is still problematic.

I had not realised that rpcrt4 was part of ole.

Is it still too early to expect much from wine ole and just add all ole  
related dlls to winecfg as native only?

Thanks for looking at this.

[Robert Shearman]

[e-mail] wrote:
> Is it still too early to expect much from wine ole and just add all 
> ole  related dlls to winecfg as native only?

No. Please report any bugs with the builtin ones and I'll see what I can do.

On Tue, 08 Nov 2005 01:06:50 +0100, Robert Shearman   
wrote:
> [e-mail] wrote:
> > Is it still too early to expect much from wine ole and just add all  
> > ole  related dlls to winecfg as native only?
>
> No. Please report any bugs with the builtin ones and I'll see what I can  
> do.

OK , I have oleaut32, ole32, and rpcrt4 explicitly as built-in and msvcrt  
and riched20 as native.

The attached log is  WINEDEBUG="+loaddll" wine natspeak &>/tmp/loaddll.log

The program starts, presents a dlg , then goes on to load some user voice  
profile data. At this point it momentarily shows an error dlg that seems  
to have COM in the msg before it shutsdown to the command prompt.

At least this behaviour is fairly orderly.

Can you advise what other traces you need to look at?

BEst regards.

[Robert Shearman]

[e-mail] wrote:
> On Tue, 08 Nov 2005 01:06:50 +0100, Robert Shearman 
>   wrote:
> > [e-mail] wrote:
> > > Is it still too early to expect much from wine ole and just add all  
> > > ole  related dlls to winecfg as native only?
> >
> > No. Please report any bugs with the builtin ones and I'll see what I 
> > can  do.
>
> OK , I have oleaut32, ole32, and rpcrt4 explicitly as built-in and 
> msvcrt  and riched20 as native.
>
> The attached log is  WINEDEBUG="+loaddll" wine natspeak 
> &>/tmp/loaddll.log
>
> The program starts, presents a dlg , then goes on to load some user 
> voice  profile data. At this point it momentarily shows an error dlg 
> that seems  to have COM in the msg before it shutsdown to the command 
> prompt.
>
> At least this behaviour is fairly orderly.
>
> Can you advise what other traces you need to look at?

The traces have a couple of error messages caused by missing registry 
entries. These may or may not be expected. I would maybe suggest a 
+reg,+snoop log using native dlls and see if the calls with the CLSIDs 
mentioned should indeed fail. If they do, then there is something more 
subtle going on and a +ole,+seh,+tid,+olerelay may reveal what it is.

Dragon v7 pref on wine 0.9 - reg/snoop fails

On Tue, 08 Nov 2005 18:22:22 +0100, Robert Shearman   
wrote:
> [e-mail] wrote:
> > On Tue, 08 Nov 2005 01:06:50 +0100, Robert Shearman  
> >   wrote:
> > > [e-mail] wrote:
> > > > Is it still too early to expect much from wine ole and just add all   
> > > > ole  related dlls to winecfg as native only?
> > >
> > > No. Please report any bugs with the builtin ones and I'll see what I  
> > > can  do.
> >
> > OK , I have oleaut32, ole32, and rpcrt4 explicitly as built-in and  
> > msvcrt  and riched20 as native.
> >
> > The attached log is  WINEDEBUG="+loaddll" wine natspeak  
> > &>/tmp/loaddll.log
> >
> > The program starts, presents a dlg , then goes on to load some user  
> > voice  profile data. At this point it momentarily shows an error dlg  
> > that seems  to have COM in the msg before it shutsdown to the command  
> > prompt.
> >
> > At least this behaviour is fairly orderly.
> >
> > Can you advise what other traces you need to look at?
>
> The traces have a couple of error messages caused by missing registry  
> entries. These may or may not be expected. I would maybe suggest a  
> +reg,+snoop log using native dlls and see if the calls with the CLSIDs  
> mentioned should indeed fail. If they do, then there is something more  
> subtle going on and a +ole,+seh,+tid,+olerelay may reveal what it is.

Sorry I've been slow replying , I've been pushing to get this on 0.9.1,  
with some success.

Using ie5.5sp2 rather than ie6 I have managed to get Dragon v7 prefered to  
work on wine-0.9.1 + DCOM98 with a minimum of natives.

In short : sidenet for config and DCOM98
wine install of IE5.5
run the installer (installsheild based)

winecfg for new app:
invert sidenet's *n,b to *b,n
add msvcrt,riched20, riched32, ole32, oleaut32, rpcrt4 as native.
copy in a real comdlg32.dll

run wine natspeak , audio setup and training . All basic functions work  
well.

Now I followed your suggestion to run a +reg,+snoop and I got an error and  
an orderly shutdown.

The program logs what happened itself , see attached file.

Suggestions pls.