wine-devel May 2009

wine-devel@winehq.org

128 participants
234 discussions

RE: Severity levels
by Nicklas Börjesson 08 May '09

08 May '09

Hi all, it seems that some of my earlier mails(and some other) has been re-mailed to the list. I don't think that our(here, at my workplace) servers has done this, rather, it feels like the mailing list server did it. So understand that I am not bombarding the list. I see that many are replying to some really old posts. //Nicklas

1 0

Severity levels
by Nicklas Börjesson 08 May '09

08 May '09

Hi all! First, I couldn't find any list more suitable than this one to comment the severity levels in the bug reporting so I post it here. If this was a really bad thing to do, please tell me were to do so. Secondly, don't take this wrong, I am not here to preach, I actually think this is a serious problem. I am not drunk either. Currently. :-) So, with regards to severity levels: Current severity levels are perfect for server applications where everything is simply about functionality working or not working. However, the overwhelming majority of windows applications in general, and those being ported through wine in particular are GUI-based, end-user applications. When it comes to these kinds of applications, in front of which actual people sit for hours on end doing actual work, other factors come into play. So I would like to introduce a bold new weight into the severity assessment: The user experience. Or at least the bugs' negative impact on it. The user experience(UE from here on) is really quite impossible to quantify exactly, luckily that is not usually necessary. There are several reasons to incorporate this into the severity classification, but I'll stop at two: 1. The ones reporting the bugs will come across with how severe they think the bug is to them. Currently, there is far too much of "you've got a almost black screen or black square instead of icons running Photoshop?..hmm that's really trivial...an 'UI glitch', but OK then, I'll mark it minor to be nice to ya." To a user, even an advanced one, this must feel like talking to a condescending Martian. Frustrating, if not infuriating. Likely, they will never again take the time to make a bug report. It is even quite likely that they will give up their move away from windows. 2. Currently, fixing a "trivial" UE-bug can make way more users happy than fixing a "normal" functionality-bug. This means that bug fixing is prioritized on a basis other than catering to the users needs. And to me, that's something that really shows. Can one defend this without invalidating the wine project? It is a serious question, I might have missed something fundamental. Anyway, I have some ideas on how to make the severity classifications better(and more intuitive for the mere user), but I won't go in to that now. I just want to know if any of you agree with me. Do I make a valid point? //Nicklas PS. I repost this since I didn't get any post from the server the first time. Also I expect this post to piss some off, which makes it even stranger not to get any replies at all. BTW, I also just read in a comment in a bug report that the severity flag doesn't mean much at all when it comes to how a bug is prioritized. So the only input the users have on how important a bug is to them is practically ignored? Why have that checkbox then? And why make such a big thing of it not being correctly set? DS.

10 55

msvcrt crash issue, tracing
by Kjell Rune Skaaraas 07 May '09

07 May '09

Hello, I've been working for some time now trying to resolve bug 15817 because it's a kickass game that apart from one crashing issue works great under wine. The situation in brief is that it works with a msvcrt.dll override, but crashes randomly and sometimes consistantly using wine's stub. Now, when I run it with trace+msvcrt, it always crashes right after attaching a new thread: trace:msvcrt:MSVCRT_operator_delete (0x8edfda0) trace:msvcrt:DllMain (0x7e510000, DLL_THREAD_ATTACH, (nil)) pid(8), tid(28), tls(2) trace:msvcrt:MSVCRT_setlocale (4 (null)) err:seh:setup_exception_record stack overflow 1440 bytes in thread 0009 eip 7ef8c40e esp 02910d90 stack 0x2910000-0x2911000-0x2e10000 However, I've been looking at the functions in the trace and it doesn't seem to be any of these functions causing the crash. Now, having looked at what msvcrt.dll is, it's much, much more than these functions, it's the C Run-Time dll and contains lots of functions, most are probably very standard and so don't contain any TRACEs. The only thing I can think of being the cause is that it must be some sort of untraced function causing this. I'm sorta out of my depth here on fixing this thing, how would you go about solving it? I think I'd be 90% of the way there if I could just figure out what functions it's really calling. Is there any way to track every access to the DLL, and I mean every? Like say a wrapper that would output a trace line then it calls the wine/real DLL? Regards, Kjell Rune Skaaraas _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

