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

X developer's conference, April 16-18

by Dan Kegel

http://www.x.org/wiki/Events/XDC2008 Seems like Wine might want a representative. What issues would we want to bring up there? - relative mouse motion events ...? - Dan

Feb. 16, 2008

Autoplay considered harmful

by Dan Kegel

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/02/15/BU47V0VOH.DTL&t… says that USB devices are being sold with infected autorun apps. "If you plug in, you're already infected," I'd say that's a pretty good argument for not supporting autoplay...

Feb. 16, 2008

Re: [PATCH] Environment variable to specify X11 window for desktop

by Dmitry Timoshkov

"Timothy Lee" <timothy.lee(a)siriushk.com> wrote: >> I'm struggling to imagine a case where the behaviour you've >> implemented is useful. >> > I'm actually using this code as the basis of a PowerPoint plugin under > Linux. I little bit more information won't hurt. For instance why your plugin needs to re-route the whole desktop window, and not just its own one. -- Dmitry.

Feb. 16, 2008

Re: winedos: Allocate a console when loading dos applications

by Alexandre Julliard

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > These things make me think that the old behavior of wine is more > correct then the current one, with relation to console handles. The behavior hasn't changed for console handles, but the default case is to run on the unix stdio handles, not true console ones. That's a feature, we don't want to create a separate window for a simple command line app. There are two bugs here: one is that the unix stdio should be presented to the app as a real console as far as possible, the other is that the code should work correctly on non-console handles because even if we fix the first one we can always redirect i/o. The second bug should be easier to fix so I'd suggest to start with that. -- Alexandre Julliard julliard(a)winehq.org

Feb. 16, 2008

Re: d3dx9 patches

by tony.wasserka＠freenet.de

Okay, thanks. Then I'll just resend them and see if they get in this time. Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

Feb. 16, 2008

Re: gecko download not robust?

by Jan Zerebecki

On Fri, Feb 15, 2008 at 11:55:26AM -0600, Austin English wrote: > On Fri, Feb 15, 2008 at 11:32 AM, TheBlunderbuss <tehblunderbuss(a)gmail.com> wrote: > > marco wrote: > > > I can make a separate package of gecko > > This sounds good to me, but lets not compartmentalize wine too much, > > like Debian. > > Who wants to find out that you need so many wine* packages in order to > > get something to work? > Agreed, but I don't think wine, wine-dev, and wine-gecko is too much, > especially considering that wine-gecko rarely changes... IMHO there should be a meta-package that is named wine which depends on everything wine, but which itself doesn't contain any files. That is also how it seems to have been done in the latest wine in debian, so it is no problem anymore that their wine is split up in many packages. But users who know what they do can still choose the subset they want. Jan

Feb. 15, 2008

Re: winedos: Allocate a console when loading dos applications

by Maarten Lankhorst

Hi all, 2008/2/14, Dmitry Timoshkov <dmitry(a)codeweavers.com>: > "Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > > > > It worked before ba896e75d7fce68e5183007b65eae7e35490ccd4. (Around > > wine 0.9.33 or so) After that it was broken. I have a wine 0.9.9 that > > when run does create a seperate console for dos apps. My guess is that > > somewhere in the initialisation allocconsole would have to be called. > > > You need to talk to Alexandre since that's his patch. Still, there is > no AllocConsole() call removed by that commit, so it has nothing to do > with the regression. I've done a bunch of tests with a simple mingw app linked with -mconsole and found the following results (in xp sp2 vmware): - Asynchronous calls are not available for console handles (ReadFile only works in synchronous mode, ReadFileEx doesn't work) - I can do WaitForSingleObject(GetStdHandle(STD_INPUT_HANDLE), INFINITE); and it will only return when there is data to be read, like a key being pressed. in wine it will return immediately, this causes the breakage of dos apps after wine 0.9.33. These things make me think that the old behavior of wine is more correct then the current one, with relation to console handles. -Maarten.

Feb. 15, 2008

[PATCH] msvcrt: Fix scanf floating-point exponent handling.

by Jānis Rūcis

