May 2002 - Wine-Devel - list.winehq.org

Re: Problem in winpos.c which ends in a infinite loop

by Christian Costa

> > >>It seems that the app's windows procedure does not expect a >>WM_QUERYNEWPALETTE message. >> >Damn, I faintly remember that I've also had a problem with the >WM_QUERYNEWPALETTE ages ago (about two years ago). >Commenting it out made it go away. > >Sounds like we might want to investigate WM_QUERYNEWPALETTE behaviour... > >>If someone that knows this code well have an idea... >>else I will report this bug to bugzilla. >> >Yep, good idea, since I can confirm suspicions about WM_QUERYNEWPALETTE >brokenness. >(or at least the WM_QUERYNEWPALETTE is playing a role in such a problem >somewhere...) > I've just submitted the bug report. Now you confirm the bug and add some comments.

May 29, 2002

RE: Stripping of whitespaces at the end of lines

by Patrik Stridvall

> Enforcing 'no space before the non-blank char on every line' is > orders of magniture more difficult than 'indentation is 4 space' Is it? find . -name \*.c | xargs perl -ne '/^\s*/ && $& =~ / / && do { print }' compared to find . -name \*.c | xargs perl -ne '!/^(?: )*/ && do { print }' Of course both will fail on Wine style function header comments but then you got what you asked for above. Anyway. I fully agree what you (Dimitrie) that the point of indentation is to make it human readable not easy for tools to verify. In fact I think I agree with almost everything you have said on the subject. So for once we agree. :-)

May 29, 2002

Re: How to fix SizeOfImage when loading a builtin dll ?

by Eric Pouech

> I thought about modifying winebuild to add > > char _end[]; > nt_headers->OptionalHeader.SizeOfImage = pe_header - _end; > > in the library initialisation function. This is small, fast and probably > more accurate. > > Does anyone have any comment about that ? don't you mean extern char _end[] instead ? there's nothing currently which ensures that pe_header is at the start of the code (it relies on the fact it's the first on gcc/ld link option, and that ld allocates slots for compilation units in the order they are expressed) => this may become a porting issue I'm not sure either that _end is completly portable? using this technique (with _start, _etext, _edata, _bss_start, _end) we could also compute the "real" size of code, data, and bss which should be of some interest (even if data would be a bit more difficult, since we need to take care of the rsrc part) beware also that those fields must be aligned on the section boundary (see SectionAlignment in optional header) A+

May 29, 2002

Re: Winehq: Bugzilla responsibilities page

by Andreas Mohr

On Wed, May 29, 2002 at 12:48:07PM -0700, Andriy Palamarchuk wrote: > > - "Talking Back" probably isn't very descriptive. > > I'd add something like "... > > (bugs etc.)" > > - that's Albe*r*telli > > - Application owners play *an* important role in the > > bugs handling process. > > Oops, sorry Guy. > Please fix misspellings or bad English you find. Hehe, ok :-) > > - why add a whole new talkback.inc ? isn't that a > > bit overkill ? > > Bug tracking activities are very close to AppDB > maintaining activities. Both present feedback to Wine > developers and processing of this feedback. The idea > is to have one page to describe both activities. > Users, wanting to provide feedback or help to handle > such feedback will have one page to start from. > Information I want to have on this page: > * link to Bugzilla > * link to AppDB > * link to guidelines for Wine bugs tracking process - > finding, submission, research, fixing, testing. Of > cause these guidelines will have tons of references to > existing documents. > * link to AppDB maintainer guide > > Remove this page if you think this is too much, we can > regroup information later. This sounds *a lot* like what www.winehq.org/about/index.php?contrib already lists. I really don't think adding a sort of "duplicate" page is going to help with the Wine users that already in some cases seem to be going out of their way to make sure that they don't contribute to Wine activities. (because it might even leave those people that do want to do Wine activities confused) My reasoning is: how many external winehq maintainers do we have ? how many main AppDB maintainers ? How many FAQ-O-Matic maintainers ? How many documentation writers ? How many translators ? How many regular application testers ? (Almost) all are tasks that even a non-programmer can easily handle given some dedication... So how should this page conflict be resolved ? I'm open to anything - well, probably except to having two separate pages with some sort of "Wine contribution" content. > Do you have better name? "User Feedback" does not > sound good either. "Getting involved in Wine activities" ? That might be the link to a combined page, at least. > > - why is <li>Bugs Hunting Guide</li> non-functional > > text ? > > FIXME reminder :-) Please remove it. I'd comment it out, then. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

May 29, 2002

Re: SafeDisc-1 semi-cleaned note...

by Laurent Pinchart

> > WinNT Explorer crashes with an access to 07ffe0000 too. > > Well, then we should debug that and implement whatever it needs. We > are never going to have a 100% compatible user shared data anyway, so > there's no point in implementing things unless we know they are > needed. You're right. I still like the idea of a fault handler, but I agree with you :-) Uwe, could you tell me which memory location is accessed exactly (and if possible a short assembly context) ? If WinNT Explorer reads the 32-bit word at 0x7ffe0000 (TickCout) my SafeDisc patch should fix the problem. Laurent Pinchart

