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

New valgrind warnings in fusion/tests/asmcache
by Dan Kegel 02 Jul '08

02 Jul '08

Hey James, could you have a look at these fresh warnings? Thanks! http://kegel.com/wine/valgrind/logs-2008-07-01/vg-fusion_asmcache-diff.txt + Conditional jump or move depends on uninitialised value(s) + at default_dbgstr_wn (debug.c:337) + by NTDLL_dbgstr_wn (debugtools.c:106) + by wine_dbgstr_wn (debug.c:408) + by debugstr_w (debug.h:260) + by GetCachePath (fusion.c:97) + by test_QueryAssemblyInfo (asmcache.c:981) + by func_asmcache (asmcache.c:1472) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a stack allocation + at test_QueryAssemblyInfo (asmcache.c:946) ... + + Conditional jump or move depends on uninitialised value(s) + at strlenW (unicode.h:212) + by strcatW (unicode.h:245) + by lstrcatW (string.c:190) + by test_QueryAssemblyInfo (asmcache.c:987) + by func_asmcache (asmcache.c:1472) + by run_test (test.h:449) + by main (test.h:498) + Uninitialised value was created by a stack allocation + at test_QueryAssemblyInfo (asmcache.c:946)

1 0

Re: [4/5] WineD3D: Delay render target activation
by James Hawkins 01 Jul '08

01 Jul '08

On Tue, Jul 1, 2008 at 2:12 PM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > You forgot the patch. -- James Hawkins

1 0

RE: [4/5] WineD3D: Delay render target activation
by Stefan Dösinger 01 Jul '08

01 Jul '08

This time with the patch > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Tuesday, July 01, 2008 2:13 PM > To: wine-patches(a)winehq.org > Subject: [4/5] WineD3D: Delay render target activation > >

1 0

Re: RFC: Adding tests for windowless richedit services
by James Hawkins 01 Jul '08

01 Jul '08

On Sun, Jun 29, 2008 at 11:56 PM, Austin Lund <austin.lund(a)gmail.com> wrote: > OK. I won't have access to a windows machine for a little while. Can > someone please test this patch for me? > The tests pass in win95, win2k, winxp, win2k3. Please remember to cc wine-devel and bottom-post replies. -- James Hawkins

1 0

Made ENTER_GL() - LEAVE_GL() free X11 lock on exception inside opengl, code
by Louis. Lenders 01 Jul '08

01 Jul '08

>And as was shown, Wine correctly returns NULL when its called without a context, so there is >something else making it crash. It may be a buggy driver. It may be memory corruption Wine is >causing.. who knows. i don't think it's buggy driver, this happens as far as i know for various people, so i'd guess various cards/drivers. Is there a way to track down what AutoCAD returns in this call to glGetString on Windows? Btw, the installer even finishes fine with native opengl32.dll ( no, this is not a joke!), so somehow i have the feeling that an exception handler is the right way anyway, but i lack knowledge of opengl, so i'll shut up for now ;) ) __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

4 3

new inetmib1 test failures
by James Hawkins 01 Jul '08

01 Jul '08

Hi Juan, Tests you added in the following commit are failing for most systems: commit c531c117340a43dbe8668189a32e6dd27f091ce4 Author: Juan Lang <juan.lang(a)gmail.com> Date: Tue May 20 20:54:34 2008 -0700 inetmib1: Support the MIB2 interface table. It looks like these values aren't set on all systems (these are the results from the failing XP system): main.c:191: Test failed: expected 2, got 65539 main.c:197: Test failed: expected 2, got 65539 main.c:203: Test failed: expected 2, got 65539 These are the results from a win2k machine: main.c:191: Test failed: expected 4, got 16777221 main.c:197: Test failed: expected 4, got 16777221 main.c:203: Test failed: expected 4, got 16777221 Can you please have a look at these? Thanks, James Hawkins

2 2

Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.
by Phil Krylov 01 Jul '08

01 Jul '08