This patch modifies the scanf floating-point algorithm to pass the tests I sent in my previous message. --- dlls/msvcrt/scanf.h | 40 +++++++++++++++++++++++++--------------- 1 files changed, 25 insertions(+), 15 deletions(-) diff --git a/dlls/msvcrt/scanf.h b/dlls/msvcrt/scanf.h index 7fe3cc4..66df15e 100644 --- a/dlls/msvcrt/scanf.h +++ b/dlls/msvcrt/scanf.h @@ -241,6 +241,12 @@ _FUNCTION_ { case 'G': { /* read a float */ long double cur = 0; int negative = 0; + + int decimal_places = 0; + unsigned int exponent = 0; + int negexp = 0; + long double be; + /* skip initial whitespace */ while ((nch!=_EOF_) && _ISSPACE_(nch)) nch = _GETC_(file); @@ -268,20 +274,17 @@ _FUNCTION_ { } /* handle decimals */ if (width!=0 && nch == '.') { - float dec = 1; nch = _GETC_(file); if (width>0) width--; while (width!=0 && (nch!=_EOF_) && _ISDIGIT_(nch)) { - dec /= 10; - cur += dec * (nch - '0'); + cur = cur * 10 + (nch - '0'); + decimal_places += 1; nch = _GETC_(file); if (width>0) width--; } } /* handle exponent */ if (width!=0 && (nch == 'e' || nch == 'E')) { - int exponent = 0, negexp = 0; - float expcnt; nch = _GETC_(file); if (width>0) width--; /* possible sign on the exponent */ @@ -292,20 +295,27 @@ _FUNCTION_ { } /* exponent digits */ while (width!=0 && (nch!=_EOF_) && _ISDIGIT_(nch)) { - exponent *= 10; - exponent += (nch - '0'); + exponent = exponent * 10 + (nch - '0'); nch = _GETC_(file); if (width>0) width--; } - /* update 'cur' with this exponent. */ - expcnt = negexp ? .1 : 10; - while (exponent!=0) { - if (exponent&1) - cur*=expcnt; - exponent/=2; - expcnt=expcnt*expcnt; - } } + + /* Combine exponent with decimal point. */ + for (; decimal_places > 0; decimal_places--) + { + if (exponent == 0) + negexp = 1; + + exponent += negexp ? +1 : -1; + } + + /* Perform exponentiation. */ + for (be = 1.0; exponent > 0; exponent--) + be *= 10.0; + + cur = negexp ? cur / be : cur * be; + st = 1; if (!suppress) { if (L_prefix) _SET_NUMBER_(long double); -- 1.5.3.8

Feb. 15, 2008

[PATCH] msvcrt/tests: Add more scanf floating-point tests.

by Jānis Rūcis

The included patch adds a couple of scanf floating-point tests to expose a problem with the algorithm. It seems that it doesn't handle negative exponents very well, resulting in single-precision values being off-by-one in the last bit of significant compared to those obtained with the GNU C library or natively on Windows XP. All five tests pass on my Windows XP SP2 system (using a self-compiled msvcrt_crosstest.exe tool). Test 3 and 4 fail with the current source in Git. I will send another patch to this list with a potential fix. (I am not sending these to wine-patches because I'm not sure I should. "wine-devel" sounds about right.) --- dlls/msvcrt/tests/scanf.c | 40 ++++++++++++++++++++++++++++++++++++---- 1 files changed, 36 insertions(+), 4 deletions(-) diff --git a/dlls/msvcrt/tests/scanf.c b/dlls/msvcrt/tests/scanf.c index 65bea46..d5da3f6 100644 --- a/dlls/msvcrt/tests/scanf.c +++ b/dlls/msvcrt/tests/scanf.c @@ -28,7 +28,7 @@ static void test_sscanf( void ) char format[20]; int result, ret; char c; - float res1= -82.6267f, res2= 27.76f, res11, res12; + float orig, res; static const char pname[]=" St. Petersburg, Florida\n"; int hour=21,min=59,sec=20; int number,number_so_far; @@ -64,9 +64,41 @@ static void test_sscanf( void ) ok( result == 12, "sscanf reads %x instead of %x\n", result, 12 ); /* Check float */ - ret = sprintf(buffer,"%f %f",res1, res2); - ret = sscanf(buffer,"%f%f",&res11, &res12); - ok( (res11 == res1) && (res12 == res2), "Error reading floats\n"); + + orig = -82.6267f; + ret = sprintf(buffer, "%f", orig); + ret = sscanf(buffer, "%f", &res); + ok(ret == 1, "Expected 1 float, got %d\n", ret); + ok(res == orig, "Wrote %e (0x%x), but read %e (0x%x)\n", + orig, *(unsigned int *) &orig, res, *(unsigned int *) &res); + + orig = 27.76f; + ret = sprintf(buffer, "%f", orig); + ret = sscanf(buffer, "%f", &res); + ok(ret == 1, "Expected 1 float, got %d\n", ret); + ok(res == orig, "Wrote %e (0x%x), but read %e (0x%x)\n", + orig, *(unsigned int *) &orig, res, *(unsigned int *) &res); + + orig = -6.61589e-2f; + ret = sprintf(buffer, "%e", orig); + ret = sscanf(buffer, "%e", &res); + ok(ret == 1, "Expected 1 float, got %d\n", ret); + ok(res == orig, "Wrote %e (0x%x), but read %e (0x%x)\n", + orig, *(unsigned int *) &orig, res, *(unsigned int *) &res); + + orig = 1.72567e-7f; + ret = sprintf(buffer, "%e", orig); + ret = sscanf(buffer, "%e", &res); + ok(ret == 1, "Expected 1 float, got %d\n", ret); + ok(res == orig, "Wrote %e (0x%x), but read %e (0x%x)\n", + orig, *(unsigned int *) &orig, res, *(unsigned int *) &res); + + orig = 15.483e+3f; + ret = sprintf(buffer, "%e", orig); + ret = sscanf(buffer, "%e", &res); + ok(ret == 1, "Expected 1 float, got %d\n", ret); + ok(res == orig, "Wrote %e (0x%x), but read %e (0x%x)\n", + orig, *(unsigned int *) &orig, res, *(unsigned int *) &res); /* check strings */ ret = sprintf(buffer," %s", pname); -- 1.5.3.8

Feb. 15, 2008

Re: d3dx9 patches

by Stefan Dösinger

Am Donnerstag, 14. Februar 2008 19:47:38 schrieb tony.wasserka(a)freenet.de: > Hi, > It's nearly two weeks ago that I sent those patches, so I was curious if > there are any problems with it? Maybe they got lost due to Alexandre's vacations and travels? Other than that I've followed the controversy about some patches, but I don't have any strong opinion regarding any possible solution. > http://www.winehq.org/pipermail/wine-patches/2008-February/049554.html > http://www.winehq.org/pipermail/wine-patches/2008-February/049667.html > http://www.winehq.org/pipermail/wine-patches/2008-February/049677.html > http://www.winehq.org/pipermail/wine-patches/2008-February/049679.html > http://www.winehq.org/pipermail/wine-patches/2008-February/049705.html

Feb. 15, 2008