September 2005 - Wine-Devel

Re: Installers freezing - ole, games

by Ivan Gyurdiev

Hi, I still can't install GTA - in case this is useful, I've attached the portion of a trace (+ole +oleaut +seh +tid), which includes only the messages after I press Next on the last installer screen (which is where the installer freezes). This is today's CVS..... maybe Olver can compare aganst his copy... 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 490 000b:trace:ole:ITypeInfo_fnAddRef (0x7f3e0d58)->ref is 55 000b:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3e0d58) index 0 000b:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3e0d58) index 1 000b:trace:ole:ITypeInfo_fnGetDocumentation (0x7f3e0d58) memid 40 Name(0x7fc95148) DocString((nil)) HelpContext((nil)) HelpFile((nil)) 000b:trace:ole:ITypeInfo_fnGetDocumentation (0x7f3e0d58) memid -1 Name(0x7fc95144) DocString((nil)) HelpContext((nil)) HelpFile((nil)) 000b:trace:ole:ITypeInfo_fnGetNames (0x7f3e0d58) memid=0x00000028 Maxname=10 000b:trace:ole:serialize_param (tdesc.vt 3) 000b:trace:ole:ClientRpcChannelBuffer_GetBuffer (0x7f47ce88)->(0x7fc950c4,{94f4a332-a2ae-11d3-8378-00c04f59fbe9}) 000b:trace:ole:ClientRpcChannelBuffer_GetBuffer -- 0 000b:trace:ole:RpcChannelBuffer_SendReceive (0x7fc950c4) iMethod=21 000b:trace:ole:apartment_addref a0000000d: before = 1 000b:trace:ole:stub_manager_int_addref before 1 000b:trace:ole:get_stub_manager_from_ipid found 0x7f47cc30 for ipid {00000004-000d-000a-c687-000f3dada1bc} 000b:trace:ole:TMStubImpl_AddRef (0x7f47d420)->(ref before=1) 000b:trace:ole:stub_manager_int_release after 1 000b:trace:ole:RpcChannelBuffer_SendReceive Calling apartment thread 0x0000000d... 000b:trace:ole:apartment_release a0000000d: after = 1 000b:trace:ole:CoWaitForMultipleHandles (0x00000000, 0xffffffff, 1, 0x7ff58b74, 0x7fc95048) 000b:trace:ole:CoWaitForMultipleHandles waiting for rpc completion or window message 000d:trace:ole:TMStubImpl_Invoke ... 000d:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 491 000d:trace:ole:ITypeInfo_fnAddRef (0x7f3e0d58)->ref is 56 000d:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3e0d58) index 0 000d:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3e0d58) index 1 000d:trace:ole:ITypeInfo_fnGetDocumentation (0x7f3e0d58) memid 40 Name(0xe806848) DocString((nil)) HelpContext((nil)) HelpFile((nil)) 000d:trace:ole:ITypeInfo_fnGetDocumentation (0x7f3e0d58) memid -1 Name(0xe806844) DocString((nil)) HelpContext((nil)) HelpFile((nil)) 000d:trace:ole:ITypeInfo_fnGetNames (0x7f3e0d58) memid=0x00000028 Maxname=10 000d:trace:ole:deserialize_param vt 3 at 0x7ff69eec 000d:trace:ole:_invoke Calling 0x3d41345e(7ebe0208,00080032,) 000d:trace:ole:_invoke returns 00000000 000d:trace:ole:serialize_param (tdesc.vt 3) 000d:trace:ole:ITypeInfo_fnRelease (0x7f3e0d58)->(55) 000d:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(491) 000d:trace:ole:TMStubImpl_Invoke returning 000d:trace:ole:TMStubImpl_Release (0x7f47d420)->(ref before=2) 000b:trace:ole:CoWaitForMultipleHandles waiting for rpc completion or window message 000b:trace:ole:CoWaitForMultipleHandles -- 0x00000000 000b:trace:ole:RpcChannelBuffer_SendReceive RPC call status: 0x0 000b:trace:ole:RpcChannelBuffer_SendReceive -- 0x00000000 000b:trace:ole:ITypeInfo_fnRelease (0x7f3e0d58)->(54) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(490) 000b:trace:ole:ITypeInfo_fnInvoke (0x7f3ce0b0)(0x7f4fa378,id=25,flags=0x00000003,0x7fca11a8,0x7fca1208,0x7fca1128,0x7fca116c) partial stub! 000b:trace:ole:dump_DispParms args=2 named args=0 000b:trace:ole:dump_Variant 0x7e9ae090->{VT_I4|VT_BYREF,0x7e9ae0bc} 000b:trace:ole:dump_Variant 0x7e9ae0a0->{VT_BSTR|VT_BYREF,0x7e9ae108} 000b:trace:ole:ITypeInfo2_fnGetFuncIndexOfMemId (0x7f3ce0b0) memid 0x00000019 invKind 0x0003 -> SUCCESS 000b:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3ce0b0) index 0 000b:trace:ole:ITypeInfo_fnInvoke invoking: memid is 00000019 Param 0: tdesc.vartype 8 (VT_BSTR) u.parmadesc.flags 1 u.parmadesc.lpex (nil) Param 1: tdesc.vartype 11 (VT_BOOL) u.parmadesc.flags 1 u.parmadesc.lpex (nil) Param 2: tdesc.vartype 26 (ptr to VT_BSTR) u.parmadesc.flags a u.parmadesc.lpex (nil) funckind: 1 (pure virtual) invkind: 2 (property get) callconv: 4 (stdcall) oVft: 56 cParamsOpt: 0 wFlags: 0 elemdescFunc (return value type): tdesc.vartype 25 (VT_HRESULT) u.parmadesc.flags 0 u.parmadesc.lpex (nil) 000b:fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff 000b:trace:ole:_invoke Calling 0x37a93b3c(7f4fa378,7e8c1b3c,0000ffff,7e8b7d48,) 000b:trace:ole:_invoke returns 00000000 000b:trace:ole:ITypeInfo_fnInvoke varresult: 0x7fca106c->{VT_BSTR|VT_BYREF,0x7e8b7d48} 000b:trace:ole:ITypeInfo_fnReleaseFuncDesc (0x7f3ce0b0)->(0x7f3ce1e0) 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 490 000b:trace:ole:ITypeInfo_fnAddRef (0x7f3ce0b0)->ref is 242 000b:trace:ole:ITypeInfo_fnGetIDsOfNames (0x7f3ce0b0) Name L"Value" cNames 1 000b:trace:ole:ITypeInfo_fnGetContainingTypeLib returning pIndex=105 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 491 000b:trace:ole:ITypeInfo_fnGetContainingTypeLib returning ppTLib=0x7ff8fc40 000b:trace:ole:ITypeLib2_fnGetTypeInfo (0x7ff8fc40)->(index=104) 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 492 000b:trace:ole:ITypeInfo_fnAddRef (0x7f3cdc98)->ref is 2 000b:trace:ole:ITypeLib2_fnGetTypeInfo -- found (0x7f3cdc98) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(492) 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo (0x7f3ce0b0) hreftype 0x28a0 loaded SUCCESS (0x7f3cdc98) 000b:trace:ole:ITypeInfo_fnGetIDsOfNames (0x7f3cdc98) Name L"Value" cNames 1 000b:trace:ole:ITypeInfo_fnGetContainingTypeLib returning pIndex=104 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 492 000b:trace:ole:ITypeInfo_fnGetContainingTypeLib returning ppTLib=0x7ff8fc40 000b:trace:ole:ITypeLib2_fnGetTypeInfo (0x7ff8fc40)->(index=103) 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 493 000b:trace:ole:ITypeInfo_fnAddRef (0x7f3cd400)->ref is 2 000b:trace:ole:ITypeLib2_fnGetTypeInfo -- found (0x7f3cd400) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(493) 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo (0x7f3cdc98) hreftype 0x283c loaded SUCCESS (0x7f3cd400) 000b:trace:ole:ITypeInfo_fnGetIDsOfNames (0x7f3cd400) Name L"Value" cNames 1 000b:trace:ole:ITypeInfo_fnRelease (0x7f3cd400)->(1) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(492) 000b:trace:ole:ITypeInfo_fnRelease (0x7f3cdc98)->(1) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(491) 000b:trace:ole:ITypeInfo_fnInvoke (0x7f3ce0b0)(0x7f4fa378,id=0,flags=0x00000004,0x7fca11f8,(nil),0x7fca1144,0x7fca1188) partial stub! 000b:trace:ole:dump_DispParms args=2 named args=1 000b:trace:ole:dump_Variant 0x7e9ae0b8->{VT_BSTR|VT_BYREF,0x7e9ae100} 000b:trace:ole:dump_Variant 0x7e9ae0c8->{VT_BSTR|VT_BYREF,0x7e9af0d0} 000b:trace:ole:ITypeInfo2_fnGetFuncIndexOfMemId (0x7f3ce0b0) memid 0x00000000 invKind 0x0004 -> FAILED 000b:trace:ole:ITypeInfo2_fnGetVarIndexOfMemId (0x7f3ce0b0) memid 0x00000000 -> FAILED 000b:trace:ole:ITypeInfo2_fnGetTypeKind (0x7f3ce0b0) type 0x4 000b:trace:ole:ITypeInfo_fnGetRefTypeOfImplType (0x7f3ce0b0) index 0 000b:trace:ole:dump_TypeInfo 0x7f3ce0b0 ref=242 000b:trace:ole:dump_TypeInfo attr:{5331f72d-17f1-4d16-a17a-f190461343bf} 000b:trace:ole:dump_TypeInfo kind:TKIND_DISPATCH 000b:trace:ole:dump_TypeInfo fct:4 var:0 impl:1 000b:trace:ole:dump_TypeInfo parent tlb:0x7ff8fc40 index in TLB:105 000b:trace:ole:dump_TypeInfo L"ISetupTextSubstitution3" (null) 000b:trace:ole:ITypeInfo_fnGetRefTypeOfImplType -- 0x000028a0 000b:trace:ole:ITypeInfo_fnGetContainingTypeLib returning pIndex=105 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 491 000b:trace:ole:ITypeInfo_fnGetContainingTypeLib returning ppTLib=0x7ff8fc40 000b:trace:ole:ITypeLib2_fnGetTypeInfo (0x7ff8fc40)->(index=104) 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 492 000b:trace:ole:ITypeInfo_fnAddRef (0x7f3cdc98)->ref is 2 000b:trace:ole:ITypeLib2_fnGetTypeInfo -- found (0x7f3cdc98) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(492) 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo (0x7f3ce0b0) hreftype 0x28a0 loaded SUCCESS (0x7f3cdc98) 000b:trace:ole:ITypeInfo_fnInvoke (0x7f3cdc98)(0x7f4fa378,id=0,flags=0x00000004,0x7fca11f8,(nil),0x7fca1144,0x7fca1188) partial stub! 000b:trace:ole:dump_DispParms args=2 named args=1 000b:trace:ole:dump_Variant 0x7e9ae0b8->{VT_BSTR|VT_BYREF,0x7e9ae100} 000b:trace:ole:dump_Variant 0x7e9ae0c8->{VT_BSTR|VT_BYREF,0x7e9af0d0} 000b:trace:ole:ITypeInfo2_fnGetFuncIndexOfMemId (0x7f3cdc98) memid 0x00000000 invKind 0x0004 -> FAILED 000b:trace:ole:ITypeInfo2_fnGetVarIndexOfMemId (0x7f3cdc98) memid 0x00000000 -> FAILED 000b:trace:ole:ITypeInfo2_fnGetTypeKind (0x7f3cdc98) type 0x4 000b:trace:ole:ITypeInfo_fnGetRefTypeOfImplType (0x7f3cdc98) index 0 000b:trace:ole:dump_TypeInfo 0x7f3cdc98 ref=2 000b:trace:ole:dump_TypeInfo attr:{1169a235-14d9-4488-8b56-58ece9c57002} 000b:trace:ole:dump_TypeInfo kind:TKIND_DISPATCH 000b:trace:ole:dump_TypeInfo fct:2 var:0 impl:1 000b:trace:ole:dump_TypeInfo parent tlb:0x7ff8fc40 index in TLB:104 000b:trace:ole:dump_TypeInfo L"ISetupTextSubstitution2" (null) 000b:trace:ole:ITypeInfo_fnGetRefTypeOfImplType -- 0x0000283c 000b:trace:ole:ITypeInfo_fnGetContainingTypeLib returning pIndex=104 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 492 000b:trace:ole:ITypeInfo_fnGetContainingTypeLib returning ppTLib=0x7ff8fc40 000b:trace:ole:ITypeLib2_fnGetTypeInfo (0x7ff8fc40)->(index=103) 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 493 000b:trace:ole:ITypeInfo_fnAddRef (0x7f3cd400)->ref is 2 000b:trace:ole:ITypeLib2_fnGetTypeInfo -- found (0x7f3cd400) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(493) 000b:trace:ole:ITypeInfo_fnGetRefTypeInfo (0x7f3cdc98) hreftype 0x283c loaded SUCCESS (0x7f3cd400) 000b:trace:ole:ITypeInfo_fnInvoke (0x7f3cd400)(0x7f4fa378,id=0,flags=0x00000004,0x7fca11f8,(nil),0x7fca1144,0x7fca1188) partial stub! 000b:trace:ole:dump_DispParms args=2 named args=1 000b:trace:ole:dump_Variant 0x7e9ae0b8->{VT_BSTR|VT_BYREF,0x7e9ae100} 000b:trace:ole:dump_Variant 0x7e9ae0c8->{VT_BSTR|VT_BYREF,0x7e9af0d0} 000b:trace:ole:ITypeInfo2_fnGetFuncIndexOfMemId (0x7f3cd400) memid 0x00000000 invKind 0x0004 -> SUCCESS 000b:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3cd400) index 1 000b:trace:ole:ITypeInfo_fnInvoke invoking: memid is 00000000 Param 0: tdesc.vartype 8 (VT_BSTR) u.parmadesc.flags 1 u.parmadesc.lpex (nil) Param 1: tdesc.vartype 8 (VT_BSTR) u.parmadesc.flags 1 u.parmadesc.lpex (nil) funckind: 1 (pure virtual) invkind: 4 (property put) callconv: 4 (stdcall) oVft: 32 cParamsOpt: 0 wFlags: 0 elemdescFunc (return value type): tdesc.vartype 25 (VT_HRESULT) u.parmadesc.flags 0 u.parmadesc.lpex (nil) 000b:trace:ole:_invoke Calling 0x37a93f6d(7f4fa378,7e8c06b4,7e8c060c,) 000b:trace:ole:_invoke returns 00000000 000b:trace:ole:ITypeInfo_fnReleaseFuncDesc (0x7f3cd400)->(0x7f3cd650) 000b:trace:ole:ITypeInfo_fnRelease (0x7f3cd400)->(1) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(492) 000b:trace:ole:ITypeInfo_fnRelease (0x7f3cdc98)->(1) 000b:trace:ole:ITypeLib2_fnRelease (0x7ff8fc40)->(491) 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 491 000b:trace:ole:ITypeInfo_fnAddRef (0x7f3ce0b0)->ref is 243 000b:trace:ole:ITypeInfo_fnInvoke (0x7f3ce0b0)(0x7f4fa378,id=25,flags=0x00000003,0x7fca120c,0x7fca126c,0x7fca118c,0x7fca11d0) partial stub! 000b:trace:ole:dump_DispParms args=2 named args=0 000b:trace:ole:dump_Variant 0x7e9ae0a0->{VT_I4|VT_BYREF,0x7e9ae0cc} 000b:trace:ole:dump_Variant 0x7e9ae0b0->{VT_BSTR|VT_BYREF,0x7e9ae118} 000b:trace:ole:ITypeInfo2_fnGetFuncIndexOfMemId (0x7f3ce0b0) memid 0x00000019 invKind 0x0003 -> SUCCESS 000b:trace:ole:ITypeInfo_fnGetFuncDesc (0x7f3ce0b0) index 0 000b:trace:ole:ITypeInfo_fnInvoke invoking: memid is 00000019 Param 0: tdesc.vartype 8 (VT_BSTR) u.parmadesc.flags 1 u.parmadesc.lpex (nil) Param 1: tdesc.vartype 11 (VT_BOOL) u.parmadesc.flags 1 u.parmadesc.lpex (nil) Param 2: tdesc.vartype 26 (ptr to VT_BSTR) u.parmadesc.flags a u.parmadesc.lpex (nil) funckind: 1 (pure virtual) invkind: 2 (property get) callconv: 4 (stdcall) oVft: 56 cParamsOpt: 0 wFlags: 0 elemdescFunc (return value type): tdesc.vartype 25 (VT_HRESULT) u.parmadesc.flags 0 u.parmadesc.lpex (nil) 000b:fixme:ole:_copy_arg Should not use VariantChangeType here. (conversion from 0x4003 -> 0xb) 0000ffff 000b:trace:ole:_invoke Calling 0x37a93b3c(7f4fa378,7ff58b6c,0000ffff,7e8c06b0,) 000b:trace:ole:_invoke returns 00000000 000b:trace:ole:ITypeInfo_fnInvoke varresult: 0x7fca10d0->{VT_BSTR|VT_BYREF,0x7e8c06b0} 000b:trace:ole:ITypeInfo_fnReleaseFuncDesc (0x7f3ce0b0)->(0x7f3ce1e0) 000b:trace:ole:ITypeLib2_fnAddRef (0x7ff8fc40)->ref was 492 000b:trace:ole:ITypeInfo_fnAddRef (0x7f3ce0b0)->ref is 244

