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

Re: added wgl_bind_to_texture_depth_nv to ConvertAttribWGLtoGLX
by Roderick Colenbrander 05 Feb '08

05 Feb '08

> This patch doesn't implement the format, simply says that is can't be > converted. This is my first patch, sorry if the format is wrong. Ok not converting the format is fine but you are also changing the return value of wglMakeCurrent. Resubmit the patch without that unneeded change. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: Bug in patch winex11.drv: Don't create a win_data structure for the desktop window, except in the process that owns it.
by Alexandre Julliard 05 Feb '08

05 Feb '08

"Luis C. Busquets Pérez" <luis.busquets(a)ilidium.com> writes: > It affects to Patrician3.exe. When initiating, it hangs and does not > allow to play the movie. Actually, the programm changes the screen > resolution and hangs. I understand that the problem is that it does not > send the appropiate message for binkplayer.exe to play the movie. What message is that, and why doesn't it send it? -- Alexandre Julliard julliard(a)winehq.org

1 0

OUTB() and friends on Win32 and .sys files
by Uwe Bonnes 05 Feb '08

05 Feb '08

Hallo, some programm with source uses giveio.sys to access the parallel port. You can find the source for giveio.sys e.g. in the avrdude package. We have code in dlls/winedos/ppdev.c to emulate the directed access on the parallel port to accesses to /dev/ppdev. However this code is not called for WIN32 code. So after starting giveio with loaddrv.exe supplied with giveio > wine loaddrv.exe start giveio starting giveio... ok. > wine javr.exe crashes when the outb access happens: javr [<filename>] [-p<port>] [-f<fusefilename>] [-e<eepromfilename>] [-L] [-V] Allocated flash buffer of 128K Using giveio.sys to gain port access to 0x378 trace:seh:raise_exception code=c0000096 flags=0 addr=0x4014b6 trace:seh:raise_exception eax=00000000 ebx=00000000 ecx=00000378 edx=00000378 esi=00000378 edi=00110388 trace:seh:raise_exception ebp=0072fe50 esp=0072fe50 cs=0073 ds=007b es=007b fs=0033 gs=003b flags=00010246 trace:seh:call_stack_handlers calling handler at 0x7eddc5bc code=c0000096 flags=0 trace:seh:MSVCRT_signal (4, (nil)) wine: Unhandled privileged instruction at address 0x4014b6 (thread 0011), starting debugger... trace:seh:start_debugger Starting debugger "winedbg --auto 16 56" trace:seh:call_stack_handlers handler at 0x7eddc5bc returned 1 Unhandled exception: privileged instruction in 32-bit code (0x004014b6). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:004014b6 ESP:0072fe50 EBP:0072fe50 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:00000378 EDX:00000378 ESI:00000378 EDI:00110388 Stack dump: 0x0072fe50: 0072fe58 0040151a 0072fe88 00406ccf 0x0072fe60: 00000378 00000000 00000000 00403411 0x0072fe70: 00000001 00110388 0072fe88 0040a3ef 0x0072fe80: 0040a3ef 00000001 0072fec8 004025e4 0x0072fe90: 00000378 00000378 00110048 0040255c 0x0072fea0: 7ed5ff48 7ffdf000 0072fec8 7ed30f5c Backtrace: =>1 0x004014b6 outb+0x6(value=0x0, port=0x378) [/spare/bon/jtagprog/win/javr-2.8/ppiwin.c:311] in javr (0x0072fe50) MS msvcrt.dll also supplies outb(). What is the policy to handle outb() and friends? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Call for winetest ing
by Jeremy White 05 Feb '08

05 Feb '08

Okay, so I got winetest to do something rational, and now I'd like to see if it will work for someone else. It's easy! Just apply this patch to a current Wine tree: http://www.winehq.org/pipermail/wine-patches/2008-February/049675.html Then configure and make Wine as you normally would. Then, cd programs/winetest ./runtests <your-tag-here> (The tag I used was jwhite-etch64; I think you should identify who you are, and then if you have multiple systems, your system within that). If you have winetricks in your path, it should be completely unattended. (If you don't, you'll need to hang around to click 'go' to the Gecko install dialog). After about 5 minutes, your test results should be run and sent up to test.winehq.org. The cron job runs every 5 minutes, so sometime after that, a reload of: firefox http://test.winehq.org/data/`date +%Y%m%d`/ Should show you your results! Easy as Pi! There is still quite a bit to do. First, I'm waiting for a 'real' winetest expert to wack me with a clue bat. But I'll stumble along until the hammer falls... Second, I want to do a stupidity check and make sure that winetest essentially correlates to a make -k test run. If they are not really identical, then we need to fix that problem... Next, I think we should probably shift the build-id from being the date to being the HEAD sha1, but that's a radical enough change that I felt I needed to start simpler and within the current conventions. But I'd really appreciate it if folks could try this and see if we can gather some data quickly. In theory, we should be able to quickly see the common points of failure and know where to attack first. Cheers, Jeremy