2 1

Re: [5/5] wined3d: Add support for immediate constants to the GLSL backend.
by Stefan Dösinger 07 May '09

07 May '09

Am Donnerstag, 7. Mai 2009 16:39:19 schrieb Henri Verbeet: I don't see an issue with the code in this patch, but did you find out anything new regarding the geforce 8 immval handling in the Nvidia driver? Remember the issue where my more-uniforms patch blew the constant limit because the driver encoded scalars as replicated vec4 immvals that still needed a full vec4 uniform for some reason? Was that a driver bug that is fixed in the newer drivers?

2 1

Re: Resend of xinput patch for bug 18218
by Austin English 07 May '09

07 May '09

On Sun, May 3, 2009 at 7:12 PM, Rafał Mużyło <galtgendo(a)gmail.com> wrote: > I didn't put DllMain in this file, as it was not > in the current version, just added numbers and > sorted (latter probably unnecessary). > --- dlls/xinput1_3/xinput1_3_main.c.old 2009-04-25 16:54:42.000000000 +0200 > +++ dlls/xinput1_3/xinput1_3_main.c 2009-04-26 00:41:04.000000000 +0200 If possible, please use git diff. > @@ -95,12 +95,20 @@ > { > FIXME("(%d %d %p)\n", dwUserIndex, dwFlags, pCapabilities); > > + //pCapabilities = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(XINPUT_CAPABILITIES)); No C++ code/comments. Thanks for helping wine! -- -Austin

1 0

Re: [1/3](resend)msctf: implement ITfKeystrokeMgr::PreserveKey
by Alexandre Julliard 07 May '09

07 May '09

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/msctf/tests/inputprocessor.c | 6 ++-- > dlls/msctf/threadmgr.c | 59 > +++++++++++++++++++++++++++++++++++- > 2 files changed, 60 insertions(+), 5 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M msctf.dll -T ../../.. -p msctf_test.exe.so inputprocessor.c && touch inputprocessor.ok inputprocessor.c:415: Test failed: ITfKeystrokeMgr_PreserveKey failed inputprocessor.c:418: Test failed: ITfKeystrokeMgr_PreserveKey inproperly succeeded make[2]: *** [inputprocessor.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdiplus: use the mode passed to GdipCreateLineBrushFromRect
by Alexandre Julliard 07 May '09

07 May '09

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > From 5ff18c519843d8df18bbb9d398079ed6a532c8c6 Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Wed, 6 May 2009 16:36:06 -0500 > Subject: [PATCH] gdiplus: use the mode passed to GdipCreateLineBrushFromRect It doesn't work here: ../../../tools/runtest -q -P wine -M gdiplus.dll -T ../../.. -p gdiplus_test.exe.so brush.c && touch brush.ok brush.c:343: Test failed: Expected 100.00, got 0.00 make[2]: *** [brush.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: Getting my test for DrawIcon and DrawIconEx included
by Ge van Geldorp 07 May '09

07 May '09

Hi Joel, > From: Joel Holdsworth > > Is there a reason why my patch (attached) hasn't been included yet? This > is my first patch, so maybe someone can help me get it in. You are aware that this patch introduces test failures on Windows 2000, Vista and 2008? See http://www.winehq.org/pipermail/wine-devel/2009-May/075324.html Ge.

1 0

Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.
by Alexandre Julliard 07 May '09

07 May '09

Rein Klazes <wijn(a)online.nl> writes: > Fixes bug 10845 > > Changes from previous patch: menu position calculations moved to > nonclient.c. You shouldn't need that, the menu size should be recomputed when it gets repainted. And if the menu was changed the whole window size needs to be recomputed anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: resubmit: [PATCH] crypt32: change salt allocation to handle errors (Coverity 133)
by Alexandre Julliard 07 May '09

07 May '09

Marcus Meissner <marcus(a)jet.franken.de> writes: > Coverity 133 shows that we need a error handling on failing > memory allocation here. Please handle the error correctly, returning FALSE is not enough. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
15
16
17
18
19
20
21
...
24
Older →

Jump to page:

2025

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 May 2009