June 2008 - Wine-devel - list.winehq.org

Re: ddraw: Don't release ddraw if a surface is still using it.
by Jens Albretsen 03 Jun '08

03 Jun '08

> Am Samstag, 31. Mai 2008 17:03:13 schrieb Michael Karcher: >> > Anyway it makes wine stop crashing when programs tries to do something >> > crazy like this. Stefan DÃ¶singer asked me to put a HeapAlloc all >> memory >> > between the two Release's to check if the memory of ddraw object would >> be >> > corrupt in Windows. It really doesn't matter if programs live by >> chance >> > in windows, if we can implement it so it's not by chance anymore. >> >> I agree on that point. > Actually, that is dangerous. There may be situations in which this > make-something-work has an unintended side effect, e.g. failure to restore > the display mode because the ddraw object isn't destroyed(although it > maybe > should be - it's the test's job to find that out). You're right, if we expect every program to behave. I guess we need a hook for wined3d (if we not already have it) to restore the state back at process termination, if there is stuff not freed, changed video modes and such. I believe d3d does this natively, if you change video and there is a abnormal program termination it will restore the video mode and if you're running with debug libraries it will tell you what you forgot to free, at least in Windows XP. I actually ran wine without virtual desktop at one point where program crashed, had to hard reset because video wasn't restored, CTRL+ALT+BACKSPACE didn't work, so now i'm running everything in a virtual desktop, so I guess there isn't any hook and we expect all programs to behave. The hook could probably be put wined3d_main.c/DllMain() fdwReason == DLL_PROCESS_DETACH so it closes wined3d correctly, in the event of abnormal program execution. > Another possibility are apps that intend to cause an exception, like copy > protection systems. Anyway still need to know if the test fails or passes in Windows.

2 1

Failing tests: now what?
by Juan Lang 03 Jun '08

03 Jun '08

Following through with Francois's suggestion, I extracted the user32 tests. They still fail for me: 81 failures in menu.c, all having to do with the expected width of menu items [1], which is precisely what I wanted to address. So I'm stymied how I'm going to convince Alexandre that my little menu patch [2] is correct. Vim is clearly broken without the patch, and looks correct with it. The user32 tests pass for me (in Wine) with and without the patch. None of the apps I've tried appear changed by the patch, though there's always the possibility. I can't verify it's correct in the usual way, by writing a test, because the existing tests fail for me in Windows. (Alexandre's never said he wants a test, but then again he hasn't said anything yet, either.) If anyone has any suggestions how I can get this accepted, I'm all ears. Thanks, --Juan [1] Typical failure: menu.c:432: Test failed: menu width wrong, got 109 expected 102 [2] http://www.winehq.org/pipermail/wine-patches/2008-May/055101.html

1 0

Re: Keep swapchain while its backbuffer is in use.
by Michael Karcher 02 Jun '08

02 Jun '08

Am Montag, den 02.06.2008, 22:51 +0200 schrieb Michael Karcher: > This fixes the warn+heap errors/crashes of d3d9:stateblock, and should > close the bug about differences with warn+heap enabled. Thats #12246, one of the 1.0 targeted bugs. I was offline while writing the patch email, so I could not look up the number. Regards, Michael Karcher

1 0

Re: winedbg: Fix 'winedbg --auto' so it does just one backtrace.
by Alexandre Julliard 02 Jun '08

02 Jun '08

Francois Gouget <fgouget(a)codeweavers.com> writes: > 'winedbg --auto' already prints a backtrace before the modules list. So > there is no need to print another one after everything else. Actually there are cases where it doesn't, which is why I added this. It's better to have two backtraces than none. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/2] wined3d: Set the surface location to SFLAG_INSYSMEM for depth stencils on Reset
by Stefan Dösinger 02 Jun '08

02 Jun '08

Am Montag, 2. Juni 2008 21:12:54 schrieb H. Verbeet: > This fixes a rather major regression when using FBOs for offscreen > rendering. Since we destroy the GL texture associated with the > surface, and INDRAWABLE and INTEXTURE are the same for offscreen > targets when using FBO ORM, the texture would never get recreated for > the depth stencil. Depth stencils are special in this regard since > they can switch between being onscreen and offscreen, for the other > implicit surfaces this isn't an issue. This should also fix bug 12794. > (This bug does expose issues with the surface management code, but I > don't think those are fixable before 1.0) updateSurfaceDesc releases the allocated system memory, so setting INSYSMEM is dangerous as well since allocatedMemory = NULL. depth stencils are't lockable, so we may get away with that, but it is still dangerous I think

2 1

Re: [2/2] Wineshader: Hardcode local constants with glUniform4fvARB
by Stefan Dösinger 02 Jun '08

02 Jun '08

Am Montag, 2. Juni 2008 21:45:07 schrieb Stefan Dösinger: Erm, the proper library is wined3d, not wineshader. "wineshader" is my current in-development HLSL compiler lib...

1 0

