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

Autoplay considered harmful
by Dan Kegel Feb. 18, 2008

Feb. 18, 2008

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 Feb. 18, 2008

Feb. 18, 2008

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 Feb. 18, 2008

Feb. 18, 2008

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 Feb. 18, 2008

Feb. 18, 2008

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 Feb. 18, 2008

Feb. 18, 2008

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 Feb. 18, 2008

Feb. 18, 2008

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 Feb. 18, 2008

Feb. 18, 2008

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 Feb. 18, 2008

Feb. 18, 2008

"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 Feb. 18, 2008

Feb. 18, 2008

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 Feb. 17, 2008

Feb. 17, 2008

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

Re: [6/6] wined3d: take alpha from device palette entry for d3d 8 and later
by Stefan Dösinger Feb. 17, 2008

Feb. 17, 2008

Am Montag, 18. Februar 2008 02:37:00 schrieb Alexander Dorofeyev: >/*can ddraw and d3d < 8 surfaces use device's palette (d3d >= 8 feature)?*/ No, they can't, there is no API to access them

2 1

Re: appdb feature request: hide the ugly urls
by Remco Feb. 17, 2008

Feb. 17, 2008

> http://appdb.winehq.org/app/command-conquer-3-tiberium-wars/ > doesn't sound too bad, actually. And if somebody types in > an ambiguous URL, like > http://appdb.winehq.org/app/command-conquer > they should get a list of matching apps. So this is kind of > like a search function rather than a unique ID. > The difference being that apps would normally be > displayed at their shortest unique human-readable URL > rather than by ID #. > This may have an obscure but important benefit: I > read on the web somewhere that it boosts search engine rankings. > (Not that I'd know; I'm way away from that part of google.) > - Dan I'm pretty sure that's just because of the related words in the URL. An additional number doesn't hurt ranking. I know a lot of sites use an ID number and a title. The title makes it easy to see what the link points to. That's a usability benefit of itself. I don't think people should start using the URL bar as a search engine. The AppDB has a nice search engine already. And I think searching for literally all URLs is going to put a lot of strain on the server. Remco ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

2 1

Usable Wine interface
by Remco Feb. 17, 2008

Feb. 17, 2008

I'd like to add a feature-request (should this go somewhereelse?). What about making a Wine GUI to behave more like emulators likeVirtualBox. It's extremely hard right now to get Wine in desktop mode.It would be nice if you could start Wine as an application, which opensup a window like this: http://xs224.xs.to/xs224/08081/mockup918.png (ignore the virtualbox-stuff) And if you start one of those prefixes, it by default opens a WineDesktop with a simple Taskbar & Start-menu. Somewhere in theStart-menu could be the option to switch to desktop integration mode.There could also be an option to run the Wine Desktop full-screen. Likethis: http://xs224.xs.to/xs224/08081/winedesktop771.png (forgive my GIMP skills) I believe this would be very good for usability. Desktop mode is morestable than seamless mode, yet it's hidden in winecfg. This kind of UIalso exposes the prefix-functionality in a transparent way. Wouldn'tthat be a nice 1.0 polishing idea? Remco ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

3 2

Re: Next big app(s) to try?
by Remco Feb. 17, 2008

Feb. 17, 2008

I'd say, of the work-related apps, definitely MS Office 2007 (especially Outlook) and Internet Explorer 6 and 7. IE7 needs a lot of work still. IE6 doesn't break on any Wine bugs AFAIK, but needs a special environment to install correctly. A little Wine magic might help here. IE is one of the few native Windows parts that cannot reasonably be replaced. Web developers need to test their sites in the real thing. Of the fun-related apps, a few press-generating apps would be Crysis DX10-mode and iTunes (iPod sync). Remco ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

2 1

Re: appdb feature request: hide the ugly urls
by Remco Feb. 17, 2008

Feb. 17, 2008

----- Original Message ---- > From: Dan Kegel <dank(a)kegel.com> > To: wine-devel <wine-devel(a)winehq.org> > Sent: Sunday, February 17, 2008 6:55:06 PM > Subject: appdb feature request: hide the ugly urls > > How hard would it be for the appdb to support > more readable URLs for vendors and applications? e.g. > Adobe Premiere is currently at > http://appdb.winehq.org/objectManager.php?sClass=application&iId=128 > but it'd be so slick to see instead > http://appdb.winehq.org/adobe/premiere > > Believe it or not, that little change would make the appdb > less scary for newcomers. > - Dan That's relatively easy to do with mod_rewrite. But it would have to be something like: http://appdb.winehq.org/app/128/adobe-premiere.html All the info is still in the URL (which mod_rewrite can extract), but it does look less scary. Remco ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