May 29, 2002

Re: Winehq: Bugzilla responsibilities page

by Andriy Palamarchuk

--- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > - why did you remove bug tracking link ? I was going to put it on the talkback page. Feel free to return the link to the original position if you do not agree with me. See below. > - "Talking Back" probably isn't very descriptive. > I'd add something like "... > (bugs etc.)" > - that's Albe*r*telli > - Application owners play *an* important role in the > bugs handling process. Oops, sorry Guy. Please fix misspellings or bad English you find. > - why add a whole new talkback.inc ? isn't that a > bit overkill ? Bug tracking activities are very close to AppDB maintaining activities. Both present feedback to Wine developers and processing of this feedback. The idea is to have one page to describe both activities. Users, wanting to provide feedback or help to handle such feedback will have one page to start from. Information I want to have on this page: * link to Bugzilla * link to AppDB * link to guidelines for Wine bugs tracking process - finding, submission, research, fixing, testing. Of cause these guidelines will have tons of references to existing documents. * link to AppDB maintainer guide Remove this page if you think this is too much, we can regroup information later. Do you have better name? "User Feedback" does not sound good either. > - why is <li>Bugs Hunting Guide</li> non-functional > text ? FIXME reminder :-) Please remove it. Andriy __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

May 29, 2002

Re: SafeDisc-1 semi-cleaned note...

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > WinNT Explorer crashes with an access to 07ffe0000 too. Well, then we should debug that and implement whatever it needs. We are never going to have a 100% compatible user shared data anyway, so there's no point in implementing things unless we know they are needed. -- Alexandre Julliard julliard(a)winehq.com

May 29, 2002

Re: Winehq: Bugzilla responsibilities page

by Andreas Mohr

On Wed, May 29, 2002 at 12:06:22PM -0700, Andriy Palamarchuk wrote: > Changelog: > Added bugzilla responsibilities page. Hi, hmm, I'm not 100% sure about this. - why did you remove bug tracking link ? - "Talking Back" probably isn't very descriptive. I'd add something like "... (bugs etc.)" - that's Albe*r*telli - Application owners play *an* important role in the bugs handling process. - why add a whole new talkback.inc ? isn't that a bit overkill ? - why is <li>Bugs Hunting Guide</li> non-functional text ? Wow, questions over questions :-) Good job with bugz_resp.inc, BTW !! Needless to say I'll add this immediately as soon as these questions are covered :) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

May 29, 2002

Re: Problem in winpos.c which ends in a infinite loop

by Andreas Mohr

On Wed, May 29, 2002 at 08:19:01PM +0200, Christian Costa wrote: > Hi everyone, > > I tried to install the game Zork : Grand Inquisitor ( probably a win16 > app) and the installer crashed. > With the debugger, I Obtained the attached log. [...] > It seems that the app's windows procedure does not expect a > WM_QUERYNEWPALETTE message. Damn, I faintly remember that I've also had a problem with the WM_QUERYNEWPALETTE ages ago (about two years ago). Commenting it out made it go away. Sounds like we might want to investigate WM_QUERYNEWPALETTE behaviour... > If someone that knows this code well have an idea... > else I will report this bug to bugzilla. Yep, good idea, since I can confirm suspicions about WM_QUERYNEWPALETTE brokenness. (or at least the WM_QUERYNEWPALETTE is playing a role in such a problem somewhere...) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://mohr.de.tt

May 29, 2002

Re: SafeDisc-1 semi-cleaned note...

by Uwe Bonnes

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> But din't we need sime infrastructure for that page in place anyhow? >> I am quite sure that e.g. WinHelp() in WinNT uses that page. Alexandre> Most of user32.dll in NT uses it, that's how it communicates Alexandre> with the portions of user32 that are in the kernel. But we Alexandre> are not going to run the native NT user32 anyway, and our Alexandre> user32 does things differently. WinNT Explorer crashes with an access to 07ffe0000 too. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

May 29, 2002