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

DirectDraw -> WineD3D patch

by Stefan Dösinger

Hi, I've brought my DirectDraw over WineD3D patch in a form where I want to show it to the public for review. I've uploaded it to http://stud4.tuwien.ac.at/~e0526822/, where it is described in detail(below the game list). If there are no fundamental objections against it, I'll start sending patches for WineD3D. The changes I'll make in small patches :) are: -> Header fixes, that wined3d_interface.h can be included with d3d.h -> Adding methods to WineD3D for DirectDraw rendering -> Adding the 2D only surface implementation to WineD3D When WineD3D is ready, I'll send a patch for dlls/ddraw to wine-devel and wine-user for a broad regression testing, and when the regressions are out, the ddraw can be replaced(From my POV, AJ has the last word of course ;) ) Have fun playing, Stefan

March 2, 2006

getwinegit.sh 0.21 released

by Christian Lachner

Hellooo, punctual to the new wine-0.9.9-release there is a new version of my getwinegit.sh-script. No great changes but some smaller ones. First of all, the logger got more informative if you experience problems with your getwinegit.sh-installation. The second thing is a better checking of the config-vars. Not the supergreat errorhandling i would like it to be but now there is something that checks if the vars are set and so on. The last thing is that the readme got a bit more informatical (dependencies and compatibility of shells). Maybe there were some more minor changes in the script but... i can't remember ;). Current version is now 0.21. PS: the release is now packed in a tar.bz2 as requested :D

March 2, 2006

Re: Dogfood Challenge, week 2

by Dan Kegel

On 2/9/06, Dan Kegel <dank(a)kegel.com> wrote: > > Firefox is quite usable; I read gmail in it routinely. > Here's my current list of firefox dogfood bugs: > > http://bugs.winehq.org/show_bug.cgi?id=4441 - black bars > http://bugs.winehq.org/show_bug.cgi?id=4523 - copy broken > http://bugs.winehq.org/show_bug.cgi?id=4528 - too tall > http://bugs.winehq.org/show_bug.cgi?id=4529 - screwy stars At first glance, Mike's patch for 4529 also fixes bugs 3171, 4441, and 4442! Firefox just got a lot tastier. (The patch isn't in cvs yet, but I think it ought to be, based on my extensive ten minutes of testing :-) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 2, 2006

Re: WineD3D Opengl 2.x compile fix

by H. Verbeet

On 02/03/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: >+ if(WINE_GL_VERSION_MAJOR(gl_info->gl_version) == 2) { Shouldn't that be >= 2? It seems unlikely functionality would get removed in later OpenGL versions.

March 2, 2006

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

by Alexandre Julliard

Vitaly Lipatov <lav(a)etersoft.ru> writes: > 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 That's not a bug, it's a feature. Binaries are now located relative to the library path, so if you move your Wine install somewhere else it still works, without having to set environment variables. -- Alexandre Julliard julliard(a)winehq.org

March 2, 2006

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

by Jan Zerebecki

On Wed, Mar 01, 2006 at 08:29:38PM -0800, Dan Kegel wrote: > Vitaly wrote: > >Build system in ALT Linux has strict requires to use rpath and last changes in > >wine conflicts with it. > > Can you explain more about ALT Linux's build system and rpath? > > Does it disallow all use of rpath by applications? > - Dan At least for Debian I think rpath may not be used. But as I understand it, it may be used if the referenced lib. path is completely private to the package, even tho that is discouraged. See the following link and especially the linked mailinglist thread for explanation: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#rpath Jan

March 2, 2006

Re: [PATCH 3/3] [Dnsapi.dll] Tests

by Steven Edwards

On 3/2/06, Steven Edwards <winehacker(a)gmail.com> wrote: > Why don't you break this out in to a function like load_dnsapi() that > way if there are missing symbols from one version to another you can > use GetProcAddress and delay load them and it will all be contained in > one function. Also to make it clear you don't need to do the delay loading of the symbols unless they really differ from one windows to another. Just using the LoadLibrary is fine. -- 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

March 2, 2006

Re: [PATCH 3/3] [Dnsapi.dll] Tests

by Steven Edwards

Hi, Just a matter of style to save moving the code around later if we add more tests. +START_TEST(names) +{ + HMODULE hdnsapi = LoadLibrary("dnsapi.dll"); + char *testname1 = ".bob"; + char *testname2 = ".bOb"; + + trace("Dnsapi.dll is only on Win2k and above.\nChecking...\n"); + if(hdnsapi != NULL) + { + trace("Dnsapi.dll loaded.\nNow unloading...\n"); + FreeLibrary(hdnsapi); + } + else + { + trace("Dnsapi.dll was not loaded or failed to be unloaded.\n"); + return; + } Why don't you break this out in to a function like load_dnsapi() that way if there are missing symbols from one version to another you can use GetProcAddress and delay load them and it will all be contained in one function. + trace("Now testing function: DnsNameCompare_A(LPSTR, LPSTR)\n"); + ok(DnsNameCompare_A(testname1,testname2)==TRUE, + "Comparison failed!\n %s and %s should be equal!\n",testname1,testname2); + trace("%s and %s are equal.\n",testname1,testname2); Also it would be a good idea to break this out in to another function. I tend to do one function per API I am checking so I would stick all of this in to a function called test_DnsNameCompare(); +} Nice work btw. Thanks for being patent with submitting patches and tests. I am not really that great of a programmer and these type of style changes help me follow along and write better tests. Take a look at this test I wrote to get the idea http://cvs.winehq.org/cvsweb/wine/dlls/setupapi/tests/stringtable.c?rev=1.2… It tends to be more lines but I think its much clearer to read. -- 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

March 2, 2006

Re: New d3d8 code and FFXIBench3 - pretty good!

by Stefan Dösinger

Hi, > I own Diablo 2... this would be a good reason to dust it off :) I should get it by today :) I ordered it at Amazon for a cheap price. Usually it takes 3 days until I get things. Snail mail that is :). > I am running fglrx as well, so I could work on getting the performance up > on these cards. I also have contacts at ATI, so if there are specific > problem I could send feedback directly, and hopefully they can fix things > for future releases. Although I'd check glDrawPixels on Windows as well... > I suspect it is just as slow there. Also for glDrawPixels you should turn > off a lot of the GL state (lighting and stuff that you don't need). That > could speed things up a bit. The attached program illustrates the problem: It's a d3d9 app and runs with current Wine CVS. On startup, it shows a black screen. If you press any button(except ESC), it will do a Clear with a solid color based on the key you pressed. If you click anywhere with the left mouse button, it locks the backbuffer, fills it with 0xff, unlocks it and flips. On Mesa radeon this has no effect(image doesn't change), with software rendering it's the same, as well with fglrx. If you change the pixel format to D3DFMT_R8G8B8, then it will work for fglrx. I haven't tested this on Windows, but I was told that it works with Nvidia cards in Wine. I just tested it in some old cvscedega version, and there it works, although I have to click twice. If you change D3DSWAPEFFECT_FLIP to D3DSWAPEFFECT_DISCARD in line 121, the screen will go black on clicks, with a delay of about one secound, so you can see the slowlyness. In some rare cases in games, glDrawPixels writes a dark, solid color, and if it writes to the front buffer, it's possible to see the new color sliding down slowly. I suspect that glDrawPixels isn't really broken, but WineD3D sets up render states which break it. I wanted to do a test with a simple GL app, but I didn't find the time yet. Current DDraw is broken in the same way, but it in the most cases, it draws a textured quad instead of using glDrawPixels, which works fine there.