4 5

Re: dlls/shell32/pidl.c -- adjust to unsignedness of a type
by Alexandre Julliard Feb. 17, 2008

Feb. 17, 2008

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > @@ -109,7 +109,7 @@ BOOL WINAPI ILGetDisplayNameExW(LPSHELLF > return FALSE; > } > > - if (type >= 0 && type <= 2) > + if (type <= 2) > { > switch (type) > { The test should probably be removed completely since there's already a default for it in the switch() that follows. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [1/6] ddraw: fix executebuffer branching with non-zero offset
by Stefan Dösinger Feb. 17, 2008

Feb. 17, 2008

Am Montag, 18. Februar 2008 02:36:35 schrieb Alexander Dorofeyev: > Fixes a crash in Moto Racer 2. > --- > dlls/ddraw/executebuffer.c | 10 ++++++++-- > 1 files changed, 8 insertions(+), 2 deletions(-) The patches look good to me

1 0

appdb feature request: hide the ugly urls
by Dan Kegel Feb. 17, 2008

Feb. 17, 2008

How hard would it be for the appdb to support more readable URLs for vendors and applications? e.g. Adobe Premiere is currently at http://appdb.winehq.org/objectManager.php?sClass=application&iId=128 but it'd be so slick to see instead http://appdb.winehq.org/adobe/premiere Believe it or not, that little change would make the appdb less scary for newcomers. - Dan

1 0

Re: dlls/msi/streams.c -- simplify and constify
by James Hawkins Feb. 17, 2008

Feb. 17, 2008

On Nov 3, 2007 1:10 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > While removing the dead code I noticed that we can actually also > strengthen the const-ness of this function. > > Gerald > > ChangeLog: > Remove a check which never could trigger (due to the domain of the > variable in question) and increase const-ness of STREAMS_CreateView(). > > Index: dlls/msi/streams.c > =================================================================== > RCS file: /home/wine/wine/dlls/msi/streams.c,v > retrieving revision 1.7 > diff -u -3 -p -r1.7 streams.c > --- dlls/msi/streams.c 18 Oct 2007 13:00:57 -0000 1.7 > +++ dlls/msi/streams.c 3 Nov 2007 18:06:27 -0000 > @@ -430,7 +430,7 @@ static UINT add_streams_to_table(MSISTRE > return count; > } > > -UINT STREAMS_CreateView(MSIDATABASE *db, MSIVIEW **view) > +UINT STREAMS_CreateView(const MSIDATABASE *db, MSIVIEW **view) > { > MSISTREAMSVIEW *sv; > > @@ -444,9 +444,6 @@ UINT STREAMS_CreateView(MSIDATABASE *db, > sv->db = db; > sv->num_rows = add_streams_to_table(sv); > > - if (sv->num_rows < 0) > - return ERROR_FUNCTION_FAILED; > - > *view = (MSIVIEW *)sv; > > return ERROR_SUCCESS; > This change is wrong. If you'd actually read what the code intended to do instead of just fixing warnings, you'd see that add_streams_to_table returns -1 on error. While the check for < 0 is not correct, removing the check entirely is wrong. The check should be if (sv->num_rows == -1) return ERROR_FUNCTION_FAILED. -- James Hawkins

2 2

Re: Autoplay considered harmful
by Remco Feb. 17, 2008

Feb. 17, 2008

Vista (and I think XP too) ask whether you want to start the Autorun program, or do a few other actions (open explorer, copy disk, etc). Remco ----- Original Message ---- > From: Evil Jay <wine(a)eternaldusk.com> > To: Steven Edwards <winehacker(a)gmail.com> > Cc: wine-devel <wine-devel(a)winehq.org>; Dan Kegel <dank(a)kegel.com> > Sent: Saturday, February 16, 2008 5:44:15 PM > Subject: Re: Autoplay considered harmful > > The purist in me says that WINE should not improve on Windows - it > should behave the same way, warts and all. If I had a vote, I'd vote to > enable it by default, but give the user an easy way to disable it in > winecfg. (And I'd immediately disable it the first time I ran Winecfg!) > > But, whatever you guys decide to do is cool - as long as you keep > cranking out this great package! :) > > -Jesse > > > > Steven Edwards wrote: > > On Feb 16, 2008 8:58 AM, Dan Kegel wrote: > > > >> > 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... > >> > > > > I was actually thinking about this today. The right method would be to > > use HAL notification events to prompt the user if they want to autorun > > when sticking a new cdrom in. There could even be warning text in the > > dialog so that if it pops up with other device insertion, the user > > would know that it could be a virus. > > > > > > > > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

5 4

Re: tools: add a wrapper script for starting files from file managers and make wine.desktop use it
by Vincent Povirk Feb. 16, 2008

Feb. 16, 2008

Please do not commit this patch as explained in comment 18 of bug 5224: http://bugs.winehq.org/show_bug.cgi?id=5224#c18 Windows explorer's default behavior is to always start programs with double quotes around their filenames, even if the filename does not contain a space. Apparently, this is impossible (or more difficult than it's worth) to do in a shell script so I will need to rewrite this as a winelib program. On Feb 13, 2008 7:44 PM, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > This is an attempt to solve the problems with double-clicking .exe > files from file managers. > > The patch adds a script named winestartfile that mimics what happens > on windows when a file is double-clicked in explorer. It starts the > file using start.exe with the full path to the file and in the > directory that contains it. > > It also modifies the wine.desktop shortcut to use that script when > opening .exe files. > > My previous attempt at this incorrectly ran start without giving a > full path (so that if a file named start.exe exists in the current > path, it will take precedence) and probably tried to change too many > things at once. > > -- > Vincent Povirk > -- Vincent Povirk

1 0

New winetricks 20080216: fixed comctl32 override, hide winetrickscache, add --version option
by Dan Kegel Feb. 16, 2008

Feb. 16, 2008

Austin nudged me into fixing comctl32 override, which has been broken since wine added support for sxs assemblies. He also was the third person to suggest hiding winetrickscache, so I guess it's what people want. And I added a --version option for a guy who said it would make packaging easier. As always, it's available at http://kegel.com/wine/winetricks and the svn repository is http://code.google.com/p/winezeug/ -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: WineD3D: add separate alpha blend support 3/3
by Stefan Dösinger Feb. 16, 2008

Feb. 16, 2008

Am Samstag, 16. Februar 2008 17:29:31 schrieb Roderick Colenbrander: > Hi, > > This patch adds support for separate alpha blend one of the last > unimplemented D3D9 features. Here are a few suggestions: *) Setting WINED3DPMISCCAPS_SEPARATEALPHABLEND in directx.c should only be done if the extension is supported *) after the "GL_LINE_SMOOTH needs GL_BLEND to work, according to the", WINED3DRS_SEPARATEALPHABLENDENABLE should probably be removed from the if block. I don't think that blending should be enabled if the WINED3DRS_ALPHABLENDENABLE is off. A test would be helpful for certainty. *) The code translating the separate blending settings could be moved into the if(stateblock->renderState[WINED3DRS_SEPARATEALPHABLENDENABLE]) block. That way they are only executed if they're needed(The compiler may take care of that though) *) The separate blend states should be grouped with the alpha states, ie, set the representative to STATE_RENDER(WINED3DRS_ALPHABLENDENABLE) instead of STATE_RENDER(WINED3DRS_SEPARATEALPHABLENDENABLE). Not doing that should not cause any rendering problems because the whole alpha blend states are set every time, but grouping them will improve performance. (e.g., if alphablendenable and separatealphaenable are changed state_blend is only executed once, not twice) *) The blendop is currently not reapplied if WINED3DRS_SEPARATEALPHABLENDENABLE is changed. One solution is to group the blendops with alphablend and move the code from state_blendop to state_blend. A better way is to make this a one-way dependency from state_alpha to state_blend. Compare STATE_RENDER(WINED3DRS_LIGHTING) and STATE_VDECL for a reference.

