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

Re: RFC: Adding tests for windowless richedit services

by James Hawkins

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

July 1, 2008

Re: Dylan Smith : richedit: Added missing DestroyWindow in a test.

by James Hawkins

On Tue, Jul 1, 2008 at 8:27 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Module: wine > Branch: master > Commit: 2a139746cc631f4ec291a89b4556af17266ce8c0 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=2a139746cc631f4ec291a89b4… > > Author: Dylan Smith <dylan.ah.smith(a)gmail.com> > Date: Sat Jun 28 03:00:46 2008 -0400 > > richedit: Added missing DestroyWindow in a test. > This commit is causing ~350 failures on all platforms. Please send in a fix or a revert patch. -- James Hawkins

July 1, 2008

Re: Possible issue with win.c and help

by celticht32＠aol.com

-----Original Message----- From: Lei Zhang <thestig(a)google.com> To: celticht32(a)aol.com Cc: wine-devel(a)winehq.org Sent: Tue, 1 Jul 2008 11:34 am Subject: Re: Possible issue with win.c and help On Mon, Jun 30, 2008 at 9:05 PM, Chris Ahrendt <celticht32(a)aol.com> wrote: > Ok in my ever increasing search to figure out why EQ2 is getting a > unhandled exception and also a no ipixel error. (I am convinced this is > two separate bugs now) > > Bug One : > > This is the unhandled exception: > If I have EQ2 run in anything but win98 mode (which I don't think is > supported anymore by EQ2) wine dies with a unhandled exception. If I set > to win98 it ends with a no ipixel format error message box (the second > bug) after it begins to draw the window. The other thing is the msg box > is not a typical msg box saying that something isn't supported but looks > to be an exception in ClientApp.cpp which means they are getting some > unhandled exception while drawing the window. > > What I think might be going on based on this : > > trace:win:WIN_SetWindowLong 0x2002c 0 0 W > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_DestroyWindow 0x2002c > trace:win:WIN_DestroyWindow 0x1002e > trace:win:WIN_DestroyWindow 0x10030 > trace:win:WIN_DestroyWindow 0x10032 > trace:win:WIN_DestroyWindow 0x10034 > trace:win:WIN_DestroyWindow 0x10036 > trace:win:WIN_DestroyWindow 0x10038 > trace:win:WIN_DestroyWindow 0x1003a > trace:win:WIN_DestroyWindow 0x1003c > trace:win:WIN_DestroyWindow 0x1003e > trace:win:WIN_DestroyWindow 0x10040 > trace:win:WIN_DestroyWindow 0x10042 > trace:win:WIN_DestroyWindow 0x10044 > trace:win:WIN_SetWindowLong 0x2002c 0 0 W > > ==================================================================== > These are my trace additions in SetWindowLong to help me follow the > execution of the code > > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_SetWindowLong 0x2002c 12 0 W > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Server Start Request > trace:win:WIN_SetWindowLong Default > trace:win:WIN_SetWindowLong no call Err > trace:win:WIN_SetWindowLong Default get and Set Win Data > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_SetWindowLong Returning 1871960 > > CRASH! Unhandled Exception > > I think the window is being destroyed in reverse for some reason. Thats > just my gut first feeling based on the above trace and the exception > output. This is where my knowledge on Windows behavior ends. Does 98 > destroy the windows chain differently than XP? This would explain why > the exception doesn't occur in 98 but does in XP. > > Second Bug: > This is the ipixel problem which I haven't figured out > how to debug whats going on there, but think it might be related to > this error: > > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering > > Which I am not sure why this is occurring yet but one bug at a time. > Where would someone look to trace along the window draw chain to see > where it dies. Some of the debug flags cause my machine to lock up which > I know is a driver issue and other lockups could be caused by the above > exception messing something up in X as the disk still runs when that > lockup occurs but X is DOA. > > Thoughts????? Ideas???? Suggestions?????? > > Chris > > > Hi, Please file bug reports on the Wine Bugzilla - http://bugs.winehq.org/ The second issue looks like 3d graphics are not set up correctly on your computer. You should ask your favorite Linux forum about that. Oh this is already reported as a bug... as to the second I know.. was just looking for some pointers... Need help actually understanding the way windows are handled in 98 vs XP . The graphic are set up correctly though... Chris

July 1, 2008

Re: programs: add rudimentary dxdiag

by Detlef Riekenberg

On Mo, 2008-06-30 at 10:15 -0500, Austin English wrote: > > Instead of simple stub, this patch also adds the (simplified) d3d test > > like seen in native dxdiag, so users can test if their d3d is setup > > correctly. Screenshot can be seen here: > > http://bugs.winehq.org/attachment.cgi?id=14342 > > It looks nice, but the Patch is very large! > > and it 's not really possible > > to send it in in small chuncks. Why not? - empty stub - the property-sheet - demo-window with an empty (in memory) Bitmap - the wine-logo as bitmap - spinning cube reorder, when needed > Like I said in the bug, you should add dxdiag to > configure.ac/Makefile.in/etc. > > -Austin No, Louis used the correct way: tools/make_makefiles ./autoconf -- By by ... Detlef

July 1, 2008

Re: Possible issue with win.c and help

by Lei Zhang

On Mon, Jun 30, 2008 at 9:05 PM, Chris Ahrendt <celticht32(a)aol.com> wrote: > Ok in my ever increasing search to figure out why EQ2 is getting a > unhandled exception and also a no ipixel error. (I am convinced this is > two separate bugs now) > > Bug One : > > This is the unhandled exception: > If I have EQ2 run in anything but win98 mode (which I don't think is > supported anymore by EQ2) wine dies with a unhandled exception. If I set > to win98 it ends with a no ipixel format error message box (the second > bug) after it begins to draw the window. The other thing is the msg box > is not a typical msg box saying that something isn't supported but looks > to be an exception in ClientApp.cpp which means they are getting some > unhandled exception while drawing the window. > > What I think might be going on based on this : > > trace:win:WIN_SetWindowLong 0x2002c 0 0 W > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_DestroyWindow 0x2002c > trace:win:WIN_DestroyWindow 0x1002e > trace:win:WIN_DestroyWindow 0x10030 > trace:win:WIN_DestroyWindow 0x10032 > trace:win:WIN_DestroyWindow 0x10034 > trace:win:WIN_DestroyWindow 0x10036 > trace:win:WIN_DestroyWindow 0x10038 > trace:win:WIN_DestroyWindow 0x1003a > trace:win:WIN_DestroyWindow 0x1003c > trace:win:WIN_DestroyWindow 0x1003e > trace:win:WIN_DestroyWindow 0x10040 > trace:win:WIN_DestroyWindow 0x10042 > trace:win:WIN_DestroyWindow 0x10044 > trace:win:WIN_SetWindowLong 0x2002c 0 0 W > > ==================================================================== > These are my trace additions in SetWindowLong to help me follow the > execution of the code > > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_SetWindowLong 0x2002c 12 0 W > trace:win:WIN_SetWindowLong Fell Through > trace:win:WIN_SetWindowLong Server Start Request > trace:win:WIN_SetWindowLong Default > trace:win:WIN_SetWindowLong no call Err > trace:win:WIN_SetWindowLong Default get and Set Win Data > trace:win:WIN_SetWindowLong Release Ptr > trace:win:WIN_SetWindowLong Returning 1871960 > > CRASH! Unhandled Exception > > I think the window is being destroyed in reverse for some reason. Thats > just my gut first feeling based on the above trace and the exception > output. This is where my knowledge on Windows behavior ends. Does 98 > destroy the windows chain differently than XP? This would explain why > the exception doesn't occur in 98 but does in XP. > > Second Bug: > This is the ipixel problem which I haven't figured out > how to debug whats going on there, but think it might be related to > this error: > > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering > libGL error: drmMap of framebuffer failed (Cannot allocate memory) > libGL error: reverting to (slow) indirect rendering > > Which I am not sure why this is occurring yet but one bug at a time. > Where would someone look to trace along the window draw chain to see > where it dies. Some of the debug flags cause my machine to lock up which > I know is a driver issue and other lockups could be caused by the above > exception messing something up in X as the disk still runs when that > lockup occurs but X is DOA. > > Thoughts????? Ideas???? Suggestions?????? > > Chris > > > Hi, Please file bug reports on the Wine Bugzilla - http://bugs.winehq.org/ The second issue looks like 3d graphics are not set up correctly on your computer. You should ask your favorite Linux forum about that.

July 1, 2008

Re: new inetmib1 test failures

by Juan Lang

> I'll relax the test from an == to a >=, which might > be surprising but is at least allowed according to RFC 1157. Oops, it isn't allowed, either. I'll use the handy new broken() instead. --Juan

July 1, 2008

Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value.

by Phil Krylov

On 29/06/2008, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > On Sun, Jun 29, 2008 at 4:20 AM, Phil Krylov <phil.krylov(a)gmail.com> wrote: > > Of course this looks most sane. But I'm asking if you're going to make > > use of the dwEmulatedVersion other than "< 0x200"? That is, under what > > circumstances we should emulate version 2 or 3 when we have support > > for version 5? It's interesting to me, because it seemed to me that > > the native versions (starting with 2.0) are very compatible to each > > other. > > > > -- Ph. > > > I know that versions 2 and 3 are very compatible with, since they register > the same class and dll name. Richedit 4.1 however uses msftedit.dll instead, > which means that programs would need to explicitlydecide which version > they are using depending on which dll they load and which class they specify. > > Certainly there are differences between richedit 3 and 4.1, but I don't know if > programs would depend on these differences. OK I see your point, and after hitting a very interesting blog on RichEdit, I even agree that the exact version number may be needed. http://blogs.msdn.com/murrays/archive/2006/10/14/richedit-versions.aspx http://blogs.msdn.com/murrays/archive/2006/10/20/some-richedit-history.aspx BTW they say that the DLL name for versions 5.0, 5.1, and 6.0 is riched20.dll again. -- Ph.

July 1, 2008

Re: Linker differences between Windows and Linux

by Alexandre Julliard

"Jussi Pakkanen" <jpakkane(a)gmail.com> writes: > 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)? Wine and Winelib use the standard linker. Check out the -Bsymbolic linker option. -- Alexandre Julliard julliard(a)winehq.org

July 1, 2008

Linker differences between Windows and Linux

by Jussi Pakkanen

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.

July 1, 2008

Re: oleaut32: Fix a test that fails on all platforms up to and including win2k

by Rob Shearman

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

July 1, 2008