Sept. 20, 2005

Re: Burning CDs under Wine?

by Vitaliy Margolen

Monday, September 19, 2005, 6:07:58 PM, Dan Kegel wrote: > What is the current state of support for burning CDs > under Wine? I checked the appdb, but can't find > any recent reports of CD burning programs working. > It seems to have worked at some point in the past: > http://appdb.winehq.org/appview.php?appId=639 > http://www.winehq.org/hypermail/wine-users/2002/09/0164.html > http://www.winehq.org/hypermail/wine-devel/2001/05/0263.html > But some people are having trouble now: > http://www.winehq.org/hypermail/wine-users/2005/05/0100.html > http://www.winehq.org/pipermail/wine-users/2005-July/018475.html > The doc at > http://www.winehq.org/site/docs/wine-user/config-scsi-support > looks pretty old. Maybe it's time for a refresh. There were few changes to wine's aspi and related code. Can you do regression testing to see when your program stopped working? Or did it ever worked at all with Wine? Or is it a problem with your Linux kernel that you can't load ide-scsi emulation driver? Vitaliy.

Sept. 20, 2005

Re: question about the status of the wine printing system

by Dan Kegel

In http://www.winehq.org/hypermail/wine-devel/2005/01/0111.html, Francois Gouget wrote: > If you're trying to print stuff from > Acrobat Reader (now called Adobe Reader), then that's known not to work. What are the problems? How much work is left before printing in Wine is more or less working with most major applications (like, say, Photoshop and Acrobat Reader)? - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Sept. 20, 2005

