October 2008 - Wine-Devel - list.winehq.org

Silencing a noisy fixme - feedback requested
by Austin English Oct. 3, 2008

Oct. 3, 2008

Howdy, I was taking a look at some of the noisy fixme's, and wanted some feedback on the attached patch. This particular fixme is _really_ noisy...out of this (http://bugs.winehq.org/attachment.cgi?id=16447) log, it has 9635 of the 13117 lines! "fixme:ntdll:NtLockFile I/O completion on lock not implemented yet" 9635 times! Not sure if this is the best way to go about this or not. Any advice appreciated (or if anyone else wants to silence it :-P). -Austin

5 6

RE: d3d8/9: Use WINED3D_OK instead of D3D_OK in vertexshader.c.
by Stefan Dösinger Oct. 3, 2008

Oct. 3, 2008

> -----Original Message----- > From: Henri Verbeet [mailto:hverbeet(a)gmail.com] > Sent: Friday, October 03, 2008 10:25 AM > To: Stefan Dösinger > Subject: Re: d3d8/9: Use WINED3D_OK instead of D3D_OK in vertexshader.c. > > 2008/10/3 Stefan Dösinger <stefan(a)codeweavers.com>: > > Actually, since the return value comes from WineD3D, we should use > WINED3D_OK here. Although there is not really a scheme behind all this > and we never cared about that because both WINED3D_OK and D3D_OK are > #define'd to S_OK. > > > Yes, that's what the patch does :-) Woops. Confusion

1 0

RE: d3d8/9: Use WINED3D_OK instead of D3D_OK in vertexshader.c.
by Stefan Dösinger Oct. 3, 2008

Oct. 3, 2008

Actually, since the return value comes from WineD3D, we should use WINED3D_OK here. Although there is not really a scheme behind all this and we never cared about that because both WINED3D_OK and D3D_OK are #define'd to S_OK. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Rob Shearman > Sent: Friday, October 03, 2008 6:56 AM > To: wine-patches > Subject: d3d8/9: Use WINED3D_OK instead of D3D_OK in vertexshader.c. > > --- > dlls/d3d8/vertexshader.c | 4 ++-- > dlls/d3d9/vertexshader.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-)

1 0

D3DXAssembleShader, unknown texture formats and misc
by Kjell Rune Skaaraas Oct. 3, 2008

Oct. 3, 2008

Hello,I'm taking a stab at implmenting D3DXAssembleShader, which takes shader instructions like "mul r1, r2.xy, r3.z" and turns them into binary code (one-to-one mapping). Although I've got very little clue what I'm really doing, I've come quite a way on a parser that breaks it down into the separate parts and made some reverse lookups on tables of opcodes, registrys, masks etc. that I found in the wine code. I've basicly come so far that I got the parts like mul = 0x00000005, r = temp registry = 0x00000000, register number = 0x00000001, writemask = 0x000F0000 etc. for all the arguments, but I'm struggling a bit putting it all together into the correct binary format. I have found a lot of material on the *text* format of the shader instructions, but pretty much none on the binary format. Clearly some documentation must have been used/made when you implemented glsl and the other shader backends as they read this stuff and translates it to OpenGL calls. Does anyone have anything they could share with me? P.S. Don't expect too much of me though, 1) It's so ugly it makes grown men cry, 2) Current it leaks memory bigtime and 3) It's a text hack that will never validate shader code or anything like that BUT I think I can make this work for code that already works.On a different note, a game I have is pulling up two completely unknown texture formats R16 and AL16 as fourcc. I figured I could at least find out something about them and add them to the debug tables, but the only references I find on google are to wine and wine bug reports. I figure they may be related to R16F (same with ints?) and L16 (luminosity, so AL16 with alpha?) but I can't find anything on them.Oh yeah and for the misc question - where's the right place to add test code? I expect my D3DXAssembleShader function will need a lot of it - at least one for each opcode, registry tests, write mask tests, whitespace and commenting tests+++. No code for you to review yet, not until it works. THEN you can bring out the tar and feathers over the code. Regards,Kjell Rune _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

2 1

