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

Re: [PATCH] Fix Bug in DeadZone calculation

by Vitaliy Margolen

Artur Szymiec wrote: > Here is attached patch > for joystick_linuxinput.c where bug in dead zone > calculation make joystick unusable. After correction > tested in two games and works properly. > > Best Regards > Artur Szymiec > Thanks for spotting the problem. Unfortunately your patch has few problems too. I'll sending a better patch. Vitaliy.

Aug. 14, 2007

Re: user32: LB_SETITEMDATA should return 1 on success, not 0

by Alexandre Julliard

Peter Verthez <peter.verthez(a)advalvas.be> writes: > diff --git a/include/winuser.h b/include/winuser.h > index 4297a8d..97363e0 100644 > --- a/include/winuser.h > +++ b/include/winuser.h > @@ -2428,6 +2428,7 @@ typedef struct tagSCROLLBARINFO > > /* Listbox message return values */ > #define LB_OKAY 0 > +#define LB_SETITEMDATA_OKAY 1 /* undoc. OK return for LB_SETITEMDATA */ Please don't invent constants that don't exist on Windows. In this case TRUE would work just as well. -- Alexandre Julliard julliard(a)winehq.org

Aug. 14, 2007

Re: kernel: add execution permission to DOS memory area

by Alexandre Julliard

Mikolaj Zalewski <mikolaj(a)zalewski.pl> writes: > Execution permission is needed because we store some (mostly > DPMI-related) code in UMB (in winedos/himem.c) that is executed for > each Win16 app. The user may put even more code there. Ntvdm.exe also > makes the DOS memory executable (except for some parts of the UMB) winedos is supposed to make that memory executable when needed. The executable protection was removed from kernel32 as it causes failures on platforms that don't allow write+exec. -- Alexandre Julliard julliard(a)winehq.org

Aug. 14, 2007

Font problem + patch solution

by penna＠bb.com.br

Hi all, Since wine 0.9.31 there is a font problem (at least latin charset). There is a patch proposed at the bug #7571 (http://bugs.winehq.org/show_bug.cgi?id=7571) It works very well and I did not experiment any regression. Maybe it is not the ideal patch and if it is not, maybe we can provide a fix for that. However, at least it fixes the font problem and did not introduce any undesirable efects. Is that possible to apply that patch at the main tree? Comments are also welcome! Thank you in advance.

Aug. 14, 2007

Re: WGL: GDI support is not advertised with double buffering

by Roderick Colenbrander

Wouldn't it be cleaner to cache the double buffering property in the WineGLPIxelFormat and set the gdi cap in there? That would skip another unneeded function. Roderick

Aug. 14, 2007

Re: Problem with dlls/winex11.drv/opengl.c, revision 1.104

by Tomas Carnecky

Chris Rankin wrote: > With the update of dlls/winex11.drv/opengl.c from revision 1.103 to 1.104, World of Warcraft no > longer starts in OpenGL mode. WoW complains that my graphics card does not have "dual-TMU > support". (I have a Radeon R200 with Mesa 7.1) http://bugs.winehq.org/show_bug.cgi?id=9307

Aug. 14, 2007

Re: [oleaut32/tests] Error when running tests on Wine, anyone?

by Paul Vriens

Paul Vriens wrote: > Detlef Riekenberg wrote: >> On So, 2007-08-12 at 10:50 +0200, Stefan Leichter wrote: >>>>> Can somebody confirm if all oleaut32 tests run correctly on Wine. >>>> detlef(a)p4:~/wine.cvs/bin$ wine dlls/oleaut32/tests/oleaut32_test.exe.so >>>> vartest >> ... >>>> vartest.c:3129: Test failed: got VT_R8(-145) expected VT_R8(-1.4) >>>> vartest: 1031878 tests executed (0 marked as todo, 1 failure), 0 >>>> skipped. >>>> Intel P4 2GHz / Ubuntu 6.06 >>> Should we think about localisation? >> >> That's the reason for the failure! >> LANG="en_GB.UTF-8" wine ... => 0 failures >> Also for "en_GB", "it_IT", "fr_FR", "gr_GR", .... >> >>> Of course we are running both debian base distributions. This might >>> be another item to look on. >> >> Not needed. >> Our tests are not correct for w2k and below. >> My w2k_sp4(german) has 539 failures and includes the failure from wine: >>> vartest.c:3129: Test failed: got VT_R8(-145) expected VT_R8(-1.4) >> >> >> The WRT-Resultpage has 536 failures for w2k: >> http://test.winehq.org/data/200708071000/2000_W2KProf-Admin/oleaut32:vartes… >> >> >> >> > OK, we have a few results now and it we know that localization is > important. This however doesn't fix it for me, so there are more variables. > > I'm running on FC7 x86_64 with gcc 4.1.2. If people can post there > versions etc.. we can maybe come up with the other variables (this also > means people where the tests succeeds). > > So far: > > - localization influences the tests (which make sense because of the '.' > in 1.45 which is a ',' in other locales) > - I have 2 failures reported (with the same results) on a FC6/FC7 > x86_64. So maybe the 64-bit is a variable as well. > > Cheers, > > Paul. > Just installed a new F7 (x86) and the failures are present there as well. So it's most likely not a 64bit thingy. Could thus be gcc related? Could we rewrite the test: VARROUND(DATE,-1.45,1,DATE,-1.4); as : VARROUND(DATE,(-145/100),1,DATE,-1.4); to overcome the decimal separator issue. Or do we need other means to construct the 1.45/1,45? Cheers, Paul.

