January 2009 - Wine-devel - list.winehq.org

Re: gdi32: Implement QueryFontAssocStatus
by ricardo_barbano＠hotmail.com 27 Jan '09

27 Jan '09

i don't know what might be wrong, but in case noone answers you: maybe divide this in much smaller patches? this way you can easily pinpoint areas where the problem is, because the patch is quite big. or you could try pinging julliard by mail or on IRC... regards, ricardo -------------------------------------------------- From: "Byeongsik Jeon" <bsjeon(a)hanmail.net> Sent: Monday, January 26, 2009 11:33 PM To: <wine-devel(a)winehq.org> Subject: Re: gdi32: Implement QueryFontAssocStatus > Again... > What's the problem? > > > 2009-01-20 (Tue), 06:39 +0900, Byeongsik Jeon wrote: >> 2009-01-19 (Mon), 09:40 +0900, Byeongsik Jeon wrote: >> > QueryFontAssocStatus() is the undocumented function. >> > This is a base patch for bug#16325. >> > >> > http://bugs.winehq.org/show_bug.cgi?id=16325 >> > >> Hmm... >> What is the problem of this patch? >> >> >> > --- >> > dlls/gdi32/font.c | 12 +++++++ >> > dlls/gdi32/freetype.c | 66 >> > ++++++++++++++++++++++++++++++++++++++++++ >> > dlls/gdi32/gdi32.spec | 2 +- >> > dlls/gdi32/gdi_private.h | 1 + >> > dlls/gdi32/tests/Makefile.in | 2 +- >> > dlls/gdi32/tests/font.c | 63 >> > ++++++++++++++++++++++++++++++++++++++++ >> > include/wingdi.h | 1 + >> > 7 files changed, 145 insertions(+), 2 deletions(-) >> > >> >> >> >> > > > >

1 0

Re: [PATCH] ddrawex: use stack ctx instead of uninitialized variable
by Austin English 27 Jan '09

27 Jan '09

On Mon, Jan 26, 2009 at 11:06 AM, Marcus Meissner <meissner(a)suse.de> wrote: > --- > dlls/ddrawex/ddraw.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/ddrawex/ddraw.c b/dlls/ddrawex/ddraw.c > index b581529..6607c78 100644 > --- a/dlls/ddrawex/ddraw.c > +++ b/dlls/ddrawex/ddraw.c > @@ -678,11 +678,11 @@ IDirectDraw4Impl_EnumSurfaces(IDirectDraw4 *iface, > LPDDENUMSURFACESCALLBACK2 Callback) > { > IDirectDrawImpl *This = impl_from_dd4(iface); > - struct enumsurfaces4_ctx *ctx; > + struct enumsurfaces4_ctx ctx; > TRACE("(%p)->(0x%08x,%p,%p,%p)\n", This, Flags, DDSD, Context, Callback); > > - ctx->orig_cb = Callback; > - ctx->orig_ctx = Context; > + ctx.orig_cb = Callback; > + ctx.orig_ctx = Context; > return IDirectDraw4Impl_EnumSurfaces(This->parent, Flags, DDSD, &ctx, enum_surfaces_wrapper); > } > > -- > 1.6.0.2 > > > This fixes Coverity 867. Pointing out so that AJ can add that to the patch title, so we can find it in the git log :-). -- -Austin

1 0

Re: [REGRESSION] Fix dlls/iphlpapi/ipstats.c on FreeBSD 6.4/i386
by Austin English 27 Jan '09

27 Jan '09