Hi, 2008/6/27 Dylan Smith <dylan.ah.smith(a)gmail.com>: > riched20.dll is implementing all the versions of richedit controls (1.0, 2.0, > 3.0, and 4.1), so it is better to store the version that is being emulated. > The bEmulateVersion10 value is replaced with dwEmulatedVersion. I thought it implements 1.0 emulation for riched32.dll usage and latest possible version for other usages - just like native. Or are you planning to add some functionality depending on the actual emulated version, not on (dwEmulatedVersion < 0x200) boolean flag? -- Ph.

3 5

Linker differences between Windows and Linux
by Jussi Pakkanen 01 Jul '08

01 Jul '08

Hi I'm working on porting the Cuneiform OCR system from Windows to Linux. I'm getting a lot of problems by the different linking order of Linux and Windows. I want to make it a native Linux application, that is not depend on Winelib. (I already have it running, but it is very buggy.) The original code is a jumble of dll's that export all of their symbols. The problem is that there are hundreds of duplicate symbols among in them (for example each dll has an "error code" variable which all have the same name). Under Linux these symbols get aliased to one single symbol and cause spurious program crashes. I assume Wine deals with this by having its own linker. My question is how does Winelib handle this problem (or does it handle it at all)? Winelib's documentation does not mention this. Can this symbol resolver fix be (easily) extracted from Winelib and used on regular Linux programs? Or is there a way to automatically rename these kinds of symbols, preferably in the source code? For those interested, the code is at https://code.launchpad.net/~jpakkane/cuneiform-linux/trunk (the manual symbol resolvation fix is checked in in revision 185, so you might want to check out revision 184). Thanks for your help.

2 1

Re: oleaut32: Fix a test that fails on all platforms up to and including win2k
by Rob Shearman 01 Jul '08

01 Jul '08

2008/7/1 James Hawkins <jhawkins(a)codeweavers.com>: > + if (leftvt == VT_RECORD && rightvt == VT_I8) > + ok((hres == expectedhres || hres == DISP_E_BADVARTYPE) && > + V_VT(&result) == resvt, > + "VarSub: %d|0x%X, %d|0x%X: Expected failure 0x%X " > + "or 0x%X, got 0x%X, expected vt %d got vt %d\n", > + leftvt, ExtraFlags[i], rightvt, ExtraFlags[i], > + expectedhres, DISP_E_BADVARTYPE, hres, resvt, V_VT(&result)); > + else > + ok(hres == expectedhres && V_VT(&result) == resvt, > + "VarSub: %d|0x%X, %d|0x%X: Expected failure 0x%X, " > + "got 0x%X, expected vt %d got vt %d\n", > + leftvt, ExtraFlags[i], rightvt, ExtraFlags[i], > + expectedhres, hres, resvt, V_VT(&result)); There's the handy HAVE_OLEAUT32_I8 variable for the purpose of expecting when VT_I8 and VT_UI8 types are going to be accepted and when they're not. To avoid complicating the test, you could probably just skip it earlier on if we're testing a VT_I8 or VT_UI8 type in the left or right parameter and HAVE_OLEAUT32_I8 is false. -- Rob Shearman

1 0

new gdi32:font test failure
by James Hawkins 01 Jul '08

01 Jul '08

Hey Dmitry, A test you added in the following commit introduces ~1 failure per platform: commit 6f7457d8adaf67b457154a45deef21d5b5a87c8f Author: Dmitry Timoshkov <dmitry(a)codeweavers.com> Date: Tue Jun 24 16:13:31 2008 +0900 gdi32: Add a test for outline text metrics. Looking at the test code, it looks like a rounding difference: font.c:302: found bitmap font System, height 16 font.c:443: gm.gmCellIncX 1366, width_orig 1366 font.c:451: gm.gmCellIncX 683, width_orig 1366 font.c:483: gm.gmCellIncX 27320, width_orig 1366 font.c:494: gm.gmCellIncX 13660, width_orig 1366 font.c:514: gm.gmCellIncX 10758, width_orig 1366 font.c:517: Test failed: incX 10758 != 10757 Thanks, James Hawkins

1 0