wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

wineps include fix.
by David Hammerton 20 May '01

20 May '01

hey mate.. just got latest CVS of wine (From winehq), it didnt compile, something about not finding "freetype/ftnames.h"... i couldnt find it on my system, in any deb packages, no one had it... so i went hunting, find you left out an 's'.. it should be #include <freetype/ftsnames.h> instead of #include <freetype/ftnames.h> i've cc'd this to "wine-devel"... so yer, if you could fix it, thatd be cool.. but whatever ;p cheers David -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David Hammerton aka crazney Victoria, Australia http://crazney.net/ HOWTO maintainer and Linux Half-Life http://lhl.linuxgames.com/ email: http://crazney.net/contact.html -> Note: this email address expires after one week.

1 0

Re: More breakages
by gerard patel 20 May '01

20 May '01

At 02:38 PM 19/05/2001 +0200, you wrote: >What do you mean? It's there... >http://www.winehq.com/hypermail/wine-cvs/2001/05/0095.html Yes :-/ I should have checked again, I was thinking that because wine-cvs input was generated automatically there could be no reason for data not to be posted to archives immediately. I checked yesterday and it seems that a delay of several hours can happen between a cvs commit and the updating of archives. Gerard

2 1

Re: More breakages
by gerard patel 20 May '01

20 May '01

At 11:07 AM 19/05/2001 +0200, I wrote: (again following up to myself) >But there are other strange crashes that I have not yet investigated Now I have, this change in server/queue.c removes the 3 remaining hangings : --- queue.c.orig Sat May 19 21:06:18 2001 +++ queue.c Sun May 20 09:37:09 2001 @@ -695,7 +695,7 @@ } /* now check for WM_PAINT */ - if (queue->wake_bits & QS_PAINT) + if (((WM_PAINT >= req->get_first) && (WM_PAINT <= req->get_last)) && (queue->wake_bits & QS_PAINT)) { req->type = 0; req->win = 0; @@ -707,6 +707,9 @@ } /* now check for timer */ This check was done in previous code, but I am not completely sure that this is the correct place for this check, though. Now searching for the Acrobat Reader funny scrolling... Gerard

1 0

Re: Small fixes in controls/menu.c
by gerard patel 20 May '01

20 May '01

At 03:33 AM 20/05/2001 +0200, you wrote: >I think it shouldn't generate infinite loops, but my patch could work >improperly when app catches and doesn't pass to defwndproc WM_NCCALCSIZE >message. So I wrote next patch (attached to this e-mail). (patch using NC_HandleNCCalcSize instead of SetWindowPos) IMO it's better and it solves my problem as well. >Any comments,hints ? - you are supposed to send patches against current Wine, not an outdated version - you are supposed to { respect the indentation style of the file you patch; } >When WIN_FindWndPtr(hWnd) return a NULL pointer doesn't it means that >something bad happens ? Yes but I have a hunch that this WARN will be edited out by the Wine maintainer anyway. You'll notice that in similar cases there are never warnings in Wine code; this is not because Wine coders are lazy, it's because the Wine maintainer thinks it's a bad idea to add warnings everywhere. Gerard

1 0

Re: Small fixes in controls/menu.c
by gerard patel 20 May '01

20 May '01

At 03:35 AM 18/05/2001 +0200, you wrote: >Application Super Memo 8 has two modes of functioning. One mulit-document >(using MDI) and the other single-document. <snip> >Second Problem: >Also occurs at switching between modes. >The menu is displayed at improper place (about 10-20 pixels upper than it >should). >I think the problem is in the function MENU_InitTracking in code : <snip one of my patches> My patch is certainly not positioning the menu correctly in the case of your app, and your patch fixes the app I did this patch for all right, but I am wondering if calling SetWindowPos could not generate infinite loops in some cases. Is Super Memo 8 available on the web as a demo app (freely downloable) ? Also vs your ignored patch, I don't know - only Alexandre Julliard is judge and executioner of all that is posted to wine-patches - but in such cases check always if your patch applies; if it does not, either because you did a mistake or the cvs code was changed too much between the creation of your sandbox and the moment he looked at your patch, it could be the reason. Gerard

2 1

Desktop mode
by lawson_whitney＠juno.com 19 May '01

19 May '01

Good day! In case anyone is bored and wants a little bug, Dmitry's little About.exe program will answer neither the keyboard nor the mouse in desktop mode. In any other mode it works fine. Sorry, I didn't notice when it happened, but it has been a while. Lawson ---cut here ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.

