March 2006 - Wine-Devel - list.winehq.org

Re: [PATCH 2/3] [Dnsapi.dll] Implement Dnsapi.dll

by Mike McCormack

MattK wrote: > +BOOL WINAPI DnsNameCompare_A(LPSTR pName1, LPSTR pName2) > +{ > + TRACE("(%s %s)\n",pName1, pName2); > + > + LPSTR name1 = pName1; > + LPSTR name2 = pName2; > + > + RemovePeriods(name1); > + RemovePeriods(name2); > + > + int equal; > + > + equal = lstrcmpiA(name1,name2); > + > + return !equal; > +} This is still not correct. You can't modify name1, and name2 in place. You shouldn't use inline declarations (ie. the "int equal" should be after the bracket.) There's also no in assigning pName1 to name1, it doesn't make a copy of the string as you suspect, it makes a copy of the pointer to the string. > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return ERROR_CALL_NOT_IMPLEMENTED; > +} You SetLastError or return an error code, not both. > diff -Nu dlls/dnsapi/utils.c dlls/dnsapi/utils.c There's no need to make a seperate file for this. > +LPSTR RemovePeriods(LPSTR string) > +{ > + if(string == NULL) > + return NULL; > + DWORD d = 0; > + > + while(string[d] == '.') > + { > + string--; > + } > + > + return string; > +} This won't work at all... If you wrote some better test cases you would discover these problems. How about testing: DnsNameCompare_A(NULL, NULL) DnsNameCompare_A("", ".") DnsNameCompare_A("..........", "..........") DnsNameCompare_A(".a.b.c.d.e.", "abcde") DnsNameCompare_A("a.com.","a.com") DnsNameCompare_A("A.com", "a.com") DnsNameCompare_A(".A.com", "a.com") DnsNameCompare_A("Acom", "acom") etc. Mike

March 2, 2006

Re: wined3d: Fix compile for older OpenGL headers.

by Raphael

On Wednesday 01 March 2006 11:48, Vitaly Budovski wrote: > H. Verbeet wrote: > > Although #ifdef GL_VERSION_2_0 will make compilation work with older > > OpenGl headers, it's not the way to fix this. Basically, wined3d > > should check for functionallity during runtime with GL_SUPPORT and > > call extensions with GL_EXTCALL. The issue has come up a few times > > before with patches from the same author, and I think he should be > > aware of the issue by now. > > That takes care of functions as part of an OpenGL extension. > What about core functions of a newer GL version? Would all of > those need to be defined in the wined3d_gl.h file? i forget :) We shouldn't have no more built-time checks as example: #if defined(GL_VERSION_1_3) We always must use runtime checks So WineD3D_GL_Info::gl_version must be correctly filled (isn't initialised for now) and used Regards, Rapahel

March 1, 2006

Re: wined3d: Fix compile for older OpenGL headers.

by Raphael

On Wednesday 01 March 2006 11:48, Vitaly Budovski wrote: > H. Verbeet wrote: > > Although #ifdef GL_VERSION_2_0 will make compilation work with older > > OpenGl headers, it's not the way to fix this. Basically, wined3d > > should check for functionallity during runtime with GL_SUPPORT and > > call extensions with GL_EXTCALL. The issue has come up a few times > > before with patches from the same author, and I think he should be > > aware of the issue by now. > > That takes care of functions as part of an OpenGL extension. > What about core functions of a newer GL version? Would all of > those need to be defined in the wined3d_gl.h file? Yes, else will have problems in wine launch if installed OpenGL library not provide this symbols Regards, Raphael

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Mike Hearn

On Wed, 2006-03-01 at 22:21 +0300, Vitaly Lipatov wrote: > Did you mean fix rpm spec? No, fix RPM the program. If the RPM software can't cope with a simple use of RPATH then it is buggy and should be patched. > You are about workaround explained by Alexandre? The workaround is fine for Wine, but it's the general principle I have a problem with. If you asked me to add a --disable-rpath switch to software I maintained I'd say no, because this is not a bug in my software but rather with RPM itself. > Now I think there is bug somewhere. I see in ps strange paths after ran any > program: > /usr/lib/../bin/wine-preloader > /usr/lib/../bin/wine-kthread notepad.exe > /usr/lib/../bin/wineserver Looks OK to me. A bit ugly maybe ...

March 1, 2006

Re: [PATCH 1/4] [WineDbg]: main_loop

by Eric Pouech

Alexandre Julliard wrote: > Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > > >>- split dbg_main_loop in two parts (one for finishing the debuggee >> attachment, the second one really for handling the main loop) >>- removed now longer needed dbg_main_loop > > > Auto mode is still broken with this patch... did you really test it? > yes, at some point, then did some last minute change, which broke it A+ -- Eric Pouech

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Vitaly Lipatov

В сообщении от 1 марта 2006 21:25 Mike Hearn написал(a): > On Wed, 2006-03-01 at 20:50 +0300, Vitaly Lipatov wrote: > > Dear Mike, I asked Alexandre to add _option_ to configure for disable > > rpath but to remove rpath using. > > I understand the request, but the question remains - why are you asking > every single upstream author to add complexity to their build systems, > when you could just fix RPM? Did you mean fix rpm spec? You are about workaround explained by Alexandre? Build system in ALT Linux has strict requires to use rpath and last changes in wine conflicts with it. I guess I do not understand where is problem in RPM you told about. Now I think there is bug somewhere. I see in ps strange paths after ran any program: /usr/lib/../bin/wine-preloader /usr/lib/../bin/wine-kthread notepad.exe /usr/lib/../bin/wineserver -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Mike Hearn

On Wed, 2006-03-01 at 20:50 +0300, Vitaly Lipatov wrote: > Dear Mike, I asked Alexandre to add _option_ to configure for disable rpath > but to remove rpath using. I understand the request, but the question remains - why are you asking every single upstream author to add complexity to their build systems, when you could just fix RPM? thanks -mike

March 1, 2006

Re: wined3d: Implemented WINED3DRS_DEPTHBIAS

by H. Verbeet

On 01/03/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > + glPolygonOffset(*((float*)&This->stateBlock->renderState[WINED3DRS_SLOPESCALEDEPTHBIAS]), tmpvalue.f); Does this compile?

March 1, 2006

Re: wined3d: Add function pointers to glSupportOpSeparate and glSupportFuncSeparate

by H. Verbeet

On 01/03/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: > wined3d: Add function pointers to glSupportOpSeparate and > glSupportFuncSeparate > That's not going to help much if you don't actually use them. Also, you probably want to be able to detect if the functions are actually available, instead of just dereferencing a NULL pointer if they aren't.

March 1, 2006

Re: Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to

by Vitaly Lipatov

В сообщении от 1 марта 2006 17:23 Mike Hearn написал(a): > On Fri, 24 Feb 2006 21:11:39 +0300, Vitaly Lipatov wrote: > > Sorry for my English. It is useful when we run wine from the source tree. > > It's useful for people distributing Wine binaries as well. Not every > feature is there for the distros you know ... also asking developers to > disable rpath because RPM cannot cope with it is remarkably poor form IMO, > just fix RPM! Dear Mike, I asked Alexandre to add _option_ to configure for disable rpath but to remove rpath using. It is poor way to make comments about distros and RPMs as your one. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

March 1, 2006