November 2007 - Wine-devel - list.winehq.org

Re: wininet: skip strcmp() in a test if the returned len is wrong
by Dmitry Timoshkov 09 Nov '07

09 Nov '07

"Lei Zhang" <thestig(a)google.com> wrote: > We'll skip doing strcmp() on a potentially uninitialized buffer if the > returned length is wrong. > - todo_wine ok(!strcmp(useragent,buffer),"Got wrong user agent string %s instead of %s\n",buffer,useragent); > - todo_wine ok(len == strlen(useragent),"Got wrong user agent length %d instead of %d\n",len,lstrlenA(useragent)); > + len_ok = (len == strlen(useragent)); > + todo_wine ok(len_ok,"Got wrong user agent length %d instead of %d\n",len,lstrlenA(useragent)); > + if (len_ok) > + todo_wine ok(!strcmp(useragent,buffer),"Got wrong user agent string %s instead of %s\n",buffer,useragent); Probably a better solution would be to actually check the return value of InternetQueryOption before touching the returned buffers. -- Dmitry.

1 0

valgrind/urlmon & http/variable question
by Misha Koshelev 09 Nov '07

09 Nov '07

> Hi Dan et al., > > So I just wanted to let you know that I have looked somewhat at one (the only as far as I saw) of the valgrind results related to HttpProtocol in urlmon, and basically it involves passing a pointer to a PROTOCOLDATA from a local variable inside a function to the ProtocolSink call which ends up > sending a message with this pointer. When this pointer is processed later, since it is a pointer to a local variable which (presumably) exists only on the stack, it is not really valid. > > Now this is quite easy to "fix" with a five-line patch that HeapAlloc's the proper structures. However, I was trying to figure out how native does this to copy it, and kind of ran into a dilemma. Namely, doing a simple patch like shown below (this probably won't really be a diff as I copy/pasted it > into WebMail which will probably mess it up, but it should give a general idea) and then doing a WINEDLLOVERRIDES with native urlmon and wininet and +relay WINEDEBUG I can see that the the PROTOCOLDATA pointers are pointing to stuff like 0x7d7ad790 and 0x7d7ad820. Now, much to my suprise, these > addresses, nor addresses in the proximate range (approximate) to that address don't seem to be part of any other relay calls, including any calls to any sort of allocation functions. Now this leaves me a little stumped ,as I can only see a few ways to properly implement these PROTOCOLDATA pointers > (without a memory leak): > > 1. A static PROTOCOLDATA variable (local or global). In this case, the address I see for native should never change I believe, but also this would not be correct as potentially you could have more than one HttpProtocol using the same structure. > > 2. Dynamic allocation of the PROTOCOLDATA structure. This seems like the best option to me, but native either does not seem to be using it or allocates it in some way in which the address or even partial versions of the address does not appear in any allocation functions (or really anywhere) in the > +relay log. Any ideas on what allocation functions I could be missing here? > > 3. Have one PROTOCOLDATA structure per IInternetProtocol implementation of http. This seems reasonable too, except I am also printing out the address of the IInternetProtocol structure and clearly PROTOCOLDATA is not in an address range anywhere near this structure, and it is never allocated so it > can't be a pointer within that structure. > > So anyhow I am a little stuck on the "proper" fix for this. Any suggestiosn would be appreciated. > > Thanks, > > Misha Hmm... so it looks like upon investigation the address ranges for PROTOCOLDATA with antive dlls are actually suspiciously similar to those I see in the current local variable implementation... which makes me think that the implementation is dissimilar (and thus leaky) in the downstream ProtocolSink implementation in binding.c, which will be a little harder to test... Misha

1 0

Problem with client manually starting services
by Roy Shea 08 Nov '07

08 Nov '07

Howdy All, I'm developing missing services in Wine and am running into problems with how Wine starts services. In Windows a service can be started using "net start <service name>", assuming that the service is properly added to the registry. In Wine it appears that the user must manually start the service before calling "net start <service name>", or the service fails to start. This is blocking me from developing an svchost wrapped DLL. I guess its not surprising that the work around of first manually starting a service fails for a DLL with no main function :-) Dan Kegel mentioned a recollection of a known bug in Wine along these lines where, as a work around, clients are manually starting servers. Anyone know more details on this problem? Any pointers to old emails or knowledge of this problem would be a big help I start digging through WINEDEBUG logs. Thanks! -Roy

2 4

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes
by Mirek Slugeň 08 Nov '07

08 Nov '07

2 6

Re: WineD3D: flush gl buffers are blt to drawable [attempt2]
by Stefan Dösinger 08 Nov '07

08 Nov '07

Am Donnerstag, 8. November 2007 23:40:18 schrieb Roderick Colenbrander: > Hi, > > This patch makes sure the gl buffer is flushed after blitting to the > screen. This fixes bug 9826 where traces of old frames appeared due to > this. You really shouldn't do this unconditionally, it is only needed if two contexts are drawing to the same drawable. A suggestion would be to mark the first use of a 2nd thread in a device in FindContext, and call the glFlush only if happened. The same glFlush is needed in all other places that draw something to the drawable: drawprim, clear and BltOverride come to my mind.

1 0

Typing Chinese Online On FireFox
by Jiang,Yi 08 Nov '07

08 Nov '07

I developped a site for Typing Chinese Online: http://www.typingChinese.com. It works on FireFox, IE, Mac. On test, I found FireFox is the fastest and used much less memory! Regards to all, Jiang,Yi

1 0

Develop .h for Wine by looking Microsoft Platform SDK
by Pau Garcia i Quiles 08 Nov '07