5 7

Blocked conformance tests
by Francois Gouget 05 Feb '08

05 Feb '08

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.

2 1

Re: kernel32: Implement ReplaceFileW. [RESEND]
by Alexandre Julliard 05 Feb '08

05 Feb '08

Robert Shearman <rob(a)codeweavers.com> writes: > + /* > + * Open the replacement file for reading, writing, and deleting > + * (writing and deleting are needed when finished) > + */ > + if ((hReplacement = CreateFileW(lpReplacementFileName, > + GENERIC_READ | GENERIC_WRITE, > + FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > + NULL, OPEN_EXISTING, 0, 0)) == INVALID_HANDLE_VALUE) > + { > + error = GetLastError(); /* Use error returned by CreateFileW */ > + goto fail; > + } Files should be opened with NtOpenFile the same way MoveFile does, to avoid having to convert path names twice. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [10/20] WineD3D: Make Clear aware of the depth stencil sharing
by H. Verbeet 05 Feb '08

05 Feb '08

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.

2 2

Re: [7/20] WineD3D: De-Statify depth blit opengl resources
by H. Verbeet 05 Feb '08

05 Feb '08

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.

2 2

running "make test" results in an error
by Christopher 05 Feb '08

05 Feb '08

I tried running "make test" under Ubuntu 7.10, and I just updated to the latest cvs this morning so it's not too old. However, after only running a couple of tests it exited with an error. Is this normal, and if so how do I run the rest of the tests? I attached a log showing which test fails. Christopher make[1]: Entering directory `/home/christopher/wine-git/tools' make[1]: `makedep' is up to date. make[1]: Leaving directory `/home/christopher/wine-git/tools' make[1]: Entering directory `/home/christopher/wine-git/dlls' make[2]: Entering directory `/home/christopher/wine-git/dlls/advapi32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/advapi32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/advpack/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/advpack/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/browseui/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/browseui/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/cabinet/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/cabinet/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comcat/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comcat/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comctl32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comctl32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/comdlg32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/comdlg32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/credui/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/credui/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/crypt32/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/crypt32/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/cryptnet/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/cryptnet/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/d3d8/tests' make[2]: Nothing to be done for `test'. make[2]: Leaving directory `/home/christopher/wine-git/dlls/d3d8/tests' make[2]: Entering directory `/home/christopher/wine-git/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so device.c && touch device.ok fixme:win:EnumDisplayDevicesW ((null),0,0x34f8c0,0x00000000), stub! fixme:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? device.c:753: Test failed: Screen width is 1680 device.c:754: Test failed: Screen height is 1050 err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful -- perhaps display has changed? device.c:798: Test failed: Screen width is 1680 device.c:799: Test failed: Screen height is 1050 err:d3d:IWineD3DDeviceImpl_DrawIndexedPrimitive (0x144548) : Called without a valid index buffer set, returning WINED3DERR_INVALIDCALL fixme:d3d:SetupForBlit >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glOrtho @ context.c / 622 fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 fixme:d3d:transform_projection >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glOrtho @ state.c / 2802 fixme:d3d_surface:flush_to_framebuffer_drawpixels >>>>>>>>>>>>>>>>> GL_INVALID_VALUE (0x501) from glDrawPixels @ surface.c / 1061 fixme:d3d:IWineD3DDeviceImpl_SetLightEnable Too many concurrently active lights make[2]: *** [device.ok] Error 4 make[2]: Leaving directory `/home/christopher/wine-git/dlls/d3d9/tests' make[1]: *** [d3d9/tests/__test__] Error 2 make[1]: Leaving directory `/home/christopher/wine-git/dlls' make: *** [dlls/__test__] Error 2

4 3

Re: kernel32: Add tests for LoadLibraryEx
by Alexandre Julliard 05 Feb '08

05 Feb '08

"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

1 0