Aug. 14, 2007

Re: Our wiki software is ugly

by Mitchell Mebane

Scott Ritchie wrote: > On Mon, 2007-08-13 at 21:25 -0500, Mitchell Mebane wrote: > >> Scott Ritchie wrote: >> >>> Our wiki software needs a major update, especially as we start to expect >>> users to actually read it. >>> >>> For instance, look at the FAQ page: >>> >>> Then, click on edit and see how it should look. From what I can tell, >>> there are a few obvious errors: >>> >>> 1) The wiki software is completely ignoring line breaks. I could hit >>> return 4 times and the HTML rendered would be on subsequent lines, >>> without a break or paragraph tag between them. >>> 2) For some completely strange reason, if you make a list item that >>> includes a link then the entire list item will be in a smaller font. >>> This makes for extremely weird and inconsistent lists when a link to >>> another wiki page is included in some, but not all, of the items. >>> >>> >> This is due to http://wiki.winehq.com/wiki/winehq/css/screen.css >> >> #pagebar { >> font-size: 1em; >> } >> >> Making links overrides this style, and the preview page does not have >> this problem, because the content of the preview page is not enclosed in >> the #pagebar element. >> >> Not sure about the others yet. Could you elaborate on #3 a bit more? >> >> --Mitchell Mebane >> >> >>> 3) Header text is almost impossible to figure out right, and there is >>> absolutely no standard of what we should do. >>> >>> Is there a reason we chose the software we did? Would it be too hard to >>> migrate to something else, or at least fix the display bugs? >>> >>> Thanks, >>> Scott Ritchie >>> > > Regarding header text: do I use 1 = sign, or two, or three, or four, or > even five? Pages vary considerably around the entire wiki, though this > might be our fault as authors rather than the software. > > Thanks, > Scott Ritchie > > > You should start out with 1 level - i.e., a top-level section. Multiple equals signs should be used for sub-sections. E.g., = Section 1= == Sub-section 1.1 == == Sub-section 1.2 == === Sub-sub-section 1.2.1 === = Section 2 = Unfortunately, it seems they are often used for the same reason many people (ab)use the various <hx> tags HTML - to gain a certain font size, rather than for semantic meaning. --Mitchell Mebane

Aug. 14, 2007

Re: Our wiki software is ugly

by Scott Ritchie

On Mon, 2007-08-13 at 21:25 -0500, Mitchell Mebane wrote: > Scott Ritchie wrote: > > Our wiki software needs a major update, especially as we start to expect > > users to actually read it. > > > > For instance, look at the FAQ page: > > > > Then, click on edit and see how it should look. From what I can tell, > > there are a few obvious errors: > > > > 1) The wiki software is completely ignoring line breaks. I could hit > > return 4 times and the HTML rendered would be on subsequent lines, > > without a break or paragraph tag between them. > > 2) For some completely strange reason, if you make a list item that > > includes a link then the entire list item will be in a smaller font. > > This makes for extremely weird and inconsistent lists when a link to > > another wiki page is included in some, but not all, of the items. > > > This is due to http://wiki.winehq.com/wiki/winehq/css/screen.css > > #pagebar { > font-size: 1em; > } > > Making links overrides this style, and the preview page does not have > this problem, because the content of the preview page is not enclosed in > the #pagebar element. > > Not sure about the others yet. Could you elaborate on #3 a bit more? > > --Mitchell Mebane > > > 3) Header text is almost impossible to figure out right, and there is > > absolutely no standard of what we should do. > > > > Is there a reason we chose the software we did? Would it be too hard to > > migrate to something else, or at least fix the display bugs? > > > > Thanks, > > Scott Ritchie Regarding header text: do I use 1 = sign, or two, or three, or four, or even five? Pages vary considerably around the entire wiki, though this might be our fault as authors rather than the software. Thanks, Scott Ritchie

Aug. 14, 2007

Re: Our wiki software is ugly

by Mitchell Mebane

Scott Ritchie wrote: > Our wiki software needs a major update, especially as we start to expect > users to actually read it. > > For instance, look at the FAQ page: > > Then, click on edit and see how it should look. From what I can tell, > there are a few obvious errors: > > 1) The wiki software is completely ignoring line breaks. I could hit > return 4 times and the HTML rendered would be on subsequent lines, > without a break or paragraph tag between them. > 2) For some completely strange reason, if you make a list item that > includes a link then the entire list item will be in a smaller font. > This makes for extremely weird and inconsistent lists when a link to > another wiki page is included in some, but not all, of the items. > This is due to http://wiki.winehq.com/wiki/winehq/css/screen.css #pagebar { font-size: 1em; } Making links overrides this style, and the preview page does not have this problem, because the content of the preview page is not enclosed in the #pagebar element. Not sure about the others yet. Could you elaborate on #3 a bit more? --Mitchell Mebane > 3) Header text is almost impossible to figure out right, and there is > absolutely no standard of what we should do. > > Is there a reason we chose the software we did? Would it be too hard to > migrate to something else, or at least fix the display bugs? > > Thanks, > Scott Ritchie > > > > >

Aug. 14, 2007