Burning CDs under Wine?

by Dan Kegel

What is the current state of support for burning CDs under Wine? I checked the appdb, but can't find any recent reports of CD burning programs working. It seems to have worked at some point in the past: http://appdb.winehq.org/appview.php?appId=639 http://www.winehq.org/hypermail/wine-users/2002/09/0164.html http://www.winehq.org/hypermail/wine-devel/2001/05/0263.html But some people are having trouble now: http://www.winehq.org/hypermail/wine-users/2005/05/0100.html http://www.winehq.org/pipermail/wine-users/2005-July/018475.html The doc at http://www.winehq.org/site/docs/wine-user/config-scsi-support looks pretty old. Maybe it's time for a refresh. -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Sept. 20, 2005

Re: resubmit: implement hlink.dll

by Mike McCormack

Aric Stewart wrote: > + if (r == S_OK); I don't think you want to put a semi colon there. > + { > + if (pwzLocation) > + IHlink_SetStringReference(*(IHlink**)ppvObj, HLINKSETF_LOCATION, > + NULL, pwzLocation); > + if (pwzFriendlyName) > + IHlink_SetFriendlyName(*(IHlink**)ppvObj, pwzFriendlyName); > + if (pihlsite) > + IHlink_SetHlinkSite(*(IHlink**)ppvObj, pihlsite, dwSiteData); > + if (pimkTrgt) > + IHlink_SetMonikerReference(*(IHlink**)ppvObj, 0, pimkTrgt, > + pwzLocation); Rather than continually casting ppvObj, why not make a temporary variable of type IHlink? > +static HRESULT WINAPI IHlink_fnGetMonikerReference(IHlink* iface, > + DWORD dwWhichRef, IMoniker **ppimkTarget, LPWSTR *ppwzLocation) > +{ > + IHlinkImpl *This = (IHlinkImpl*)iface; > + > + TRACE("(%p) -> (%li %p %p)\n",This, dwWhichRef, ppimkTarget, ppwzLocation); > + > + if(ppimkTarget) > + { > + if (This->Moniker) > + *ppimkTarget = This->Moniker; > + else if (This->Site) > + IHlinkSite_GetMoniker(This->Site, This->SiteData, > + OLEGETMONIKER_FORCEASSIGN, OLEWHICHMK_CONTAINER, > + (LPVOID)ppimkTarget); > + } > + > + return S_OK; > +} The above function doesn't look right. You don't use dwWhichRef or ppwzLocation, and you unconditionally return S_OK even when *ppimkTarget is uninitialized or IHlinkSite_GetMoniker fails. Mike