Re: msxml3: Add IXMLHTTPRequest support (try 2)
by Juan Lang Oct. 3, 2008

Oct. 3, 2008

Hi Alistair, maybe I'm being overly picky, but:: --- /dev/null +++ b/dlls/msxml3/httprequest.c @@ -0,0 +1,343 @@ +/* This file has DOS line endings. The rest of the files do not. It's really distracting in the patch, since this portion of the patch has ^M at the end of every line. --Juan

1 0

Re: msxml3: Add IXMLHTTPRequest support
by Alistair Leslie-Hughes Oct. 3, 2008

Oct. 3, 2008

From: "Hans Leidekker" <hans(a)meelstraat.net> Sent: Friday, October 03, 2008 9:45 PM To: <wine-devel(a)winehq.org>; "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> Subject: Re: msxml3: Add IXMLHTTPRequest support > On Friday 03 October 2008 13:23:14 Alistair Leslie-Hughes wrote: > >> Changelog: >> msxml3: Add IXMLHTTPRequest support > > Would it be possible to use winhttp instead of nanohttp? The less > we depend on libxml the better I'd say. > Sure. This nanphttp was just my initial thought. I'll resend a corrected patch shortly. Best Regards Alistair Leslie-Hughes

1 0

Re: msxml3: Add IXMLHTTPRequest support
by Hans Leidekker Oct. 3, 2008

Oct. 3, 2008

On Friday 03 October 2008 13:23:14 Alistair Leslie-Hughes wrote: > Changelog: > msxml3: Add IXMLHTTPRequest support Would it be possible to use winhttp instead of nanohttp? The less we depend on libxml the better I'd say. -Hans

2 1

Re: [PATCH 1/2] wininet: Return error codes explicitly from URLCache functions instead of returning a BOOL and storing the error code in the last error value.
by Juan Lang Oct. 3, 2008

Oct. 3, 2008

Hi Rob, + * Locks the index for system-wide exclusive access. + * + * RETURNS + * TRUE if successful + * FALSE if failed and calls SetLastError. */ static LPURLCACHE_HEADER URLCacheContainer_LockIndex(URLCACHECONTAINER * pContainer) The comment's off here. @@ -1346,34 +1353,32 @@ static BOOL URLCache_AddEntryToHash(LPURLCACHE_HEADER pHeader, LPCSTR lpszUrl, D * FALSE if the hash table could not be created * */ -static HASH_CACHEFILE_ENTRY *URLCache_CreateHashTable(LPURLCACHE_HEADER pHeader, HASH_CACHEFILE_ENTRY *pPrevHash) +static DWORD URLCache_CreateHashTable(LPURLCACHE_HEADER pHeader, HASH_CACHEFILE_ENTRY *pPrevHash, HASH_CACHEFILE_ENTRY **ppHash) I think you forgot to update the comment here. --Juan

2 1

Re: msi: Implement the DROP TABLE sql command.
by Steven Edwards Oct. 3, 2008

Oct. 3, 2008

On Thu, Oct 2, 2008 at 3:25 PM, James Hawkins <jhawkins(a)codeweavers.com> wrote: > Hi, I can't repro this problem on my machine, so I'm sending this > patch to patchwatcher by way of wine-patches to get some info. Please > do not apply. Regarding our wineconf discussion about patchwatcher spam on wine-patches and filtering. Perhaps we need 2 email address patches can be sent to. My thinking is the flow could be something like: 1. By default everyone sends a patch to wine-patches 2. If a patch gets rejected the author gets a failure mail in private, and now retries or testing patches should go to wine-patches-testing N times until they get it right 3. once its right, patchwatch could then forward the new good patch to wine-patches or could send an email to the dev saying that its good enough to now send to wine-patches. Doing it like this, if everyone follows the rules, we won't get a ton of patchwatcher retries filling up wine-patches. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

4 6

Re: howto fix bug 13462
by Louis. Lenders Oct. 2, 2008

Oct. 2, 2008