1 0

X developer's conference, April 16-18
by Dan Kegel Feb. 16, 2008

Feb. 16, 2008

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

3 3

MSG_PEEK race in urlmon_test?
by Francois Gouget Feb. 16, 2008

Feb. 16, 2008

When I run the urlmon_test test the kernel (2.6.22.9) has this to say: Feb 16 05:53:54 amboise kernel: TCP(urlmon_test.exe:9836): Application bug, race in MSG_PEEK. Does anyone know what's up with that? Maybe someone who knows more than me about urlmon? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

1 0

Re: wined3d: Fix bug in swapchain release which causes incorrect display mode changes.
by Chris Robinson Feb. 16, 2008

Feb. 16, 2008

On Saturday 16 February 2008 06:01:48 am Peter Dons Tychsen wrote: > Fixed bug in wined3d swapchain, which caused the release of the > swap-chain to mess around with the display-modes set by ddraw. Also > added test-case for this scenario. Reworked test code minimally, to > re-use existing test code. You may want to test D3D8 and D3D9 too, to see what they do when presented by the situation (since the code is shared). Also I don't think you should make those 2-space indents just to avoid changing those few lines.

1 0

Re: winedos: Allocate a console when loading dos applications
by Maarten Lankhorst Feb. 16, 2008

Feb. 16, 2008

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.