Sept. 20, 2005

Wine on NetBSD?

by Bryce Robilliard

I was enquiring as to whether or not Wine is compatible with NetBSD, or if any other port of Wine is compatible with NetBSD. If not are there any plans to make this so? Regards, Bryce Robilliard

Sept. 19, 2005

scared! freedce-win32 in a cvs repository near you

by Luke Kenneth Casson Leighton

right. 48 hours later, i've got a first version of freedce-win32 to try out, which i'm actually a bit frightened of running. just in case it works :) thank goodness for pthreads-win32, otherwise i'd be up small creek. major things todo: in ipnaf.c (actually ipnaf_linux.c or even better ipnaf_win32.c) it's necessary to write an IP-interface-enumeration function. this function presumably will call GetIpAddrTable and go over all the addresses including netmasks and broadcast addresses returning information that the rpc runtime can then "listen" on - one by one. no, freedce doesn't go listening on 0.0.0.0 it binds to all "towers" whatever they're called. because i've commented this code out (stubbed) i am not expecting freedce-win32 to work straight off. once this is working, putting it in place of rpcrt4 should be relatively straightforward (and mostly very very mind numbingly boring) - a matter of "back-converting" and following the lead of dceport.h - microsoft's "wrapper" header file that allows application developers to port DCE/RPC applications to MSRPC. i say "lead" because it's woefully inadequate, representing about 10% of the functions and structs that actually need "converting", because dceport.h contains the "publicly accessible" functions. once _that's_ done, then there will be two remaining tasks: 1) check that pthreads-win32 works under wine (!) and if so, job done, otherwise it's _yet_ another emulation layer to write, but at least the source code of pthreads-win32 represents a damn good starting point 2) mash freedce's typelib output to be compatible with MSRPC binaries. this latter is no small task (but at least it could be considered). the data structures have been _totally_ mashed, by microsoft. gotta run. later. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

