Dragon v7 pref on wine 0.9

[Robert Shearman]

wino at piments.com wrote:

> On Mon, 07 Nov 2005 00:19:08 +0100, Robert Shearman 
> <rob at codeweavers.com>  wrote:
>
>> wino at piments.com 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. )

-- 
Rob Shearman