2 1

Re: d3dx9 patches
by tony.wasserka＠freenet.de Feb. 16, 2008

Feb. 16, 2008

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…

1 0

re: gecko download not robust?
by marco Feb. 15, 2008

Feb. 15, 2008

> > Hmm. gecko download hung for me once. I saw > fixme:urlmon:ProtocolStream_Read Read failed: 800c0008 > in the log, which makes me wonder if our download code > doesn't handle transient network errors well. > > Time to get rid of the download, and just bundle gecko outright, I say... I make the mandriva rpms for wine. This would make the rpms 30% bigger. And you would download the same gecko binary over and over again with every new version. But if that is not a problem than it can be easily done.

7 12

[PATCH] msvcrt: Fix scanf floating-point exponent handling.
by Jānis Rūcis Feb. 15, 2008

Feb. 15, 2008

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

1 0

d3dx9 patches
by tony.wasserka＠freenet.de Feb. 15, 2008

Feb. 15, 2008

Hi, It's nearly two weeks ago that I sent those patches, so I was curious if there are any problems with it? 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

2 1

Windows Mobile API
by Arthur Maciel Feb. 15, 2008

Feb. 15, 2008

Hi there. I´m not part of the mailing list, but I really want to know if there is any port of WINE to support Windows Mobile API (that is Windows for pocket pc, handhelds and pocket phones). This would come as a great solution for me, as I need specific WM programs on my pda. I really appreciate any help and information. Regards, Arthur

2 3

Google's support for Wine in 2007
by Dan Kegel Feb. 15, 2008

Feb. 15, 2008