Sept. 19, 2005

Re: user: make A->W WM_GETTEXTLENGTH use WM_GETTEXT [try 2]

by Frank Richter

On 09.09.2005 17:09, Alexandre Julliard wrote: > Frank Richter <frank.richter(a)gmail.com> writes: > >> On 09.09.2005 16:27, Alexandre Julliard wrote: >>> Well, I'm not sure doing a SendMessage is the right thing if you are >>> called from inside CallWindowProc, you may have to do a CallWindowProc >> UnmapMsgAtoW() (or so) is also called when interprocess messages are >> translated back... in this case, (afaik... correct me when I'm wrong) a >> CallWindowProc() does not suffice... > > Yes, that's what I mean. When unmapping the result of a SendMessage > you should do a SendMessage, when unmapping the result of a > CallWindowProc you should do a CallWindowProc (I guess, this needs to > be checked under Windows). Interestingly, when CallWindowProcA() is used on an W window, no WM_GETTEXT is sent. (Whether the window proc belongs to the window does not seem to matter.) Though, in that case, the result is not doubled either. -f.r.

Sept. 19, 2005

Re: Empire Earth continued

by Stefan Dösinger

Hello Lionel, Now that I think that the refcount crash is solved and I'm waiting for the patch I've sent to be reviewed and commited, I've looked into the OpenGL crash: I know the following cases *Hardware accellerated, with fglrx: Crash in fglrx[1] *Hardware accellerated, other implementation: Crash in some DDraw DIP function *No hardware accelleration: No crash, Main Menu finally starts, but only with a black screen[2] I've uploaded two logs to my homepage, [1] and [2], if you want to look at them. Well I noticed 2 things: *Empire Earth starts using a new thread to do ddraw things. *Sigh* *There's some problem due to a missing Z Buffer Is the first thing likely to cause problems? You told me so some time ago, but it doesn't look like it in the logs. The Z buffer thing is more suspicious to me, but the code path with leads to the crash seems to be prepared for this. Do you have any suggestions? When I start the game without hw accel, I can take screen shots with the game's screen shot functionality. They show text elements and the mouse pointer. The background and the button decorations are not drawn. See [3]. I can control the menu with the keyboard and start the map editor, which has the in-game graphics. It's basically the same as the menu, text and mouse pointer only, but luckily no further crash :-) Thanks for taking the time, Stefan [1] http://doesi.gmxhome.de/ee.fglrx-crash.bz2 [2] http://doesi.gmxhome.de/ee.mesa.bz2 [3] http://doesi.gmxhome.de/EE000.jpg

