November 2007 - Wine-Devel - list.winehq.org

winetest.exe broken

by Stefan Leichter

Hello, as you all may have noticed winetest.exe does not longer build (see http://quisquiliae.physics.gla.ac.uk/crossbuild-logs/20071109-11:05.txt ). The patch: 65d865d96313d96889bf8cbe88c931b5e1e9bb74 is first bad commit commit 65d865d96313d96889bf8cbe88c931b5e1e9bb74 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Nov 8 12:21:10 2007 +0100 libwine: Refuse to use a WINEPREFIX dir owned by a different user. :040000 040000 1bf2b5da793741040732f222ce4a90ebd3f54b74 ee36bfdcf5d65ec8bb1c8ee478e74e0af8679039 M libs broke the build. Can someone please fix this. Thanks Stefan

Nov. 9, 2007

Re: [6/15] WineD3D: Replace the position fixup mul-add-add with a MAD

by Chris Robinson

I think the problem is that the replacement has incorrect order of operations. Originally, it was adding the half-pixel fixup then multiplying to invert the Y, while the MAD replacement does the Y invert first then the half-pixel fix. Also Mirek, can you please stop sending your messages as HTML? My client makes your messages nearly unreadable. Thanks.

Nov. 9, 2007

Re: xrun handling in winealsa.drv

by Maarten Lankhorst

Hello Timofei, Timofei V. Bondarenko schreef: > No matter how low the chance: sound is an real-time task while linux > is not a real-time system. So underruns still possible. > And in case of XRUN widRecorder() tries to read about 4G of data. > > Well, I'm a busy man too. So I've wrote a simple patch and sent it to > wine-patches. Please look. May be it will be more clear in C than in > my broken english. I took a quick look, it's incorrect for dscapture and dsoutput, underruns are already handled there in CheckXRUN, in case of _Stop it is unneeded as well since it just stopped and restarted, no underruns possible. The only thing needed in that part is that the < 0 checks need to have a cast to sframes. Regards, Maarten.

Nov. 9, 2007

Re: [14/15] WineD3D: Get rid of the conditionals in shader_glsl_compare

by Stefan Dösinger

Hi, I wrote a test, and I think I found the issue. Can you try the attached patch?

Nov. 9, 2007

notepad crashes in VNC @ 16bpp

by Francois Gouget

So if I start a VNC server with the following command: vncserver :1 -depth 16 -geometry 1024x768 Then notepad crashes on startup while initializing OpenGL. More precisely the crash happens in X11DRV_WineGL_InitOpenglInfo() on line 304 of winex11.drv/opengl.c. The reason for the crash is an OpenGL/X11 assertion: glxcmds.c:343: CreateContext: Assertion "mode != ((void *)0)" failed This seems like a VNC/OpenGL/X11 bug because Wine works fine if VNC is started in 15bpp or 24bpp. Still, the problem is that as this is part of the winex11 initialization it impacts all applications (including the DIB conformance tests). Does anyone see a way to avoid the crash? (maybe detect VNC before that call, but how?) Note: I'm using VNC 4.1.1+X4.3.0-2. Here's the xdpyinfo output in that mode: name of display: :1.0 version number: 11.0 vendor string: The XFree86 Project, Inc vendor release number: 40300000 XFree86 version: 4.3.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x400013, revert to Parent number of extensions: 23 BIG-REQUESTS DEC-XTRAP DOUBLE-BUFFER Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD SECURITY SGI-GLX SHAPE SYNC TOG-CUP VNC-EXTENSION X-Resource XC-APPGROUP XC-MISC XFree86-Bigfont XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1024x768 pixels (260x195 millimeters) resolution: 100x100 dots per inch depths (2): 1, 16 root window id: 0x2e depth of root window: 16 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x21 default number of colormap cells: 64 preallocated pixels: black 0, white 65535 options: backing-store YES, save-unders YES largest cursor: 1024x768 current input event mask: 0xd83f3f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask Button1MotionMask Button2MotionMask Button3MotionMask Button4MotionMask Button5MotionMask ButtonMotionMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals: 8 default visual id: 0x24 visual: visual id: 0x24 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 8 bits visual: visual id: 0x25 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x26 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x27 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x28 class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x29 class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x2a class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x2b class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

Nov. 9, 2007

Re: [6/15] WineD3D: Replace the position fixup mul-add-add with a MAD

by Mirek Slugeň

Nov. 9, 2007

Re: wininet: make a test pass on all versions of windows

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > How do we know which set of result to expect then? Do we consider all > three sets of behavior to be acceptable? Or just conform to the newest > behavior? Any results that are returned by Windows are by definition acceptable. So yes, you just have to accept the various behaviors, and make Wine conform to one of them (usually the newest is preferable). There's no reason to check that the behavior matches the reported Windows version, unless there is a real app that does a version check at that point. -- Alexandre Julliard julliard(a)winehq.org

Nov. 9, 2007

Re: xrun handling in winealsa.drv

by Maarten Lankhorst

Hello Timofei, Timofei V. Bondarenko schreef: > No matter how low the chance: sound is an real-time task while linux > is not a real-time system. So underruns still possible. > And in case of XRUN widRecorder() tries to read about 4G of data. > > Well, I'm a busy man too. So I've wrote a simple patch and sent it to > wine-patches. Please look. May be it will be more clear in C than in > my broken english. I took a quick look, it's incorrect for dscapture and dsoutput, underruns are already handled there in CheckXRUN, in case of _Stop it is unneeded as well since it just stopped and restarted, no underruns possible. The only thing needed in that part is that the < 0 checks need to have a cast to sframes. Regards, Maarten.

Nov. 9, 2007

Re: wininet: make a test pass on all versions of windows

by Lei Zhang

On Nov 9, 2007 2:47 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Lei Zhang" <thestig(a)google.com> writes: > > > + > > + { > > + OSVERSIONINFOEX foo; > > + BOOL r; > > + memset(&foo, 0, sizeof(foo)); > > + foo.dwOSVersionInfoSize = sizeof(foo); > > + r = GetVersionEx((OSVERSIONINFO *) &foo); > > + if (!r) > > + { > > + skip("could not get windows version\n"); > > + return; > > + } > > + > > + is_sp1 = -1; > > + if (foo.dwMajorVersion > 5) > > + is_sp1 = 1; > > + else if (foo.dwMajorVersion == 5) > > + { > > + if (foo.dwMinorVersion > 1) > > + is_sp1 = 1; > > + else if (foo.dwMinorVersion == 1) > > + { > > + if (foo.wServicePackMajor > 1) > > + is_sp1 = 1; > > + else if (foo.wServicePackMajor == 1) > > + is_sp1 = 0; > > + } > > + } > > Please don't add version checks in tests. > > -- > Alexandre Julliard > julliard(a)winehq.org > How do we know which set of result to expect then? Do we consider all three sets of behavior to be acceptable? Or just conform to the newest behavior?

Nov. 9, 2007

Re: No Subject

by Detlef Riekenberg

On Fr, 2007-11-09 at 11:38 +1000, Colin M Inglis wrote: your gcc is unable to compile this simple program: | int > | main () > | { > | > | ; > | return 0; > | } Reason: > /usr/bin/ld: can't locate file for: -lcrt1.o you need the development files for the c runtime library (this is "libc6-dev" here) --- cut --- GNU C Library: Development Libraries and Header Files Contains the symlinks, headers, and object files needed to compile and link programs which use the standard C library. --- cut --- -- By by ... Detlef

Nov. 9, 2007