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

Blocked conformance tests

by Francois Gouget

When I run winetest on Windows XP I get some dialog boxes asking me: Do you want to keep blocking this program? According to the title bar, the impacted tests are: dplayx rpcrt4 'Microsoft DirectPlay Helper' ??? ws2_32 My understanding is that it should only prevent the test from receiving network connections which I guess is not common. Does anyone know if this could cause any test failure currently? How does XP determine whether to block the test or not? Is the 'authorisation' based on the executable hash? If so there's no way to pre-authorise the tests for nightly tests. Should the winetest mark the executable so it is not hampered by this check? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Feb. 5, 2008

Re: kernel32: Add tests for LoadLibraryEx

by Alexandre Julliard

"James Hawkins" <truiken(a)gmail.com> writes: > I'm not sure how you feel this should be fixed. Is there a reason we > don't have tests for ntdll/loader.c? If not, I'd like add some tests > for LdrLoadDll. We don't have tests for it because apps don't use LdrLoadDll, so testing LoadLibraryEx should be enough. Of course if you have an app that depends on a specific behavior of LdrLoadDll then this should be tested. The todo in your test is because builtin dlls are supposed to get loaded even if the corresponding native file doesn't exist, that's a feature. -- Alexandre Julliard julliard(a)winehq.org

Feb. 5, 2008

Re: comctl32 failures on Win95, Win98, NT4 asnd Win2K

by Francois Gouget

On Tue, 29 Jan 2008, Paul Vriens wrote: [...] > > Several of the others have failures on Win95 and Win98 only. > > > > Is anyone going to look at these? I'm sending a patch to fix the InitCommonControlsEx() issue I introduced. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

Feb. 5, 2008

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2

by tony.wasserka＠freenet.de

Oh well, I forgot one point: if you take my example code again, but don't build it under winelib but under windows (i.e. it's a real win application) but later run it with wine it may also fail because all dlls forward to the D3DXCheckVersion of d3dx9_36. I know that you would have implemented another D3DXCheckVersion for each dll, but this again would've ended in the case I mentioned in the first e-mail. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

Feb. 5, 2008

Re: d3dx9_36: Implementation of D3DXCheckVersion try 2

by tony.wasserka＠freenet.de

I probably should've gone into a bit more detail about this function: It's just for developer purpose. If you have a very big project and are trying to upgrade e.g. from d3dx9_27 to d3dx9_36 some files may need to be rebuild, some files may not. This function is just there to ensure the developer that all files are built with the right dll. Now THIS means, that we won't ever see an ENDUSER application fail because of a d3dx9 version mismatch. Also, we come to a problem when a user wants to built an application with Winelib, where we can only use one definition of D3DX_SDK_VERSION which only applies to ONE dll. Now just watch following code sample: > #include "d3dx9.h" > > int check_version() { > if( D3DXCheckVersion( D3D_SDK_VERSION, D3DX_SDK_VERSION ) == FALSE ) { > MessageBox( NULL, "D3DX9 Versions don't match!", "Error!", MB_OK ); > exit( 1 ); > } > } Now, if a Winelib user compiles this, D3DX_SDK_VERSION is 9 (as its specified in our current d3dx9core.h). But if the program requires to be built with d3dx9_36 (and thus uses our implementation of D3DXCheckVersion) it will report an error as D3DX_SDK_VERSION was expected to be 36. So, the only thing we can test in this function is if D3DX_SDK_VERSION is between 24 and 36, which are all compatible versions (also, no enduser application will need the accurate implementation as stated above). I have made a mistake though, when I defined D3DX_SDK_VERSION to be 9, which was caused by my somewhat old installation of the DX SDK, which is incompatible with d3dx9_24 to d3dx9_36. (it was statically linked at that time), You don't need correct this in your patch, as this will be addressed in one of my future patches, I am just waiting for Julliard to (hopefully) accept my d3dx9_24 patch. In conclusion, all you have to do is replace the line > return ((D3DSdkVersion==D3D_SDK_VERSION) && (D3DXSdkVersion==D3DX_SDK_VERSION)); with > return ((D3DSdkVersion==D3D_SDK_VERSION) && (D3DXSdkVersion>=24 && D3DXSdkVersion <=36)); (Could also be => and =<, ain't that familiar with it) Best regards, Tony

Feb. 5, 2008

Re: [10/20] WineD3D: Make Clear aware of the depth stencil sharing

by H. Verbeet

On 05/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Stefan already knows this, but just for what it's worth, I've got a more complete fix in my tree for depth stencil sharing. Unfortunately that patch causes a couple of regressions, so it needs more work.

Feb. 5, 2008

Re: [7/20] WineD3D: De-Statify depth blit opengl resources

by H. Verbeet

On 05/02/2008, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I was aware of this issue, but technically these resources should be stored in the shader backend, not the device.

Feb. 5, 2008

Re: winetest experience

by Reece Dunn

On 05/02/2008, Jeremy White <jwhite(a)codeweavers.com> wrote: > Okay, so I boldly tried to use winetest with what documentation > I could find, and had an...um...interesting time. I have added my experiences to the wiki (http://wiki.winehq.org/ConformanceTests) with a link on the main page. Feel free to update it with your own experiences - Reece

Feb. 5, 2008

Re: winetest experience

by Reece Dunn

On 05/02/2008, Jeremy White <jwhite(a)codeweavers.com> wrote: > Okay, so I boldly tried to use winetest with what documentation > I could find, and had an...um...interesting time. The easiest thing I found for generating test results on Wine is to treat it like Windows. That is, download the winetest-[buildid]-paul-mingw.exe from the build you want to test and run: wine winetest-[buildid]-paul-mingw.exe e.g. on the http://test.winehq.org/data/200801301937/ page, the "Main summary for build 200801301937", and downloaded http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-200801301937…. Then, I ran ./wine winetest-200801301937-paul-mingw.exe from a build of wine-0.9.54 and followed the instructions on the program. It did generate an error about not being able to clean the log at the end, but it generated the "XP wine-0.9.54-notheme" and "XP wine-0.9.54" results without any issues. > So...what's the convention for build.id etc? And > why didn't they get set? Looking at the results from the Wine Test Shell, it is using a build timestamp. - Reece

Feb. 5, 2008

Re: War on conformance test suite failures!

by Reece Dunn

On 04/02/2008, Dan Kegel <dank(a)kegel.com> wrote: > Great progress was made at Wineconf last year on > getting our test suite closer to always passing on wine, but > http://test.winehq.org/data/200801301937/#Wine shows > that, according to the results collected from people who run > programs/winetest on Wine, twelve DLLs' tests are currently failing. > (Let alone the test failures on Windows!) > http://bugs.winehq.org/show_bug.cgi?id=9916 also > talks about the fact that "make test" shows failures. I have been providing patches to help the situation on all platforms. I am currently tracking 11 patches that are test related (9 on Windows - mainly Vista, but the directory-based listview failures should be fixed on all platforms, 2 on Wine). These haven't been applied yet because Alexandre went on holiday when I started my campaign against test suite failures. A few of these patches I have updated and resent as they needed todo blocks adding for Wine. I also kicked off discussions about different aspects of the test suite failures, but only some of these generated responses. I am specifically interested in increasing the timeout when running the Wine Test Shell to handle various timeouts (specifically software rendered D3D tests and MSI install tests). - Reece

Feb. 5, 2008