08 Nov '07

Hello, How legal (if at all) would be to develop a header file by looking reading the corresponding header file from the Microsoft Platform SDK and adapting it to gcc (removing MSVC stuff, etc)? I'm interested in supporting annotations[*] and before I start deducting everything from MSDN documentation, I'd like to know if there is a fast track. [*] More information: http://msdn2.microsoft.com/en-us/library/aa383701.aspx http://msdn2.microsoft.com/en-us/library/ms235402(VS.80).aspx Thank you. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

4 4

valgrind/urlmon & http/variable question
by Koshelev, Misha Vladislavo 08 Nov '07

08 Nov '07

Hi Dan et al., So I just wanted to let you know that I have looked somewhat at one (the only as far as I saw) of the valgrind results related to HttpProtocol in urlmon, and basically it involves passing a pointer to a PROTOCOLDATA from a local variable inside a function to the ProtocolSink call which ends up sending a message with this pointer. When this pointer is processed later, since it is a pointer to a local variable which (presumably) exists only on the stack, it is not really valid. Now this is quite easy to "fix" with a five-line patch that HeapAlloc's the proper structures. However, I was trying to figure out how native does this to copy it, and kind of ran into a dilemma. Namely, doing a simple patch like shown below (this probably won't really be a diff as I copy/pasted it into WebMail which will probably mess it up, but it should give a general idea) and then doing a WINEDLLOVERRIDES with native urlmon and wininet and +relay WINEDEBUG I can see that the the PROTOCOLDATA pointers are pointing to stuff like 0x7d7ad790 and 0x7d7ad820. Now, much to my suprise, these addresses, nor addresses in the proximate range (approximate) to that address don't seem to be part of any other relay calls, including any calls to any sort of allocation functions. Now this leaves me a little stumped ,as I can only see a few ways to properly implement these PROTOCOLDATA pointers (without a memory leak): 1. A static PROTOCOLDATA variable (local or global). In this case, the address I see for native should never change I believe, but also this would not be correct as potentially you could have more than one HttpProtocol using the same structure. 2. Dynamic allocation of the PROTOCOLDATA structure. This seems like the best option to me, but native either does not seem to be using it or allocates it in some way in which the address or even partial versions of the address does not appear in any allocation functions (or really anywhere) in the +relay log. Any ideas on what allocation functions I could be missing here? 3. Have one PROTOCOLDATA structure per IInternetProtocol implementation of http. This seems reasonable too, except I am also printing out the address of the IInternetProtocol structure and clearly PROTOCOLDATA is not in an address range anywhere near this structure, and it is never allocated so it can't be a pointer within that structure. So anyhow I am a little stuck on the "proper" fix for this. Any suggestiosn would be appreciated. Thanks, Misha --- diff --git a/dlls/urlmon/tests/protocol.c b/dlls/urlmon/tests/protocol.c index 00335b3..5b3579b 100644 --- a/dlls/urlmon/tests/protocol.c +++ b/dlls/urlmon/tests/protocol.c @@ -295,7 +295,9 @@ static HRESULT WINAPI ProtocolSink_Switch(IInternetProtocolSink *iface, PROTOCOL } SET_EXPECT(ReportData); + printf("!!! Continue %p -->\n", pProtocolData); hres = IInternetProtocol_Continue(http_protocol, pProtocolData); + printf("!!! Continue <--\n"); ok(hres == S_OK, "Continue failed: %08x\n", hres); CHECK_CALLED(ReportData); @@ -1255,6 +1257,7 @@ static void test_http_protocol_url(LPCWSTR url, BOOL is_first) hres = IClassFactory_CreateInstance(factory, NULL, &IID_IInternetProtocol, (void**)&http_protocol); ok(hres == S_OK, "Could not get IInternetProtocol: %08x\n", hres); + printf("!!! IInternetProtocol: %p %p\n", http_protocol, http_protocol+sizeof(IInternetProtocol)); if(SUCCEEDED(hres)) { BYTE buf[3600]; DWORD cb;

1 0

Re: d3dxof: return correct value for IDirectXFileDataImpl_GetType
by Roderick Colenbrander 08 Nov '07

08 Nov '07

> IDirectXFileDataImpl_GetType should return DXFILEERR_BADVALUE on failure, > not S_FALSE > > This patch fixes bug 10355 > > http://msdn2.microsoft.com/en-us/library/bb174490.aspx > Sure this could fix that bug but it not a real fix. D3dxof.dll is mostly a stub and its real functionality (loading and parsing of .x files) is missing. This GetType function is also related to the parsing of the .x file. In short this file contains data and some 'templates' for describing the data. This function returns the guid of that template. Returning a failure is not really an option in my opion as it won't get the app working. For the time being you should a native d3dxof.dll should be used or the rest of the .x file parsing should be added. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

2 1

Bugs in dlls/wsock32/socket.c
by Gerald Pfeifer 08 Nov '07

08 Nov '07

dlls/wsock32/socket.c has the following code: DWORD routeTableSize, numRoutes, ndx, ret; numRoutes = min(routeTableSize - sizeof(MIB_IPFORWARDTABLE), 0) / sizeof(MIB_IPFORWARDROW) + 1; The problem here is that both routeTableSize and sizeof(...) are of an unsigned type, so their difference is also unsigned. Which means that the minimum between that difference and 0 always will be 0, the result of the division will thus always be zero, and the result of the entire expressions is a constant 1. I have a hunch this is not the intendend purpose of this code, is it? Gerald -- Gerald (Jerry) Pfeifer gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 2