Sept. 19, 2005

OLE file close problem in win32s mathcad 5.0

by paul

Since some work is occurring in OLE I will mention this bug. http://bugs.winehq.org/show_bug.cgi?id=3154 When you start mathcad one New blank file is opened. Trying to close any file does not work and my guess some Ole stub return value is preventing it. This application has had this problem of not closing for several years. What other traces do I need to generate? Open file splash.mcd then close it and it does not close. bash-3.00$ WINEDEBUG=+ole wine mcad Loading required GL library /usr/X11R6/lib/libGL.so.1.2 trace:ole:DllMain 0x7b7c0000 0x1 0x1 fixme:ole:OleRegisterServer (Mathcad,0x7bc9f330,0x7bc9f334,0x400000,1): stub! fixme:psdrv:PSDRV_ExtEscape QUERYESCSUPPORT(24) - not supported. fixme:ole:OleRegisterClientDoc (Mathcad document,\Untitled:1,...): stub fixme:ole:OleRegisterServerDoc (1,\Untitled:1): stub fixme:ole:OleRegisterClientDoc (Mathcad document,C:\WINMCAD\handbook\deskref\splash.mcd,...): stub fixme:ole:OleRegisterServerDoc (1,C:\WINMCAD\handbook\deskref\splash.mcd): stub fixme:ole:OleRevokeClientDoc (2): stub fixme:ole:OleRevokeServerDoc (3): stub

Sept. 19, 2005

riched versions

by wino＠piments.com

trying to get recent (winecfg) wine versions to run a program and it shows an error saying riched20.dll version <unspecified> is found and it "requires" 5.2...... I would have thought that the build-in is probably fine , it is just a version check that is failing. Is there a way to con it or is the only way to pull in a versioned native dll? TIA

Sept. 19, 2005

Re: server: Try2: add case-sensitivity comparison flag to find_object & co

by Robert Shearman

Vitaliy Margolen wrote: >Monday, September 19, 2005, 7:47:08 AM, Alexandre Julliard wrote: > > >>Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: >> >> >>>I guess this one got lost. Resend it. >>>Or is there anything wrong with it? >>> >>> > > > >>Well, you didn't change create_named_object, which looks >>suspicious. Also I'd really like to see some regression tests for the >>behavior of the various objects. >> >> >Ah, I see. I new I was missing something. As far as regression testing - most >of the named objects created from kernel32 and they are case insensitive. I >purposely left it case sensitive to keep it same way as it was before. I know of >at least named pipes that fail with current code, if I start mixing case - which >does work on windows. > Something like this should test the behaviour (written in MSVC so will need some cleaning up before adding to a Wine test): WCHAR buffer1[] = L"\\BaseNamedObjects\\Test"; WCHAR buffer2[] = L"\\BaseNamedObjects\\test"; WCHAR buffer3[] = L"\\BaseNamedObjects\\TEst"; HANDLE Event, Mutant, h; NTSTATUS status; OBJECT_ATTRIBUTES attr; attr.Length = sizeof(attr); attr.RootDirectory = NULL; attr.ObjectName = HeapAlloc(GetProcessHeap(), 0, sizeof(UNICODE_STRING)); attr.Attributes = 0; attr.SecurityDescriptor = NULL; attr.SecurityQualityOfService = NULL; attr.ObjectName->Buffer = buffer2; attr.ObjectName->Length = wcslen(buffer2) * sizeof(WCHAR); attr.ObjectName->MaximumLength = (wcslen(buffer2) + 1) * sizeof(WCHAR); status = NtCreateMutant(&Mutant, GENERIC_ALL, &attr, FALSE); attr.ObjectName->Buffer = buffer1; attr.ObjectName->Length = wcslen(buffer1) * sizeof(WCHAR); attr.ObjectName->MaximumLength = (wcslen(buffer1) + 1) * sizeof(WCHAR); status = NtCreateEvent(&Event, GENERIC_ALL, &attr, FALSE, FALSE); attr.Attributes = OBJ_CASE_INSENSITIVE; attr.ObjectName->Buffer = buffer3; attr.ObjectName->Length = wcslen(buffer3) * sizeof(WCHAR); attr.ObjectName->MaximumLength = (wcslen(buffer3) + 1) * sizeof(WCHAR); status = NtOpenMutant(&h, GENERIC_ALL, &attr); ok(status == STATUS_OBJECT_TYPE_MISMATCH, "NtOpenMutant should have failed with STATUS_OBJECT_TYPE_MISMATCH because of case-insensitive search finding an event object\n"); return 0; -- Rob Shearman