March 2, 2006

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

by Rolf Kalbermatter

Mike McCormack [mike(a)codeweavers.com] wrote: >> + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); >> + return ERROR_CALL_NOT_IMPLEMENTED; >> +} > >You SetLastError or return an error code, not both. This is not always correct. Win32 API has several functions returning an int where the only SDK documentation is that the function returns 0 on success and anything else on failure. What those usually seem to do is retuning the (internal) error code. Relying on such a return value being anything than 0 or !0 of course would be bad programming, since there will be potential differences between different platforms but it does happen. Rolf Kalbermatter

March 2, 2006

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

by Dan Kegel

Vitaly wrote: >Build system in ALT Linux has strict requires to use rpath and last changes in >wine conflicts with it. Can you explain more about ALT Linux's build system and rpath? Does it disallow all use of rpath by applications? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 1, 2006

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

by Mike McCormack

Also, please disable your challenge/response spam "filter". Solving your spam problem by spamming everybody else is not cool. You wrote to us with a patch, you solicited our response, so why are you spamming us back? I'd advise others to not respond to spam from bluebottle.com. Mike

March 1, 2006

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

by Dmitry Timoshkov

"MattK" <mekjedi(a)bluebottle.com> wrote: > + if(fdwReason == DLL_THREAD_ATTACH) > + { > + DisableThreadLibraryCalls(hinstDLL); > + return TRUE; > + } This is not an appropriate place to call DisableThreadLibraryCalls, how did you come with it when there are a lot of examples in the Wine tree? -- Dmitry.

March 1, 2006

Re: x11drv fix for bug#4506: page fault on read access

by Dmitry Timoshkov

"Rein Klazes" <wijn(a)wanadoo.nl> wrote: > + srcpixel = (const DWORD*)((int)srcpixel & 0xfffffffc); It would be more readable IMO to use ~3 instead of 0xfffffffc. -- Dmitry.

March 1, 2006

[wined3d] glStencilOpSeparate & glStencilFuncSeparate symbol errors

by Aric Cyr

The recent patch: http://winehq.org/pipermail/wine-patches/2006-February/024656.html can cause linker errors for the two symbols glStencilOpSeparate and glStencilFuncSeparate. The reason being that these are only exported in OpenGL 2.0 compatible libraries, and in particular, are not present in ATI's binary driver. This causes wined3d to fail to build (compiles fine but linking fails). I suspect that Vitaly is already working on fixing this, but thought I'd mention it anyways since other might run into the same problem. Cheers, Aric

March 1, 2006

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 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? 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