1 0

Re: Patch for a bug in server/select.c
by Alexandre Julliard 19 May '01

19 May '01

Bang Jun-Young <bjy(a)mogua.org> writes: > According to the manpage, NetBSD implementation of poll(2) is different > from historical one in that a given fd may not cause poll to return with > an error. I'm not sure if this is the case, however. I'm not sure I understand what they mean in the manpage. Could you write a small test program to determine the exact behavior WRT invalid fds? Particularly interesting would be to determine if poll actually sleeps waiting for something, or if it returns POLLNVAL at once. -- Alexandre Julliard julliard(a)winehq.com

2 1

More breakages
by gerard patel 19 May '01

19 May '01

The patch moving queue management to the server has made about 10 casualties in my toy test suite (btw, why is this patch not appearing on any archive of wine-cvs either Integrita or the winehq one ? I am not suscribed to wine-cvs so I don't know if anyone has received it at all) The simplest problem is : --- timer.c.orig Sat May 19 01:24:04 2001 +++ timer.c Sat May 19 10:04:57 2001 @@ -104,7 +104,7 @@ TIMER * pTimer; HWINDOWPROC winproc = 0; - if (GetWindowThreadProcessId( hwnd, NULL ) != GetCurrentThreadId()) + if (hwnd && (GetWindowThreadProcessId( hwnd, NULL ) != GetCurrentThreadId())) { SetLastError( ERROR_INVALID_WINDOW_HANDLE ); return 0; This fixes ForteFreeAgent dying immediately with a 'no windows timer', Bcb4, and also funny menus problems. I checked GetWindowThreadProcessId under NT and it fails for hwnd=0 so I think that this is the proper fix. But there are other strange crashes that I have not yet investigated, also clicking in the vertical scrollbar in Acrobat Reader scrolls too much. Gerard

2 1

queue management problem
by eric pouech 19 May '01

19 May '01

after last night move of queue management to the server, one of my test app stopped working. What happens is that it's waiting on a WM_TIMER message, but which is no longer triggered. After some investigation, it turned out that message retrieval did change a bit: - in previous code, if the QS_PAINT bit was set, but no window to redraw was found, then the QS_TIMER bit was tested - current code, returns from the server a WM_PAINT message in any case, and if no window can be found, then we retry the whole loop, and we don't check the timer case for my, the wPaintCount was always > 1, meaning that the QS_PAINT bit was never reset then, I investigated why the wPaintCount was > 1. It seems that when a visible window, needing some redraw, is hidden before the update takes place, then we don't update the paint count (which should be decreased) the attached patch does take care of it (basically, if we find a hidden window with an update region, then we destroy the region, and clear the internal paint flag), but I don't think it's the best place to do it. any better idea ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle Index: windows/win.c =================================================================== RCS file: /usr/share/cvs/cvsroot/wine/wine/windows/win.c,v retrieving revision 1.130 diff -u -r1.130 win.c --- windows/win.c 2001/05/18 22:51:57 1.130 +++ windows/win.c 2001/05/19 11:39:54 @@ -367,8 +367,15 @@ { if (!(pWnd->dwStyle & WS_VISIBLE)) { - TRACE("skipping window %04x\n", - pWnd->hwndSelf ); + TRACE("skipping window %04x\n", pWnd->hwndSelf); + if ((pWnd->flags & WIN_INTERNAL_PAINT) || pWnd->hrgnUpdate) + { + if (pWnd->hrgnUpdate) DeleteObject(pWnd->hrgnUpdate); + pWnd->hrgnUpdate = 0; + pWnd->flags &= ~WIN_INTERNAL_PAINT; + QUEUE_DecPaintCount(hQueue); + } + } else if ((pWnd->hmemTaskQ == hQueue) && (pWnd->hrgnUpdate || (pWnd->flags & WIN_INTERNAL_PAINT)))

1 0

Re: Patch for a bug in server/select.c
by Morten Welinder 19 May '01

19 May '01

> +#ifdef __NetBSD__ > + if (pollfd[i].revents & !(pollfd[i].revents & POLLNVAL)) > +#else > if (pollfd[i].revents) > +#endif I would hate to see this kind of __NetBSD__ pollution of Wine. (I believe something like it slipped through recently -- not good.) It used to be that documentation/porting contained lots of reasons why mentioning any OS name in places like this is a bad idea. I suggest a suitable configure test or a porting wrapper for poll. Morten

2 1

Jump to page:

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