Sept. 19, 2005

Re: DDRAW: Fix reference counting

by Stefan Dösinger

Hello, > In that case, it would be really beneficial with a unit test. > Both as documentation and to see what Windows does. Excuse my ignorance, but what exactly is meant with 'unit test'? As far as I've learned, it's a small piece of code which uses this functionality and checks the results. My patch includes such a test: --- /dev/null 2005-09-01 15:22:32.000000000 +0200 +++ dlls/ddraw/tests/refcount.c 2005-09-18 21:57:52.000000000 +0200 <...> + /* Create a Texture. Increases the refcount by 2!!!*/ + memset(&ddsd, 0, sizeof(ddsd)); + ddsd.dwSize = sizeof(ddsd); + ddsd.dwFlags = DDSD_CAPS | DDSD_HEIGHT | DDSD_WIDTH | DDSD_PIXELFORMAT; + ddsd.ddsCaps.dwCaps = DDSCAPS_TEXTURE; <...> + rc = IDirectDraw7_CreateSurface( lpDD, &ddsd, &lpDDS, NULL ); + ok(rc == DD_OK, "CreateSurface for a mipmap surface returned %lx\n", rc); + if(rc == DD_OK) + { + newref = IDirectDraw_AddRef(lpDD) - 1; + IDirectDraw_Release(lpDD); + ok( (newref - oldref) == 2, "DD reference count increased by %d during creation of a mipmap surface\n", newref - oldref); + oldref = newref; + + newref = IDirectDrawSurface_AddRef(lpDDS) - 1; + IDirectDrawSurface_Release(lpDDS); + ok(newref == 1, "Initial surface reference count of a mipmap surface is %d\n", newref); + + /* Release the surface */ + IDirectDrawSurface_Release(lpDDS); + + newref = IDirectDraw_AddRef(lpDD) - 1; + IDirectDraw_Release(lpDD); + ok( (newref - oldref) == -2, "DD reference count decreased by %d during releasing a mipmap surface\n", newref - oldref); + } Is that enought? This test succeeds in Windows 2000 and Windows 95. Stefan

Sept. 19, 2005

Re: server: Try2: add case-sensitivity comparison flag to find_object & co

by Alexandre Julliard

Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > Ah, I see. I new I was missing something. As far as regression testing - most > of the named objects created from kernel32 and they are case insensitive. I > purposely left it case sensitive to keep it same way as it was before. I know of > at least named pipes that fail with current code, if I start mixing case - which > does work on windows. That's why we need regression tests. If things currently fail you can add todo_wine, but we need to know what the exact behavior is supposed to be. -- Alexandre Julliard julliard(a)winehq.org

Sept. 19, 2005

Re: server: Try2: add case-sensitivity comparison flag to find_object & co

by Vitaliy Margolen

Monday, September 19, 2005, 7:47:08 AM, Alexandre Julliard wrote: > Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: >> I guess this one got lost. Resend it. >> Or is there anything wrong with it? > Well, you didn't change create_named_object, which looks > suspicious. Also I'd really like to see some regression tests for the > behavior of the various objects. Ah, I see. I new I was missing something. As far as regression testing - most of the named objects created from kernel32 and they are case insensitive. I purposely left it case sensitive to keep it same way as it was before. I know of at least named pipes that fail with current code, if I start mixing case - which does work on windows. This is a first step to making it right. The next step would be to pass obj_attr attributes to server so it can check for OBJ_CASE_INSENSITIVE. I will run all tests to check if it broke anything. And also add the case_sensitive flag to create_named_object as well. Vitaliy

Sept. 19, 2005

Re: comctl32.dll: Running siap and modules under wine, first steps

by Maximiliano Curia

