Dragon v7 pref on wine 0.9
Robert Shearman
rob at codeweavers.com
Sun Nov 6 19:56:18 CST 2005
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
More information about the wine-devel
mailing list