On Mon, Jan 26, 2009 at 5:43 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > After Austin's recent changes (that were committed in the last 24h), > Wine no longer builds for me on FreeBSD 6.4/i386 with the following > failure mode. > > In file included from ipstats.c:71: > /usr/include/netinet/ip.h:160: error: expected specifier-qualifier-list before 'n_long' > gmake[2]: *** [ipstats.o] Error 1 > gmake[2]: Leaving directory `/sw/test/Wine/dlls/iphlpapi' > gmake[1]: *** [iphlpapi] Error 2 > gmake[1]: Leaving directory `/sw/test/Wine/dlls' > gmake: *** [dlls] Error 2 > > The patch below fixes this. > > Gerald > > ChangeLog: > Move #include <netinet/in_systm.h> before #include <netinet/ip.h> to > fix FreeBSD 6.4. > > Index: dlls/iphlpapi/ipstats.c > =================================================================== > RCS file: /home/wine/wine/dlls/iphlpapi/ipstats.c,v > retrieving revision 1.43 > diff -u -3 -p -r1.43 ipstats.c > --- dlls/iphlpapi/ipstats.c 23 Jan 2009 16:07:29 -0000 1.43 > +++ dlls/iphlpapi/ipstats.c 26 Jan 2009 22:42:34 -0000 > @@ -67,6 +67,9 @@ > #ifdef HAVE_NETINET_IF_INARP_H > #include <netinet/if_inarp.h> > #endif > +#ifdef HAVE_NETINET_IN_SYSTM_H > +#include <netinet/in_systm.h> > +#endif > #ifdef HAVE_NETINET_IP_H > #include <netinet/ip.h> > #endif > @@ -88,9 +91,6 @@ > #ifdef HAVE_NETINET_TCP_VAR_H > #include <netinet/tcp_var.h> > #endif > -#ifdef HAVE_NETINET_IN_SYSTM_H > -#include <netinet/in_systm.h> > -#endif > #ifdef HAVE_NETINET_IP_ICMP_H > #include <netinet/ip_icmp.h> > #endif > I've already sent a patch for this: http://www.winehq.org/pipermail/wine-patches/2009-January/068396.html -- -Austin

1 0

Making the file dialog resizable(implementing OFN_ENABLESIZING)
by Diaa Sami 26 Jan '09

26 Jan '09

Hi, The attached patch fixes the bug at http://bugs.winehq.org/show_bug.cgi?id=10394 , can you have a look at it. It's pretty much done except for some nasty bug and the repainting problem. -- Regards, Diaa Sami

1 1

Re: gdi32: Implement QueryFontAssocStatus
by Byeongsik Jeon 26 Jan '09

26 Jan '09

2009-01-19 (Mon), 09:40 +0900, Byeongsik Jeon wrote: > QueryFontAssocStatus() is the undocumented function. > This is a base patch for bug#16325. > > http://bugs.winehq.org/show_bug.cgi?id=16325 > Hmm... What is the problem of this patch? > --- > dlls/gdi32/font.c | 12 +++++++ > dlls/gdi32/freetype.c | 66 ++++++++++++++++++++++++++++++++++++++++++ > dlls/gdi32/gdi32.spec | 2 +- > dlls/gdi32/gdi_private.h | 1 + > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 63 ++++++++++++++++++++++++++++++++++++++++ > include/wingdi.h | 1 + > 7 files changed, 145 insertions(+), 2 deletions(-) >

1 1

[RFC] msvcrt: Implement _mbcjistojms
by David Hedberg 26 Jan '09

26 Jan '09

Hello, This function is supposed to convert a jis-encoded (Japanese) character to sjis encoding. I think I botched my last attempt up in more than one way so I've now reworked it slightly and thought I'd try again, but perhaps I should first ask if there is anything else obviously wrong with it. For example, the implementation is a bit of a (as far as I can tell working) black box, and the test of it basically tests two different things depending on the codepage, which I am not sure is a good thing. A very insignificant patch perhaps, but all comments are welcome. :) -- David

1 0

Re: Two simple fixes for ListView
by Austin English 26 Jan '09

26 Jan '09

On Mon, Jan 26, 2009 at 4:29 PM, Michael James <james.me(a)gmail.com> wrote: > Here are two simple fixes before I attempt anything more complex here. > > Michael James > > From d978eb3c3eff3b44fce6257892749c2c1c34277d Mon Sep 17 00:00:00 2001 > From: Michael James <james.me(a)gmail.com> > Date: Sun, 25 Jan 2009 20:09:33 -0800 > Subject: [PATCH 1/2] Added logic to eliminate a valgrind warning in > LISTVIEW_GetItemExtT > > The original code used correct but somewhat obscure logic. Added a test to > avoid testing uninitialized pointer for pszText when LVIF_TEXT is not indicated > in the flags. With this change, the code functions identically to what it was > doing before but will not cause a warning from valgrind. > --- > dlls/comctl32/listview.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index 172925f..f28a70e 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -5685,7 +5685,7 @@ static BOOL LISTVIEW_GetItemExtT(const > LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVIte > > pszText = lpLVItem->pszText; > bResult = LISTVIEW_GetItemT(infoPtr, lpLVItem, isW); > - if (bResult && lpLVItem->pszText != pszText) > + if (bResult && (lpLVItem->mask & LVIF_TEXT) && lpLVItem->pszText > != pszText) > textcpynT(pszText, isW, lpLVItem->pszText, isW, lpLVItem->cchTextMax); > lpLVItem->pszText = pszText; > > -- > 1.6.1 > > From 8f05ae1ceca1b787f09ede7e7ab0883ee38c63b9 Mon Sep 17 00:00:00 2001 > From: Michael James <james.me(a)gmail.com> > Date: Sun, 25 Jan 2009 21:09:42 -0800 > Subject: [PATCH 2/2] Defined missing macro ListView_GetCheckState > > --- > include/commctrl.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/commctrl.h b/include/commctrl.h > index 426d70a..9cea03c 100644 > --- a/include/commctrl.h > +++ b/include/commctrl.h > @@ -3715,6 +3715,8 @@ typedef struct NMLVSCROLL > SNDMSGA(hwnd, LVM_SETITEMSTATE, (WPARAM)(UINT)i, (LPARAM) (LPLVITEMA)&_LVi);} > #define ListView_GetItemState(hwnd,i,mask) \ > (BOOL)SNDMSGA((hwnd),LVM_GETITEMSTATE,(WPARAM)(UINT)(i),(LPARAM)(UINT)(mask)) > +#define ListView_GetCheckState(hwnd,i) \ > + ((ListView_GetItemState(hwnd,i,LVIS_STATEIMAGEMASK)>>12)-1) > #define ListView_GetCountPerPage(hwnd) \ > (BOOL)SNDMSGW((hwnd),LVM_GETCOUNTPERPAGE,0,0L) > #define ListView_GetImageList(hwnd,iImageList) \ > -- > 1.6.1 > > > One patch per e-mail please. -- -Austin

1 0

Re: Bugzilla question with respect to .NET 1.1SP1
by James Mckenzie 26 Jan '09

26 Jan '09

Austin English <austinenglish(a)gmail.com> wrote: >Sent: Jan 26, 2009 11:48 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Alexandre Julliard <julliard(a)winehq.org>, Paul Vriens <paul.vriens.wine(a)gmail.com>, "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Bugzilla question with respect to .NET 1.1SP1 > >On Mon, Jan 26, 2009 at 12:34 PM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> Alexandre Julliard <julliard(a)winehq.org> >>>Sent: Jan 26, 2009 7:21 AM >>>To: Paul Vriens <paul.vriens.wine(a)gmail.com> >>>Cc: James Mckenzie <jjmckenzie51(a)earthlink.net>, "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >>>Subject: Re: Bugzilla question with respect to .NET 1.1SP1 >>> >>>Paul Vriens <paul.vriens.wine(a)gmail.com> writes: >>> >>>> So that means bug 14850 needs to be reopened with a link to 13995? >>> >>>No, if it's the same bug it should be a single report. If .NET doesn't >>>install then obviously all apps that try to install it will be broken, >>>it doesn't make sense to create a separate bug for each app that suffers >>>from the problem. >>> >> Actually, I have a different opinion as the reason a program will not install may, at first appearance, be the lack of .NET1.1SP1 but may be another function that Wine does not provide. Paul is 'smart enough' to figure that the problem IS the lack of .NET functionality or the inability to install, but the common user may not. I say, open the bug, mark it as a duplicate of the existing bug and then close it. Add the reporter as a cc to the original bug. When the bug is resolved, then have the user attempt to install the program, if it still fails, reopen the duplicate with whatever does not work now. This keeps the number of bugs down and lets us know how much the lack of functionality affects the Wine user base. Some users complain of being lost in the shuffle because they add to an existing bug that another program is affected. >> >> What do you say about doing this? >> >> James McKenzie >> >> >> >> > >That's messy. Have them cc themselves to the original bug, and when >its fixed, retest. No need to file a bug only to close it immediately >as a duplicate. > I realize it's ugly, but I'm thinking like a software tester not a developer. If I found three bugs in a program, I opened three bugs. If I found the same bug in a different program, I opened a second bug and attached it to the first. >If, however, you're able to workaround that bug, then make a new bug, >and have the second depend on the first. > >E.g., program foo needs native gdiplus and native richedit to install. >File bug for gdiplus problem, then file a second one for richedit, >marking it as depending on the gdiplus bug. What if the richedit bug is fixed first? Would it be impossible to test to see if the bug is fixed? If that were the case, then this is a correct scenario. If the richedit bug can be tested independently of the gdiplus bug, then this scenario is incorrect. If the gdiplug bug depends on the richedit bug being fixed first, then the linkage should be reversed. Linking two separate bugs in this case may not pass the sense test. There has to be an added, simple mechanism where a user (not a developer, or triage) can add to a list of applications affected by a specific bug. See above for what I consider a bug, this is a single application affected by a single problem. Linking together independent bugs needs to be done in a rational manner. If three applications are affected by the same bug, then they either should be linked together, reported under one bug with additional votes for the added applications and users with an updated description, or held as separate bug reports. Sorry to be so long winded about this, but proper bug reporting was and still is my primary business. James McKenzie

2 1

Making the file dialog resizable(implementing OFN_ENABLESIZING)
by Diaa Sami 26 Jan '09

26 Jan '09

Hi, Can you please have a look at the patch at http://bugs.winehq.org/show_bug.cgi?id=10394 ? It's pretty much done except for some nasty bug and the repainting problem. -- Regards, Diaa Sami

1 0

re: advapi32: Fix potential NULL pointer dereference in LookupPrivilegeNameW [with test] (Saturn)
by Dan Kegel 26 Jan '09

26 Jan '09

Cool, I didn't know about Saturn. I've updated http://wiki.winehq.org/StaticAnalysis with info about it. Offhand it looks like neither of these were caught by Coverity...?

1 0