Rob Shearman <robertshearman <at> gmail.com> writes: Hi Rob, i think i got the test ready now, i'll send it when the defenitions are in place in ctxtcall.idl. Now still strugling how to fix the bug. I fixed up the patch below, also by looking how things are done in similar places in wine-code. With patch applied I can see that ContextCallback_ContextCallback and ContextCallback_Release are called from the application (tested with NASA WorldWind), and the simple stubs are enough to let the app continue fine. But i'm not sure if everything is 100% ok. Is this what you more or less meant in your first comment? diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c index 37907ec..a1f41fd 100644 --- a/dlls/ole32/compobj.c +++ b/dlls/ole32/compobj.c @@ -55,6 +55,7 @@ #include "objbase.h" #include "ole2.h" #include "ole2ver.h" +#include "ctxtcall.h" #include "compobj_private.h" @@ -3615,25 +3616,39 @@ HRESULT WINAPI CoRegisterChannelHook(REFGUID guidExtension, IChannelHook *pChann typedef struct Context { const IComThreadingInfoVtbl *lpVtbl; + const IContextCallback *lpVtblIContextCallback; LONG refs; APTTYPE apttype; } Context; +static inline Context *impl_from_Context(IComThreadingInfo *iface) +{ + return (Context *)((char*)iface - FIELD_OFFSET(Context, lpVtbl)); +} + static HRESULT WINAPI Context_QueryInterface(IComThreadingInfo *iface, REFIID riid, LPVOID *ppv) { + Context* This=impl_from_Context((IComThreadingInfo*) iface); *ppv = NULL; if (IsEqualIID(riid, &IID_IComThreadingInfo) || IsEqualIID(riid, &IID_IUnknown)) { *ppv = iface; - IUnknown_AddRef(iface); - return S_OK; } + else if(IsEqualIID(riid, &IID_IContextCallback)) + { + *ppv = &This->lpVtblIContextCallback; + } + else + { + FIXME("interface not implemented %s\n", debugstr_guid(riid)); + return E_NOINTERFACE; + } - FIXME("interface not implemented %s\n", debugstr_guid(riid)); - return E_NOINTERFACE; -} + IUnknown_AddRef(iface); + return S_OK; +} static ULONG WINAPI Context_AddRef(IComThreadingInfo *iface) { @@ -3691,6 +3706,31 @@ static HRESULT WINAPI Context_SetCurrentLogicalThreadId(IComThreadingInfo *iface return E_NOTIMPL; } + +static HRESULT WINAPI ContextCallback_QueryInterface(IContextCallback *iface, REFIID riid, LPVOID *ppv) +{ + FIXME("\n"); + return E_NOTIMPL; +} + +static ULONG WINAPI ContextCallback_AddRef(IContextCallback *iface) +{ + FIXME("\n"); + return E_NOTIMPL; +} + +static ULONG WINAPI ContextCallback_Release(IContextCallback *iface) +{ + FIXME("\n"); + return E_NOTIMPL; +} + +static HRESULT WINAPI ContextCallback_ContextCallback(IContextCallback *iface, PFNCONTEXTCALL pfnCallback, ComCallData* pParam, REFIID riid, int iMethod, IUnknown* pUnk) +{ + FIXME("not implemented yet\n"); + return E_NOTIMPL; +} + static const IComThreadingInfoVtbl Context_Threading_Vtbl = { Context_QueryInterface, @@ -3702,6 +3742,14 @@ static const IComThreadingInfoVtbl Context_Threading_Vtbl = Context_SetCurrentLogicalThreadId }; +static const IContextCallbackVtbl Context_Callback_Vtbl = +{ + ContextCallback_QueryInterface, + ContextCallback_AddRef, + ContextCallback_Release, + ContextCallback_ContextCallback +}; + /*********************************************************************** * CoGetObjectContext [OLE32.@] * @@ -3735,6 +3783,7 @@ HRESULT WINAPI CoGetObjectContext(REFIID riid, void **ppv) return E_OUTOFMEMORY; context->lpVtbl = &Context_Threading_Vtbl; + context->lpVtblIContextCallback=(IContextCallback*)&Context_Callback_Vtbl; context->refs = 1; if (apt->multi_threaded) context->apttype = APTTYPE_MTA;

3 2