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

shell32:shlfileop - interactive dialogs on Windows Vista

by Reece Dunn

Hi, One of the new features of Windows Vista is to bring up dialogs whenever you are copying files, moving files, etc. to ask the user what behaviour they want (e.g. move and replace; don't move; move, but keep both files). This makes it more user friendly, but for the Wine tests, it means that: - on XP the shlfileop tests run and pass eithout any user interaction; - on Vista, the shlfileop tests bring up several of those dialog prompts. I haven't yet looked at the tests to see what they are doing, or at the MSDN documentation to see if this would break things (i.e. if the program selected copy & replace, but the user said don't copy). Does anyone have any ideas how to get these working without user interaction (or if that is at all possible)? - Reece

Jan. 27, 2008

Wine Test Shell - timeouts during test runs too short?

by Reece Dunn

Hi, When running the Wine Test Shell to run the tests as part of http://test.winehq.org/, there are several timeouts in different places. These may be valid timeouts, but on my Vista test machine ddraw:d3d and msi:install generate the timeout message box part way through the test run, even though they continue and complete. Those tests are just slow. The others (such as kernel32:debugger) may be the same - especially when you get mixed results from different runs. Because of this, the timeout length should be increased (I would say at least doubled, to allow the long-running tests to run through). Another thing... I find it breaks the idea of an automated test run to have to watch it to OK the timeout messages. I know that UAC and the shfileop tests bring up interactive dialogs, but these are from within Windows itself, and will be dealt with by the timeout/test killer part of the Wine Test Shell. This would help make it easier for people to run the tests more often. - Reece

Jan. 27, 2008

Re: Wiki Down?

by Dimi Paun

On Fri, 2008-01-25 at 15:06 -0600, Austin English wrote: > What happened to the wiki? AppDB/WineHQ/Bugzilla are all fine, but > wiki.winehq.org seems to be down. The wiki is up. In fact, it was always up, but there was a little problem with the DNS yesterday (I think from 1-8PM EST) that affected our environment. It's been fixed, sorry for the downtime. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Jan. 27, 2008

Re: Implement D3DXCreateTextureFromFile

by Dmitry Timoshkov

"Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com> wrote: > diff --git a/dlls/d3dx8/d3dx8_main.c b/dlls/d3dx8/d3dx8_main.c > index c24aedc..931e6c1 100644 > --- a/dlls/d3dx8/d3dx8_main.c > +++ b/dlls/d3dx8/d3dx8_main.c > @@ -32,6 +32,30 @@ > #include "wine/unicode.h" > #include "d3dx8_private.h" > > +typedef enum D3DXIMAGE_FILEFORMAT > +{ > + D3DXIFF_BMP = 0, > + D3DXIFF_JPG = 1, > + D3DXIFF_TGA = 2, > + D3DXIFF_PNG = 3, > + D3DXIFF_DDS = 4, > + D3DXIFF_PPM = 5, > + D3DXIFF_DIB = 6, > + D3DXIFF_HDR = 7, > + D3DXIFF_PFM = 8, > + D3DXIFF_FORCE_DWORD = 0x7fffffff, > +} D3DXIMAGE_FILEFORMAT, *LPD3DXIMAGE_FILEFORMAT; D3DXIMAGE_FILEFORMAT s inot used in your patch, so it either should be a separate patch, or removed. > +typedef struct _D3DXIMAGE_INFO { > + UINT Width; > + UINT Height; > + UINT Depth; > + UINT MipLevels; > + D3DFORMAT Format; > + D3DRESOURCETYPE ResourceType; > + D3DXIMAGE_FILEFORMAT ImageFileFormat; > +} D3DXIMAGE_INFO; If D3DXIMAGE_INFO is used in public API definitions it should be placed in an appropriate SDK header. -- Dmitry.

Jan. 27, 2008

MinGW cross compiler rpms available

by Hans Leidekker

Updated cross compiler rpms are available here: http://mirzam.it.vu.nl/mingw/ I can build the full test suite from Wine 0.9.54 with these. -Hans

Jan. 26, 2008

Re: d3dx8, d3dx9_xx and d3dx10_xx

by tony.wasserka＠freenet.de

> Find attached some data on d3dx8, d3dx9_xx and d3dx10_xx implementations: > dll files by d3dx extension: > d3dx8 1 dll files > d3dx9_xx 13 dll files > d3dx10_xx 4 dll files > [...] > Nice work, how did you get the data? Did you run Dependency Walker on each dll or is there a more practical way? I'm creating stub dlls at the moment and need to get the parameters for each function on MSDN which is very time consuming and am looking for a faster way. However, to add a little more data, my list of the differences between the d3dx9 dlls: from d3dx9_24 to d3dx9_25: + D3DXUVAtlasCreate + D3DXUVAtlasPack + D3DXUVAtlasPartition from d3dx9_25 to d3dx9_26: + D3DXComputeIMTFromPerTexelSignal + D3DXComputeIMTFromPerVertexSignal + D3DXComputeIMTFromSignal + D3DXComputeIMTFromTexture from d3dx9_26 to d3dx9_27: (no changes) from d3dx9_27 to d3dx9_28: + D3DXPreprocessShader + D3DXPreprocessShaderFromFileA + D3DXPreprocessShaderFromFileW + D3DXPreprocessShaderFromResourceA + D3DXPreprocessShaderFromResourceW from d3dx9_28 to d3dx9_30: (no changes) from d3dx9_30 to d3dx9_31: - D3DXCpuOptimizations - D3DXGetTargetDescByName - D3DXGetTargetDescByVersion from d3dx9_31 to d3dx9_32: + D3DXSHMultiply2 + D3DXSHMultiply3 + D3DXSHMultiply4 + D3DXSHMultiply5 + D3DXSHMultiply6 from d3dx9_32 to d3dx9_35: (no changes) from d3dx9_35 to d3dx9_36: + D3DXCreateFragmentLinkerEx + D3DXGetShaderConstantTableEx They of course match to your reported number of function, great job. PS: My d3dx9_24 patch is on its way, just need to prove that everything is correct

Jan. 26, 2008

user32: understanding the HiliteMenuItem failures (all platforms)... call for help

by Reece Dunn

Hi, I am currently looking at the user32: menu (HiliteMenuItem) test failures: menu.c:1884: Test failed: HiliteMenuItem: Item 1 is not hilited menu.c:1891: Test failed: HiliteMenuItem: Item 3 is not hilited 1. These are failing consistently on all platforms (see http://test.winehq.org/data/200801161000 - you may need to search for HiliteMenuItem to find the failures!). 2. It appears (backed up with tests in the attached patch) that the API fails when the HWND parameter is NULL. 3. The tests are not comprehensive enough. The patch I have attached here is still a work in progress: 1. I have not tested it on Wine - it is likely that this will require todo_wine markers to make it run successfully. 2. The tests are still failing on Windows (both XP and Vista). Here is where I get stuck. According to the MDSN documentation (which is likely to be wrong) this appears to be correct. Does anyone know how to get HiliteMenuItem to work?! - Reece

Jan. 26, 2008

Re: ddraw: ddrawmodes test failures (all platforms)

by Paul Vriens

Stefan Dösinger wrote: > Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt: >> Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: >>> Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: >>>> Hi, >>>> >>>> Looking at the ddrawmode test failures, they are because the test is >>>> checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate >>>> is not 0. However, on many of the test platforms at >>>> http://test.winehq.org/data/200801161000, they are reporting a refresh >>>> rate of 0. >>>> >>>> Are these bogus - due to them running on VM - or is this a valid case? >>>> I don't currently have the ability to build those tests locally, so I >>>> cannot verify those failures. >>> I have never seen such failures on my real hardware(Windows XP or Vista), >>> so I think they fail due to VM drivers. I'll re-run the tests to make >>> sure the tests didn't break somewhen. >> I don't think so. My system (called xanlosch) is a real XP system with >> an ATI Mobility 9700 graphic card with one of the latest ATI drivers >> (7.11er catalyst drivers). Maybe an ATI driver issue? > If the ATI driver behaves that way then I think our tests should accept this > behavior > > I have a radeon 9000 mobility, and I don't remember any test failures > > > > Just ran the test on my real WinXP box (NVIDIA GeForce FX 5200) with the same results: http://test.winehq.org/data/200801161000/xp_XPSP2-HOME-NL/ddraw:ddrawmodes.… -- Cheers, Paul.

Jan. 26, 2008

Re: ddraw: ddrawmodes test failures (all platforms)

by Stefan Dösinger

Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt: > Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: > > Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: > >> Hi, > >> > >> Looking at the ddrawmode test failures, they are because the test is > >> checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate > >> is not 0. However, on many of the test platforms at > >> http://test.winehq.org/data/200801161000, they are reporting a refresh > >> rate of 0. > >> > >> Are these bogus - due to them running on VM - or is this a valid case? > >> I don't currently have the ability to build those tests locally, so I > >> cannot verify those failures. > > > > I have never seen such failures on my real hardware(Windows XP or Vista), > > so I think they fail due to VM drivers. I'll re-run the tests to make > > sure the tests didn't break somewhen. > > I don't think so. My system (called xanlosch) is a real XP system with > an ATI Mobility 9700 graphic card with one of the latest ATI drivers > (7.11er catalyst drivers). Maybe an ATI driver issue? If the ATI driver behaves that way then I think our tests should accept this behavior I have a radeon 9000 mobility, and I don't remember any test failures

Jan. 26, 2008

Re: ddraw: ddrawmodes test failures (all platforms)

by Henning Gerhardt

Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: > Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: >> Hi, >> >> Looking at the ddrawmode test failures, they are because the test is >> checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate >> is not 0. However, on many of the test platforms at >> http://test.winehq.org/data/200801161000, they are reporting a refresh >> rate of 0. >> >> Are these bogus - due to them running on VM - or is this a valid case? >> I don't currently have the ability to build those tests locally, so I >> cannot verify those failures. > I have never seen such failures on my real hardware(Windows XP or Vista), so I > think they fail due to VM drivers. I'll re-run the tests to make sure the > tests didn't break somewhen. I don't think so. My system (called xanlosch) is a real XP system with an ATI Mobility 9700 graphic card with one of the latest ATI drivers (7.11er catalyst drivers). Maybe an ATI driver issue? Regards, Henning Gerhardt

Jan. 26, 2008