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

Re: [1/3] comctl32: Do not call parent of tool window for tip text

by Ann & Jason Edmeades

Hi Alexander, > In the process of debugging I > also determined that Windows doesn't seem to send this message to > parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1 > normal installation). So I'm deleting this second call altogether and > a conformance test for this situation will be included in the next > patch. > Under some circumstances, it must - see bug 9233 (and my patch at url below) http://www.winehq.org/pipermail/wine-patches/2007-August/042660.html http://www.winehq.org/pipermail/wine-cvs/2007-August/035236.html I debugged this through to the point where the parent was definitely retrieving the information (I watched spy logs of the application in question) and I believe reversing this patch will break radmin again... It's a free download, can you please test you havent regressed that application with the patch Jason

Oct. 28, 2007

Re: tools/widl/typegen.c pointer initialization

by Dan Hipschman

On Sun, Oct 28, 2007 at 01:51:34PM +0100, Gerald Pfeifer wrote: > In tools/widl/typegen.c we have the following snippet > > static void write_user_tfs(FILE *file, type_t *type, unsigned int *tafsoff) > { > unsigned int start, absoff, flags; > unsigned int align = 0, ualign = 0; > const char *name; > type_t *utype = get_user_type(type, &name); > > which passes name to get_user_type without initializing it. get_user_type > in return has the following piece of code: > > static type_t *get_user_type(const type_t *t, const char **pname) > { > for (;;) > { > type_t *ut = get_attrp(t->attrs, ATTR_WIREMARSHAL); > if (ut) > { > if (pname) > *pname = t->name; > return ut; > } > > It is unclear to this reader (and various versions of GCC I tested), > whether we don't really use *name (*pname) uninitialized here. Now > it is possible that through some of the, hmm, tricky logic in these > two functions combined with some environmental guarantees it happens > that we don't, but it seems better to be proactive here. The logic is as follows: We wouldn't be in write_user_tfs if the predicate is_user_type wasn't true for that type, which means *pname (name) will always be initialized since it gets set precisely when get_user_type returns non-NULL (which is the is_user_type test). I don't think initializing it to NULL is helpful since it would crash just the same as if it weren't initialized. name *must* have a valid (non-NULL) value. This may silence a warning, but it's making the logic of the code more confusing by setting the variable to a value that doesn't make any sense in that context. get_user_type is the initialization. Better than this would be to put "assert(is_user_type(type));" above the initializations to convince the programmer at least that name will get initialized correctly in get_user_type. If that doesn't convince the compiler then I don't think it's worth it to try to placate it since we're supposed to be wrting code for humans, not computers. Some projects use a macro like "name IF_LINT(= NULL);" to quiet warnings while informing the reader that the initialization is not necessary. I suppose that's slightly better as well. I think the real problem is that the code is just not clear enough. I've been meaning to add asserts. Where asserts are impractical: comments.

Oct. 28, 2007

Re: Make test drill, next steps, call for help with Winetest

by Detlef Riekenberg

On Sa, 2007-10-27 at 14:03 +0200, Francois Gouget wrote: > > Things still on the todo list: > * the script also grabs the winetest.exe signature and attempts to > verify it. But I don't know where to find the corresponding public > key > (651FD487) so I don't know if this really works. Paul's homepage: http://www.astro.gla.ac.uk/users/paulm/ $ gpg --list-keys paulm pub 1024D/BF0F03E9 2000-11-07 uid Paul Millar (Physics & Astronomy) sub 1024g/1034BACC 2000-11-07 pub 1024D/651FD487 2002-05-11 uid quisquiliae (automatic program for testing WINE) sub 1024g/420F3FE4 2002-05-11 (The email-address was stripped) My script loads the signature and verify the winetest-latest.exe. When gpg failed to verify the binary, a new winetest is available. The new binary is downloaded and checked again. When the check was ok, the winetest-lastest is copied to the destination and qemu is started for every image. To bad, that qemu 0.9.0 crash on "ntdll_text.exe exception" ... -- By by ... Detlef

Oct. 28, 2007

Re: Lots of 'make test' failures on Windows

by Reece Dunn

On 27/10/2007, Jakob Eriksson <jakob(a)vmlinux.org> wrote: > Francois Gouget wrote: > > > > And I have recently put together a script for running winetest in > > VMware virtual machines unattended (see my other post). So going > > forward I will be running it on Windows 98, Windows XP and Windows > > 2003 nightly. > > > > > This is soooo good. test.winehq.org will became several times more > useful than before. > A consistent track record from the same installations of Windows. I agree. It would be even better if the tests were also run on real machines, as that would catch which test failures are VM related (such as the Direct3D tests). - Reece

Oct. 28, 2007

Re: ddraw: allow explicit backbuffer

by Stefan Dösinger

Am Sonntag, 28. Oktober 2007 01:18:53 schrieb EA Durbin: > based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game > combat pillows to launch There is a test in the ddraw tests that shows that this is not allowed. This test will break I guess. However, maybe it is a version differece. The test tests IDirectDraw7 I think, maybe the game uses an older version.

Oct. 28, 2007

Re: ddraw: allow explicit backbuffer

by Marcus Meissner

On Sat, Oct 27, 2007 at 06:18:53PM -0500, EA Durbin wrote: > > based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game combat pillows to launch > > _________________________________________________________________ > Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct > From d6c94c504f555f773c2c90d7fcbd4bf3500fe490 Mon Sep 17 00:00:00 2001 > From: EA Durbin <ead1234(a)hotmail.com> > Date: Sat, 27 Oct 2007 18:16:27 -0500 > Subject: ddraw: allow explicit backbuffer, based on a patch by Jaroslav Reznik > > --- > dlls/ddraw/ddraw.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c > index 7785624..a84fc36 100644 > --- a/dlls/ddraw/ddraw.c > +++ b/dlls/ddraw/ddraw.c > @@ -2283,7 +2283,7 @@ IDirectDrawImpl_CreateSurface(IDirectDraw7 *iface, > return DDERR_NOEXCLUSIVEMODE; > } > > - if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER | DDSCAPS_BACKBUFFER)) { > + if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER || DDSCAPS_BACKBUFFER)) { This is wrong. You changed a logical OR into a boolean OR and the bitmask will no longer work... Something else needs to be changed, like removing either the DDSCAPS_BACKBUFFER part or the FRONTBUFFER part of the |. Ciao, Marcus

Oct. 28, 2007

Re: implement FatalExitHook()

by Maarten Lankhorst

EA Durbin schreef: > ----------------------------------------> Date: Sun, 28 Oct 2007 01:13:54 +0200> From: m.b.lankhorst(a)gmail.com> To: ead1234(a)hotmail.com> CC: wine-devel(a)winehq.org> Subject: Re: implement FatalExitHook()>> Hi EA,>> I can find absolutely no info on FatalExitHook, are you sure it's> supposed to exit the process, rather then making the argument be called> in case of exit?>> Cheers,> Maarten. > > I couldn't find much info on it either, except it's a stub in the krn386.exe. Age of empires 2 throws up an unimplimented function krn386.exe.FatalExitHook error after it crashes due to bug 9925, and this makes that error go away. I'm not sure if it's correct due to the lack of documentation for this function. > The easiest way to figure it out, is by creating a small test program.. Something along the lines of: void CALLBACK trigger(int test) { printf("Triggered: %d\n"); } int main() { FatalExitHook(&trigger); printf("Still alive..\n"); FatalExit(0); printf("Alive?!\n"); return 1; } Regards, Maarten.

Oct. 28, 2007

SHChangeNotify()

by Francois Gouget

shlwapi.spec exports SHChangeNotify. However I see no implementation of this function in shlwapi. There is an SHChangeNotifyWrap() function however. Weirder still, SHChangeNotifyWrap() does not seem to be called anywhere, is not exported by shlwapi.spec, and calls SHChangeNotify(). So I'm confused as to how this is supposed to work. Could you clarify things for me? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Oct. 28, 2007

RE: implement FatalExitHook()

by EA Durbin

----------------------------------------> Date: Sun, 28 Oct 2007 01:13:54 +0200> From: m.b.lankhorst(a)gmail.com> To: ead1234(a)hotmail.com> CC: wine-devel(a)winehq.org> Subject: Re: implement FatalExitHook()>> Hi EA,>> I can find absolutely no info on FatalExitHook, are you sure it's> supposed to exit the process, rather then making the argument be called> in case of exit?>> Cheers,> Maarten. I couldn't find much info on it either, except it's a stub in the krn386.exe. Age of empires 2 throws up an unimplimented function krn386.exe.FatalExitHook error after it crashes due to bug 9925, and this makes that error go away. I'm not sure if it's correct due to the lack of documentation for this function. _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctW…

Oct. 27, 2007

Re: implement FatalExitHook()

by Maarten Lankhorst

Hi EA, I can find absolutely no info on FatalExitHook, are you sure it's supposed to exit the process, rather then making the argument be called in case of exit? Cheers, Maarten.

Oct. 27, 2007