On Saturday 17 September 2005 20:45, Robert Shearman wrote: > Start the program with WINEDEBUG=+treeview wine program.exe &> > treeview.log and send the treeview log to the list (compressed if it is > over 50kB). It's about 31 Kb, it gets to the line 272 to open the main window and showing the treeview, as shown in the screenshot. The rest is just the program closing. I don't know if this could actually help but, I've noticed, after looking fiercely at the log, that the tree is being set to expand, but the Paint seems to only be calling DrawItem to the root (twice), but looking at the code I can't tell wheter the TREEVIEW_Expand is not setting the siblings to visible or if TREEVIEW_Paint is just failling. -- Saludos, /\/\ /\ >< `/ No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.2/105 - Release Date: 19/09/05

Sept. 19, 2005

Re: server: Try2: add case-sensitivity comparison flag to find_object & co

by Alexandre Julliard

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > I guess this one got lost. Resend it. > Or is there anything wrong with it? Well, you didn't change create_named_object, which looks suspicious. Also I'd really like to see some regression tests for the behavior of the various objects. -- Alexandre Julliard julliard(a)winehq.org

Sept. 19, 2005

Take 2: DDRAW: Fix reference counting

by Stefan Dösinger

Hello, This patch increases the reference count of a DirectDraw object when a Surface is created, like Windows does. It also adds a test which tests this functionality. This time with the !FAILED() -> SUCCEEDED() suggestion from Robert Shearman. I kept adding a secound refcount in case of DDSCAPS_TEXTURE surfaces to achieve more compatiblity with Windows. Stefan

Sept. 19, 2005

Re: msvcrt spec changes

by Dmitry Timoshkov

Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > I couldnt get the necessary info on it from msdn. MinGW should have all the necessary info as well. -- Dmitry.

Sept. 19, 2005

Re: DDRAW: Fix reference counting

by jakov＠vmlinux.org

On Mon, Sep 19, 2005 at 09:27:05AM +0200, Stefan D?singer wrote: > Hi, > > Why do you increase the refcount by 2? Since you add and release them in > > the same functions, it is not really necessary and just adds complexity > > to the code. > Well, Windows does so for some reason, and after what I've seen with Empire > Earth, I suspect that there are some apps out there which depend on things > like this. It's unlikely, but I would not be surprised if that happens. In that case, it would be really beneficial with a unit test. Both as documentation and to see what Windows does. -- regards, Jakob It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News

Sept. 19, 2005

Re: msvcrt spec changes

by Vijay Kiran Kamuju

I couldnt get the necessary info on it from msdn. Ill be sending a new patch for with the change for _getsystemtime On 9/19/05, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > > > added reference to kernel32.GetLocalTime to _getsystime stub function > > (support.microsoft.com/default.aspx?scid=kb;en-us;99456<http://support.microsoft.com/default.aspx?scid=kb;en-us;99456> > ) > > > -@ stub _getsystime #(ptr) > > +@ cdecl _getsystime(ptr) kernel32.GetLocalTime > > You can't just forward _getsystime to GetLocalTime, they accept different > arguments: struct tm * vs. SYSTEMTIME *. Have a look at your MSVC docs. > > -- > Dmitry. > >

Sept. 19, 2005

Re: msvcrt spec changes

by Dmitry Timoshkov

Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > added reference to kernel32.GetLocalTime to _getsystime stub function > (support.microsoft.com/default.aspx?scid=kb;en-us;99456) > -@ stub _getsystime #(ptr) > +@ cdecl _getsystime(ptr) kernel32.GetLocalTime You can't just forward _getsystime to GetLocalTime, they accept different arguments: struct tm * vs. SYSTEMTIME *. Have a look at your MSVC docs. -- Dmitry.

Sept. 19, 2005

Re: Fwd: amblksize definition

by Vijay Kiran Kamuju

please ignore this patch, i'll be sending a more correct patch. On 9/19/05, Vijay Kiran Kamuju <infyquest(a)gmail.com> wrote: > > I will be initializing that variable to 16, in msvcrt's heap.c > In that way it would be in msvcrt's code. > There are some diffreneces between the value returned and the > documentation. > > On 9/19/05, Saulius Krasuckas <saulius2(a)ar.fi.lt > wrote: > > > > * On Mon, 19 Sep 2005, Vijay Kiran Kamuju wrote: > > > > > > amblksize definition in msvcrt. > > > > Wouldn't it be nice to establish a real variable somewhere in the msvcrt > > code? > > > >

Sept. 19, 2005

Re: hhctrl: Correctly draw the navigation pane

by Dmitry Timoshkov

"Robert Shearman" <rob(a)codeweavers.com> wrote: > >@@ -149,7 +144,7 @@ static void HH_RegisterChildWndClass(HHI > > wcex.hInstance = pHHInfo->hInstance; > > wcex.hIcon = LoadIconW(NULL, (LPCWSTR)IDI_APPLICATION); > > wcex.hCursor = LoadCursorW(NULL, (LPCWSTR)IDC_ARROW); > >- wcex.hbrBackground = (HBRUSH)(COLOR_3DFACE); > >+ wcex.hbrBackground = (HBRUSH)(COLOR_MENU); > > > > > > This doesn't seem right. You're not registering a menu-like class. Moreover, when using COLOR_xxx constants in the place of a brush one needs to increase the value by 1 in order to make it work. dlls/msi/dialog.c, dlls/shlwapi/ordinal.c, programs/notepad/main.c have the same problem. -- Dmitry.

Sept. 19, 2005

Re: Fwd: amblksize definition

by Vijay Kiran Kamuju

I will be initializing that variable to 16, in msvcrt's heap.c In that way it would be in msvcrt's code. There are some diffreneces between the value returned and the documentation. On 9/19/05, Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote: > > * On Mon, 19 Sep 2005, Vijay Kiran Kamuju wrote: > > > > amblksize definition in msvcrt. > > Wouldn't it be nice to establish a real variable somewhere in the msvcrt > code? >

Sept. 19, 2005