wine-devel February 2008

wine-devel@winehq.org

141 participants
325 discussions

Autoplay considered harmful
by Dan Kegel 18 Feb '08

18 Feb '08

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...

7 7

Re: [advapi32/tests #2] Don't set last error to 0 so we can check if it has changed
by Alexandre Julliard 18 Feb '08

18 Feb '08

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > We test for a last error of 0, so we shouldn't set it to 0 before the > function is called. This however introduces a todo_wine. Is there any reason to believe that last error should be 0 on success? This looks more like a broken test to me. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: include: Add support for executing finally code for exceptions without using a separate function.
by Alexandre Julliard 18 Feb '08

18 Feb '08

Robert Shearman <rob(a)codeweavers.com> writes: > The first goal is accomplished by changing the previous two-state > variable of __first into a three-state variable where the third state > is the state in which the finally code is executed in the normal > case. The second goal is accomplished by calling sigsetjmp in > __wine_finally_handler to give the finally code a place to jump back > to after it has finished executing. That can't work, once you longjmp into the finally block you can't longjmp back, since you are no longer inside the function that did the setjmp. -- Alexandre Julliard julliard(a)winehq.org

2 1

iTunes
by Christopher Harvey 18 Feb '08

18 Feb '08

What needs to get done for iTunes to work?

3 3

[PATCH] msvcrt/tests: Add more scanf floating-point tests.
by Jānis Rūcis 18 Feb '08

18 Feb '08

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

2 1

programs: add winestartfile for starting files from the unix path (for file managers)
by Vincent Povirk 18 Feb '08

18 Feb '08

This is now attempt 4, not that anyone's counting. Adding winelib programs is a bit involved, and I imagine I've screwed something up along the way. If you know how to add them properly, please say something, even if it's to tell me I did it right. This patch adds a winelib program called winestartfile for starting files given the unix path. It attempts to mimic what windows explorer does to start files and provide some visible (gui) feedback when it doesn't work. The idea is that wine.desktop can then be modified to use winestartfile instead of wine, solving the following problems when starting exe files from file managers: * File managers typically do not set the working directory to the directory that contains an exe when they start it. Setting the working directory is the default behavior for windows explorer, and many windows programs rely on it. * File managers naturally use the unix path to start files, and the wine binary passes the unix path along to the exe it starts, rather than translating it to a windows path (this can and probably should also be fixed somewhere else). * Windows explorer always starts exe files with quotes around the path in the command-line, even if the path does not contain spaces. The wine binary does not (and probably should not) add quotes in this situation. A few apps rely on the quotes. See http://bugs.winehq.org/show_bug.cgi?id=5224#c14 -- Vincent Povirk

2 3

Re: inetcomm: Fix compilation on systems that don't support nameless unions.
by Marcus Meissner 18 Feb '08

18 Feb '08

On Mon, Feb 18, 2008 at 11:54:22AM +0100, Francois Gouget wrote: > --- > dlls/inetcomm/mimeole.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > diff --git a/dlls/inetcomm/mimeole.c b/dlls/inetcomm/mimeole.c > index a0da6b9..e986e7f 100644 > --- a/dlls/inetcomm/mimeole.c > +++ b/dlls/inetcomm/mimeole.c > @@ -1257,7 +1257,7 @@ static HRESULT WINAPI sub_stream_CopyTo( > ULARGE_INTEGER totalBytesRead; > ULARGE_INTEGER totalBytesWritten; > > - TRACE("(%p)->(%p, %d, %p, %p)\n", iface, pstm, cb.LowPart, pcbRead, pcbWritten); > + TRACE("(%p)->(%p, %d, %p, %p)\n", iface, pstm, cb.u.LowPart, pcbRead, pcbWritten); > > totalBytesRead.QuadPart = 0; > totalBytesWritten.QuadPart = 0; > @@ -1525,7 +1525,7 @@ static HRESULT create_body_offset_list(IStream *stm, const char *boundary, struc > > zero.QuadPart = 0; > hr = IStream_Seek(stm, zero, STREAM_SEEK_CUR, &cur); > - start = cur.LowPart; > + start = cur.u.LowPart; > > do { > hr = IStream_Read(stm, overlap, PARSER_BUF_SIZE, &read); > @@ -1599,7 +1599,7 @@ static body_t *create_sub_body(MimeMessage *msg, IStream *pStm, BODYOFFSETS *off > IMimeBody_Load(mime_body, pStm); > zero.QuadPart = 0; > hr = IStream_Seek(pStm, zero, STREAM_SEEK_CUR, &cur); > - offset->cbBodyStart = cur.LowPart + offset->cbHeaderStart; > + offset->cbBodyStart = cur.u.LowPart + offset->cbHeaderStart; > if(parent) MimeBody_set_offsets(impl_from_IMimeBody(mime_body), offset); > IMimeBody_SetData(mime_body, IET_BINARY, NULL, NULL, &IID_IStream, pStm); > body = new_body_entry(mime_body, msg->next_hbody, parent); > @@ -1629,8 +1629,8 @@ static body_t *create_sub_body(MimeMessage *msg, IStream *pStm, BODYOFFSETS *off > IStream *sub_stream; > ULARGE_INTEGER start, length; > > - start.LowPart = cur->offsets.cbHeaderStart; > - length.LowPart = cur->offsets.cbBodyEnd - cur->offsets.cbHeaderStart; > + start.u.LowPart = cur->offsets.cbHeaderStart; > + length.u.LowPart = cur->offsets.cbBodyEnd - cur->offsets.cbHeaderStart; > create_sub_stream(pStm, start, length, &sub_stream); > sub_body = create_sub_body(msg, sub_stream, &cur->offsets, body); > IStream_Release(sub_stream); > @@ -1674,7 +1674,7 @@ static HRESULT WINAPI MimeMessage_Load( > > zero.QuadPart = 0; > IStream_Seek(pStm, zero, STREAM_SEEK_END, &cur); > - offsets.cbBodyEnd = cur.LowPart; > + offsets.cbBodyEnd = cur.u.LowPart; > MimeBody_set_offsets(impl_from_IMimeBody(root_body->mime_body), &offsets); > > list_add_head(&This->body_tree, &root_body->entry); > There seems to be damage in here, both ^M and lose 0s. Ciao, Marcus

1 0

Re: user32: Check for .ico and .cur magic.
by Dmitry Timoshkov 18 Feb '08

18 Feb '08

"Andrew Riedi" <andrewriedi(a)gmail.com> wrote: > +#define ICON_DIB_SIZE 4264 It would be helpful to actually calculate the size instead of hardcoding the magic value. > + handle = LoadImageA(NULL, "icon.ico", IMAGE_CURSOR, 0, 0, LR_LOADFROMFILE); > + ok(handle != NULL, "LoadImage() failed.\n"); > + error = GetLastError(); > + ok(error == 0, "Last error: %u\n", error); > + > + /* Clean up. */ > + ret = DestroyIcon(handle); The fact that LoadImage has returned a not zero handle actually confirms nothing, you need to verify the contents of the loaded image with GetIconInfo. -- Dmitry.

1 0

re: iTunes
by Dan Kegel 18 Feb '08

18 Feb '08

E. Savage wrote: > Maarten why not focus on supporting applications that > don't have viable open source solutions first? iTunes doesn't have any alternatives for these functions: - purchasing songs from iTunes Store - activating iPhone - new ipod/iPhone syncing Anybody who buys an iPhone and can't activate it on their Linux PC will blame Linux and think it's crap. Even developers like jwz, I bet; see http://jwz.livejournal.com/494040.html So yeah, iTunes is important. - Dan

2 1

Winnowing the 1.0 bug list
by Dan Kegel 18 Feb '08

18 Feb '08

We now have about 100 bugs nominated for fixing in 1.0. Thanks to everybody who nominated bugs. Now it's time to winnow the list a bit. 1.0 bugs should be 'important' somehow, easy to reproduce, and have some chance of actually being fixed by, say, summer. The better understood a bug is, the more likely it is it can be fixed for 1.0, so even less important bugs can be 1.0 bugs if they're well enough understood and a patch is available. Here are a few bugs I'm thinking of deferring, and why: Not important enough http://bugs.winehq.org/show_bug.cgi?id=5807 Mercora IMRadio crashes http://bugs.winehq.org/show_bug.cgi?id=6048 Stokes crashes http://bugs.winehq.org/show_bug.cgi?id=8687 everestpoker and Programmer's Editor don't work http://bugs.winehq.org/show_bug.cgi?id=9288 Armed Assault doesn't load web page http://bugs.winehq.org/show_bug.cgi?id=9895 Alzip crashes Probably not doable by summer http://bugs.winehq.org/show_bug.cgi?id=609 Add BiDi support Not well enough understood: http://bugs.winehq.org/show_bug.cgi?id=6383 Dual-core not being correctly supported Do people agree with those assessments, and are there other bugs nominated for 1.0 that don't quite deserve it? - Dan

1 0

← Newer
1
...
13
14
15
16
17
18
19
...
33
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2008