As you might know, I work for Google, and part of my day job is to help improve Wine. Here's a little report about what we've been up to. Google uses Wine primarily as the basis for the Linux port of our photo management software, Picasa. In fact, the Linux version is exactly the Windows build of Picasa, bundled with a lightly patched version of Wine. Most of the work in that port was to improve Wine so it could handle Picasa, and that work is still going on. Codeweavers did the initial port, and Googlers Lei Zhang, Nigel Liang, and Michael Moss are improving Wine further for Picasa 2.7. Beyond Picasa, a few of us (Lei Zhang, Alex Balut, and I) have been fixing random Wine bugs in our 20% time. I've also been doing regular Valgrind runs over the Wine test suite, pestering developers who accidentally check in code that Valgrind doesn't like. Hats off to the Valgrind team for a great tool, and to the (non-Google) folks who work on Valgrind/Wine compatibility (Eric Pouech, Tom Hughes, and John Reiser, among others). Google also sponsored some work by Codeweavers to improve support for Photoshop ('cause so many people want it) and for Dragon Naturally Speaking ('cause even Linux users get RSI). While not yet perfect, those apps are a lot more usable now as a result. In particular, Photoshop CS and CS2 are quite usable indeed. (See http://wiki.winehq.org/AdobePhotoshop for details.) I also had the pleasure of hosting eight students as Google interns working on Wine throughout the year. Here are their names, and roughly what they worked on: Dan Hipschman: widl Evan Stade: gdiplus, Powerpoint Viewer James Hawkins: msi Jennifer Lai: win16 conformance tests Juan Lang: crypt32, iTunes Matt Jones: mono testing Mikolaj Zalewski: Photoshop, Limux Roy Shea: svchost, BITS So, you're wondering, what exactly does that all boil down to? I tallied all our accepted patches recently; the list is now up (along with the exact Wine source we use for Picasa) at http://code.google.com/opensource/wine.html I was pleasantly surprised at the size of the list. Separately, Google also sponsored nine Summer of Code students this year. Just to name two who remain active even after the end of summer: Alex Sørnes, who improved Wine's Wordpad, and Maarten Lankhorst, who solved tons of sound problems. (And oh, how nice it is to not have to change sound settings anymore!) All that may sound like a lot, and perhaps it is, but it pales compared to the work put in on Wine by the rest of the Wine developers. Thanks, everybody! I'm really looking forward to Wine 1.0 (which, according to Alexandre, is planned for sometime in 2008). Dan Kegel Software Engineer Google

5 6

Re: [PATCH] winex11.drv: get hwnd for injected mouse events
by Alexandre Julliard Feb. 15, 2008

Feb. 15, 2008

"Lei Zhang" <thestig(a)google.com> writes: > --- a/dlls/winex11.drv/mouse.c > +++ b/dlls/winex11.drv/mouse.c > @@ -278,6 +278,7 @@ void X11DRV_send_mouse_input( HWND hwnd, DWORD flags, DWORD x, DWORD y, > { > pt.x = (x * screen_width) >> 16; > pt.y = (y * screen_height) >> 16; > + hwnd = GetAncestor(WindowFromPoint(pt), GA_PARENT); This should not be needed, for injected events the window is determined on the server side. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: systray [4/4]: implement systray transparency
by Kirill K. Smirnov Feb. 15, 2008

Feb. 15, 2008

> We don't want to export such a specific function. Besides, it should > really be setting the window shape. I've just understood why we cannot rely upon setting window shape to get transparency. Let's consider almost empty icon or even empty - this may happen when application "flashes" icon, e.g. on incoming ICQ message. 1) Can be there active windows with empty visible area? 2) This windows do not correctly relay mouse events. -- Kirill

1 0

Re: systray [4/4]: implement systray transparency
by Kirill K. Smirnov Feb. 15, 2008

Feb. 15, 2008

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > > diff --git a/dlls/winex11.drv/winex11.drv.spec > > b/dlls/winex11.drv/winex11.drv.spec index 36b83d7..126cbc5 100644 > > --- a/dlls/winex11.drv/winex11.drv.spec > > +++ b/dlls/winex11.drv/winex11.drv.spec > > @@ -130,6 +130,7 @@ # Desktop > > > > # System tray > > @ cdecl wine_make_systray_window(long) X11DRV_make_systray_window > > +@ cdecl wine_systray_window_clear(long) X11DRV_systray_window_clear > > We don't want to export such a specific function. Besides, it should > really be setting the window shape. Do I understand you correct that we should cut off transparent parts of icon, thus making window shape to match solid part of icon? Taking into account that almost every xembed-systray-aware application uses ParentRelative attribute (and KDE developers assumes this as I noticed at bug #3534), the idea of changing window shape sounds really strange. 1) Is there any strong reason why we really must change windows shape to achieve visual transparency? 2) Will it be better to stop embedding wine windows in favor of embedding pure X windows (like other apps do)? This way assumes implementing all xembed-specific stuff at winex11.drv side and exporting ONLY ONE function like wine_xembed_systray_handler(int cmd, void *data), which converts windows icon to X11 icon, creates X11 window with ParentRelative bkgrnd and embeds it. Explorer will use this function when it adds/removes icon to/from system tray. Also, this function will detect the case of wine virtual desktop and notify explorer to stop using xembed. I'm just not sure that this way will not break relaying mouse events. -- Kirill

2 1

Re: shell32: Fix character count passed into lstrcpnA in SHGetDataFromIDListA.
by Francois Gouget Feb. 15, 2008

Feb. 15, 2008

if (shortname) - lstrcpynA(pfd->cAlternateFileName, shortname, MAX_PATH); + lstrcpynA(pfd->cAlternateFileName, shortname, 14); sizeof(*pfd->cAlternateFileName) would be better than the magic 14 here. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

1 1

Re: Don't use GetExceptionCode and GetExceptionInformation in exception filter functions.
by Alexandre Julliard Feb. 15, 2008

Feb. 15, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > Alternatively, we could get rid of the WINE_EXCEPTION_FILTER and > WINE_FINALLY_FUNC functions and make users of __EXCEPT and __FINALLY > declare the functions themselves and access the exception data > directly without use of macros. That would be better, the macros only make sense if we can use the standard ones. If we have to use a Wine-specific approach anyway then the macros are just making it harder to see what's going on. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ddraw / wined3d fighting over the resolution!
by Peter Dons Tychsen Feb. 15, 2008

Feb. 15, 2008

On Thu, 2008-02-14 at 09:18 +0100, Stefan Dösinger wrote: > Am Donnerstag, 14. Februar 2008 04:22:16 schrieb Peter Dons Tychsen: > > Why does the SwapChain-destroy function play around with the resolution > > at all. Is that really necessary? I think it should not do it if the > > caller is ddraw at least. > I thought I'm filtering this out in the case of ddraw, but maybe that got > lost. The reason why the swapchain restores the resolution is the different > way ddraw/d3d8 and d3d8/d3d9 set up the screen. > > In ddraw the app calls IDirectDraw7::SetDisplayMode. This sets the mode. Then > it creates a DDSCAPS_PRIMARYSURFACE surface, which creates the swapchain. > > In d3d8/d3d9 the swapchain controls the video mode > > I think the problem is that RestoreDisplayMode is called before the primary > surface is destroyed. The question is why this happens. I can think of the > following reasons: > > -> Refcounting problem, or the app just doesn't release the surfaces. Then > ddraw.dll destroys the objects on DLL_PROCESS_DETACH > > -> The app calls it that way. This needs a test, but I think it is not allowed > to call SetDisplayMode / RestoreDisplayMode while a primary surface is around OK, i have now eaten enough wine-gums to comprehend this.... I think there is a general problem in swapchain->release. The swapchain should only change the resolution back to the original *if* the current resolution is still the same as the swapchain enforced. If someone else has intervened, it should let it be. This fixes the problem at hand, but would also fix other silly problems. Some could for example have called Release() while the "window" is not even visible (tabbed to desktop for example). Please review my patch and let med know if it is submittable. If you hate it, i will eat more wine-gums. :-) /pedro

2 1

What's up with GetPrivateProfileString?
by Johan Gill Feb. 15, 2008

Feb. 15, 2008

http://bugs.winehq.org/show_bug.cgi?id=5424 The bug above is causing me some confusion regarding how GetPrivateProfileString should behave. Wine looks for maxis.ini in C:\Windows, and does not find it there. Therefore, Setup.exe exits. MSDN claims that if an absolute path is not provided, the windows directory is searched for the file. There are also some registry things to take into account, but maxis.ini should not be referenced in the registry since it is located on a CD-ROM and read before the autorun screen is shown. It seems very likely that GetPrivateProfileString on real Windows with just a filename as path argument looks in the current directory, but it would be nice if someone with a real Windows installation would check that. I can have a try at writing the test source if necessary.

1 0

Re: include: Fix the C_ASSERT macro to not generate an unused variable warning when compiling with gcc.
by Alexandre Julliard Feb. 15, 2008

Feb. 15, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > @@ -279,10 +279,10 @@ extern "C" { > > /* Compile time assertion */ > > -#if defined(_MSC_VER) > +#if defined(_MSC_VER) || defined(__GNUC__) > # define C_ASSERT(e) typedef char __C_ASSERT__[(e)?1:-1] > -#elif defined(__GNUC__) > -# define C_ASSERT(e) extern char __C_ASSERT__[(e)?1:-1] > +#else > +# define C_ASSERT(e) This will break if you do two C_ASSERTs in the same scope. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] Add IRunnableTask interface (resend)
by Alexandre Julliard Feb. 15, 2008

Feb. 15, 2008

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > I have no idea why it wasn't applied, so this is a resend with no modifications. It should go in shobjidl.idl. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: systray [4/4]: implement systray transparency
by Alexandre Julliard Feb. 15, 2008

Feb. 15, 2008

"Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > diff --git a/dlls/winex11.drv/winex11.drv.spec b/dlls/winex11.drv/winex11.drv.spec > index 36b83d7..126cbc5 100644 > --- a/dlls/winex11.drv/winex11.drv.spec > +++ b/dlls/winex11.drv/winex11.drv.spec > @@ -130,6 +130,7 @@ # Desktop > > # System tray > @ cdecl wine_make_systray_window(long) X11DRV_make_systray_window > +@ cdecl wine_systray_window_clear(long) X11DRV_systray_window_clear We don't want to export such a specific function. Besides, it should really be setting the window shape. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winedos: Allocate a console when loading dos applications
by Dmitry Timoshkov Feb. 14, 2008

Feb. 14, 2008

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> wrote: > Fixes bug 9178. > > I was looking hard at it, then I had to laugh, hard, when I found this > simple fix. This patch is not correct, think for instance of all win16 applications. -- Dmitry.

1 0

re: Fixing the last failing tests
by Dan Kegel Feb. 14, 2008

Feb. 14, 2008

Maarten wrote: > An example is IsWindowUnicode. It always returns TRUE on XP, but it > won't do that on 9x. That would mean something like: > ok(IsWindowUnicode() || !IsWindowUnicode(), "How can this fail?"); Maybe you can do something like if (CreateWindowExW doesn't work) { /* win95 without MSLU */ ok(!IsWindowUnicode()); } else { /* win95 with MSLU, or something with native unicode support */ ok(IsWindowUnicode()); }

2 3

[RFC] winecfg enhancements
by Reece Dunn Feb. 14, 2008

Feb. 14, 2008

Hi, I am looking at how we can make winecfg more useful. I have already supplied patches to allow importing a ubuntu human theme to work :). So I am now looking at how to build on that. On the Desktop Integration tab, I am planning on adding the following improvements: * Split the Appearance section into Theme and Appearance. The rationale behind this is while the two are linked, they are also distinct. It will make it possible to simplify "Install theme..." to just "Install...", and support enhancements below. * Pre-populate the Theme list with themes in WINDOWS/Resources/Themes and with other *.theme files added by the user. The rationale behind this is that it simplifies the workflow for the average usage (e.g. install a theme, then select it). * Rename "Install theme..." to "Add...". The rationale is that we are not installing a theme, but setting it as the theme being used. Having the theme appear in the Themes list in the future further supports this name change and workflow. * Rename "(No Theme)" to "Wine Default". The rationale behind this is that it isn't true that there is no theme installed (in the sense that a theme can be a set of colours and metrics). * Provide an "Export..." button to the Themes section. The rationale behind this is that it makes it easier to create, modify and preview themes being created. Therefore, you could create a Ubuntu Human or Oxygen theme from winecfg. * Make the theme importer read the themes [Theme]/DisplayName property. The rationale behind this is to make the display name user friendly. * Add --import-theme command line support to winecfg. The rationale behind this is to support loading a theme via a script (e.g. post-install configuration), without resorting to the winecfg GUI. * Make the shell folders a drop down list. The rationale behind this is that it is unclear what "link to" applies to. An alternative is to make the listview have the showselalways flag, so it is clearer what folder "link to" is relating to. Q: Should we provide a --simple mode for winecfg that has the work flow that Ubuntu is planning? Not specifying --simple would bring up the standard winecfg dialog. - Reece

8 10

Re: mscms: [GS]etColorSpace() are not supposed to be defined in icm.h.
by Detlef Riekenberg Feb. 14, 2008

Feb. 14, 2008

On Mi, 2008-02-13 at 21:52 +0100, Francois Gouget wrote: > diff --git a/include/icm.h b/include/icm.h The end of the attached Patchfile is broken: > &#;& -- By by ... Detlef

2 1

gecko valgrind errors show up better now
by Dan Kegel Feb. 14, 2008

Feb. 14, 2008

The new version of valgrind shows better stack dumps for gecko valgrind errors. For instance, Invalid read of size 4 at (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/components/xppref32.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by load_gecko (nsembed.c:396) by NSContainer_Create (nsembed.c:1574) by HTMLDocument_Create (htmldoc.c:1232) by ClassFactory_CreateInstance (main.c:206) by CoCreateInstance (compobj.c:2411) by report_data (binding.c:444) by report_data_proc (binding.c:1262) Address 0x7f22e1e0 is not stack'd, malloc'd or (recently) free'd Invalid read of size 4 at (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by load_gecko (nsembed.c:338) by NSContainer_Create (nsembed.c:1574) by HTMLDocument_Create (htmldoc.c:1232) by ClassFactory_CreateInstance (main.c:206) by CoCreateInstance (compobj.c:2411) by report_data (binding.c:444) by report_data_proc (binding.c:1262) by notif_wnd_proc (binding.c:184) Address 0x7f22e108 is not stack'd, malloc'd or (recently) free'd Conditional jump or move depends on uninitialised value(s) at (within 0.1.0/wine_gecko/components/necko.dll) by nsURI_QueryInterface (nsio.c:1181) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by (within 0.1.0/wine_gecko/components/necko.dll) by nsIOService_NewChannelFromURI (nsio.c:2111) by (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/rdf.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/components/chrome.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by load_gecko (nsembed.c:338) Invalid read of size 4 at (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/xpc3250.dll) by (within 0.1.0/wine_gecko/components/xpc3250.dll) by (within 0.1.0/wine_gecko/components/xpc3250.dll) by (within 0.1.0/wine_gecko/components/xpc3250.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/xpcom_core.dll) by (within 0.1.0/wine_gecko/components/profile.dll) by load_gecko (nsembed.c:338) by NSContainer_Create (nsembed.c:1574) by HTMLDocument_Create (htmldoc.c:1232) by ClassFactory_CreateInstance (main.c:206) by CoCreateInstance (compobj.c:2411) by report_data (binding.c:444) by report_data_proc (binding.c:1262) by notif_wnd_proc (binding.c:184) by (within /home/dank/wine-git/dlls/user32/user32.dll.so) Address 0x7f22d1a8 is not stack'd, malloc'd or (recently) free'd etc., etc. Jacek, if you can give me a debug build of gecko, I can probably give you even better info. Interested? - Dan

2 1

Re: ddraw / wined3d fighting over the resolution!
by Peter Dons Tychsen Feb. 14, 2008

Feb. 14, 2008

Hello S. I have studied this a bit more. The app seems to do this purposely. In any case wined3d should not change the mode in this case. Either wined3d must detect this, or the code should be moved into d3d8/d3d9. On a similar note, i found i found a funny "RestoreDisplayMode()" call in "SetCooperateLevel()", when switching from full-screen. I tested with win-xp, and here this does not happen. This causes additional mode-switch flicker. I think i will chew on some nice German wine-gums (Haribo), and then send some patches :-). mmmmmm.... wine-gums.... they should sell them on wine.org... would be appropriate... :-) /p On Thu, 2008-02-14 at 09:18 +0100, Stefan Dösinger wrote: > Am Donnerstag, 14. Februar 2008 04:22:16 schrieb Peter Dons Tychsen: > > Why does the SwapChain-destroy function play around with the resolution > > at all. Is that really necessary? I think it should not do it if the > > caller is ddraw at least. > I thought I'm filtering this out in the case of ddraw, but maybe that got > lost. The reason why the swapchain restores the resolution is the different > way ddraw/d3d8 and d3d8/d3d9 set up the screen. > > In ddraw the app calls IDirectDraw7::SetDisplayMode. This sets the mode. Then > it creates a DDSCAPS_PRIMARYSURFACE surface, which creates the swapchain. > > In d3d8/d3d9 the swapchain controls the video mode > > I think the problem is that RestoreDisplayMode is called before the primary > surface is destroyed. The question is why this happens. I can think of the > following reasons: > > -> Refcounting problem, or the app just doesn't release the surfaces. Then > ddraw.dll destroys the objects on DLL_PROCESS_DETACH > > -> The app calls it that way. This needs a test, but I think it is not allowed > to call SetDisplayMode / RestoreDisplayMode while a primary surface is around

1 0

Re: Weird failure in kernel32 volume test
by Maarten Lankhorst Feb. 14, 2008

Feb. 14, 2008

Hi Jeremy, 2008/2/14, Jeremy White <jwhite(a)winehq.org>: > Anyone else has some tests that consistently fail on make test? > > > As of last nights git tip, I still had four failures: > > http://test.winehq.org/data/20080213/#Wine I submitted a patch for the comm test. I'm not 100% sure about the shelllink test. On that site there is also a failure for 'volume' which I experienced as well. I have really no idea what causes it though, but it looks like aj has done some work on it. Maybe you have any idea alexandre? Cheers, Maarten.

1 0