Invalid '...' in resources
by Francois Gouget 02 Jun '08

02 Jun '08

The files below contain ' . . .' instead of '...'. This is invalid typographically in at least English, French and Russian. Could someone check if it is valid for the relevant languages: Danish Dutch Hungarian Korean Norwegian Turkish ./programs/winefile/No.rc ./programs/oleview/No.rc ./programs/clock/No.rc ./programs/cmd/Da.rc ./programs/cmd/No.rc ./programs/taskmgr/No.rc ./programs/notepad/No.rc ./programs/winhlp32/No.rc ./programs/progman/No.rc ./programs/cmdlgtst/No.rc ./programs/wordpad/Ko.rc ./programs/wordpad/No.rc ./programs/wordpad/Tr.rc ./programs/wordpad/Nl.rc ./programs/wordpad/Hu.rc ./programs/winecfg/No.rc ./programs/regedit/Ko.rc ./programs/regedit/Da.rc ./programs/regedit/No.rc ./programs/regedit/Nl.rc ./dlls/setupapi/No.rc ./dlls/mshtml/No.rc ./dlls/gphoto2.ds/gphoto2_No.rc ./dlls/shell32/shell32_No.rc ./dlls/sane.ds/sane_No.rc ./dlls/msvfw32/msvfw32_No.rc ./dlls/msvfw32/msvfw32_Da.rc ./dlls/oledlg/oledlg_No.rc ./dlls/msacm32/msacm_Da.rc ./dlls/msacm32/msacm_No.rc ./dlls/comdlg32/cdlg_No.rc ./dlls/browseui/rsrc_No.rc ./dlls/shdoclc/Da.rc ./dlls/shdoclc/No.rc ./dlls/user32/resources/user32_No.rc -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

3 2

How to handle lack of internet connection in conformance tests
by Austin English 02 Jun '08

02 Jun '08

For curiousity's sake, I tested my work XP box today, first as usual, then after a reboot and disabling the network connection: http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/#group… http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/xp_aen… http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/xp_aen… Most of the tests came out the same, with some spurious failures in MSI/dinput/user32/etc. The interesting ones would be the urlmon/wininet. Some of these tests timeout (urlmon: protocol/url, wininet:http) , some failed (msxml3:domdoc), and some still passed(!) (wininet:ftp, wininet:generated, wininet:internet, wininet:url, wininet:urlcache, ws2_32:protocol, urlmon:misc). I haven't tested wine yet, as I can't bring down the network connection on any of the boxes I can currently test on, but I'll do so when I next get a chance. Either way, seems some of this behavior could be made more consistent (if network connection is down, either skip or timeout, but don't fail). I may try later with leaving the network connection up but removing the internet connection at the router... -Austin

1 0

Crash in test d3d9:stateblock with warn+heap is a wine bug
by Michael Karcher 02 Jun '08

02 Jun '08

Hello developers (mostly direct3d hackers), the infamous crash in d3d9:stateblock [1] is caused by a call sequence that is forbidden according to the DirectX SDK documentation. The switch_rendertarget test makes a new swap chain, and sets its backbuffer as new rendering target, and then releases the swap chain. The backbuffer is obtained by GetBackBuffer on the new swapchain. The SDK tells states explicitly that you have to release all surfaces obtained by GetBackBuffer before you release the swapchain itself. [2] In Windows, this buggy behaviour seems to work nicely (no crash in the d3d9:stateblock test and no errors with maximum debugging settings in the debugging d3d9 runtime), whereas on wine, at releasing the backbuffer finally, some access to the state is made which has already been released with the swapchain. So, we have two options: - Consider using backbuffer of released chains buggy: Fix the test to not release the swapchain Upgrade the FIXMEs in dlls/wined3d/swapchain.c, lines 95 and 104 to ERR - Implement behaviour seemingly compatible to Windows: Have a hidden reference counter to the swap chain or for the contexts to prevent them from getting freed too early. Does anyone knows whether the test has this been written buggy on purpose (some app does this), or it is by accident? Regards, Michael Karcher [1]: Bugs 9916, 12246 [2]: http://msdn.microsoft.com/en-us/library/bb205902(VS.85).aspx

3 4

Winetest grrr...
by Juan Lang 02 Jun '08

02 Jun '08

Since my tiny little menu patch didn't go in, I figured Alexandre wanted a test. So I tried to compile and run the existing one on Windows XP. It failed for me: lots of menu size tests failed. I checked the test.winehq.org data, and I don't see lots of failures on XP, so... I thought I'd run winetest.exe from Paul Millar's site, just in case the compilation environment had something to do with it. That locks up my laptop somewhere in the d3d/ddraw tests. I know some video drivers are so broken we don't want to run on them. I have an ATI Radeon Mobility 250. I thought this was a fairly common card. Is locking up the machine really acceptable here? How the ^$*@ am I supposed to produce a test when the existing ones fail/crash/burn for me? Grrr... --Juan

5 9