Re: Severity levels
On Mon, May 4, 2009 at 12:28 AM, Ben Klein wrote: > 2009/5/4 Austin English : >> 2009/5/3 Rosanne DiMesio : >>> What I would suggest is making the default severity normal rather than >>> enhancement, as that's what's appropriate in most cases anyway (and there's >>> already a bug report, 13363, suggesting just that), and perhaps allowing >>> users to lower the severity if they want. Judgments about raising the >>> severity level above normal should be restricted to the people who know >>> what they're doing. >> >> +1 > > +1 > > But how would the restriction work? Not that I'm likely to ever submit > a Major or Critical bug report, but I know what they mean ;) > I don't know if bugzilla supports that or not. But changing the default to normal is quick and easy. -- -Austin
Re: Severity levels
2009/5/4 Austin English : > 2009/5/3 Rosanne DiMesio : >> What I would suggest is making the default severity normal rather than >> enhancement, as that's what's appropriate in most cases anyway (and there's >> already a bug report, 13363, suggesting just that), and perhaps allowing >> users to lower the severity if they want. Judgments about raising the >> severity level above normal should be restricted to the people who know what >> they're doing. > > +1 +1 But how would the restriction work? Not that I'm likely to ever submit a Major or Critical bug report, but I know what they mean ;)
Re: Severity levels
2009/5/3 Rosanne DiMesio : > What I would suggest is making the default severity normal rather than > enhancement, as that's what's appropriate in most cases anyway (and there's > already a bug report, 13363, suggesting just that), and perhaps allowing > users to lower the severity if they want. Judgments about raising the > severity level above normal should be restricted to the people who know what > they're doing. +1 -- -Austin
Re: Severity levels
> > > > Let's try user education. You only get to choose normal and we get to > > up/downgrade until you can prove that you know how to do it right. This > > is how some companies do it. > > > > James McKenzie > > > > +1. Or just remove priorities for users altogether. > I think you mean severity. I agree that users should be limited in what severity level they can set, but I suspect that not allowing them to set severity at all would create too much work for the people who would have to go in and set the severity level for every bug filed. What I would suggest is making the default severity normal rather than enhancement, as that's what's appropriate in most cases anyway (and there's already a bug report, 13363, suggesting just that), and perhaps allowing users to lower the severity if they want. Judgments about raising the severity level above normal should be restricted to the people who know what they're doing. Rosanne DiMesio
Re: Severity levels
2009/5/3 James McKenzie : > Ken Sharp wrote: >> >> >> Nicklas Börjesson wrote: >> >>> I think that the users should have quite a say with regards to how >>> important a bug is, because for every user putting in the >>> (considerable for a user) effort of reporting a bug, there are dozens >>> that don't say anything at all. >> >> To every Wine user, their application not working is critical. This >> is clear by all the bugs that are logged incorrectly every day, >> because nobody bothered reading the FAQ. > You bet. "The application that I reported, which has a perfectly good > Linux port, has to be fixed absolutely last week." I've seen this in > the user list again and again. It gets boorish after a while. > > Let's try user education. You only get to choose normal and we get to > up/downgrade until you can prove that you know how to do it right. This > is how some companies do it. > > James McKenzie > > > > +1. Or just remove priorities for users altogether.
Re: Severity levels
Ken Sharp wrote: > > > Nicklas Börjesson wrote: > >> I think that the users should have quite a say with regards to how >> important a bug is, because for every user putting in the >> (considerable for a user) effort of reporting a bug, there are dozens >> that don't say anything at all. > > To every Wine user, their application not working is critical. This > is clear by all the bugs that are logged incorrectly every day, > because nobody bothered reading the FAQ. You bet. "The application that I reported, which has a perfectly good Linux port, has to be fixed absolutely last week." I've seen this in the user list again and again. It gets boorish after a while. Let's try user education. You only get to choose normal and we get to up/downgrade until you can prove that you know how to do it right. This is how some companies do it. James McKenzie
Re: Office 2007 MSI Crash - Null dereference @ MsiViewExecute
On Sun, May 3, 2009 at 10:36 PM, James Hawkins wrote:
> On Sun, May 3, 2009 at 1:52 PM, Mike Kaplinskiy
> wrote:
>> On Thu, Apr 30, 2009 at 1:08 PM, James Hawkins wrote:
>>> On Thu, Apr 30, 2009 at 4:03 AM, Austin English
>>> wrote:
On Tue, Apr 28, 2009 at 9:27 PM, Mike Kaplinskiy
wrote:
> I was looking at the trace of the crash from bug 17600, and it looks like
> a custom action is calling MsiViewExecute with a null hRec.
>
> I (sadly) don't know much about the wine MSI architecture, but the
> msiobj_lock on line 484 should fail since rec will never be fetched
> (null). I think the intention was to make it query->hdr (as it is
> released later).
A testcase for it would show if you're right or wrong ;-).
>>>
>>> Not really. If you grep through the msi tests, you'll see that we
>>> call MsiViewExecute with NULL hRec all over the place. That doesn't
>>> mean there isn't a bug, just saying.
>>>
>>> --
>>> James Hawkins
>>>
>>
>> So I got a little time to look into this, and was completely blown
>> away. Apparently doing
>>
>> TRACE("dereferencing 0?=%p\n", (void *) &(((MSIRECORD *) NULL)->hdr));
>>
>> works, since nothing ever gets dereferenced. I will post a patch for
>> this small nit.
>>
>> On a slightly different note, I have traced the problem in office 2007
>> to the patch by James, and in particular to INSERT_execute. The row
>> index gets set to 0 if the primary key is null (which is what office
>> install is doing), but if the insert is temporary TABLE_insert assumes
>> that row >= tv->table->row_count, and subtracts from the row index,
>> putting us in the negatives (or high positives due to uint).
>>
>> I have a patch for this, but I don't know how to make a testcase (all
>> I know is office installs), so would anyone mind pointing me to
>> somewhere that explains msi temporary inserts?
>>
>> And should I post the patch up on wine-patches to get it critiqued?
>> (sorry, first time)
>>
>
> I'll take a look at your patch. No offense intended, but it's
> probably not correct. The problem is a beast and deeply rooted in the
> way we store temporary rows in the DB. I have a huge test patch for
> it, and I had a fix, but my linux HD got fragged (bummer).
>
> --
> James Hawkins
>
(Sorry, forgot to forward to the list)
Thanks James. I'm not gonna post it on the patches list quiet yet
then. I checked that the msi tests pass with the patch as well.
Mike.
From 24fb8a3628b0815a2cfcc0d6a7c6adb41f491bb2 Mon Sep 17 00:00:00 2001
From: Mike Kaplinskiy
Date: Sun, 3 May 2009 16:15:39 -0400
Subject: msi: fix temporary row handling
---
dlls/msi/table.c | 145 +-
1 files changed, 57 insertions(+), 88 deletions(-)
diff --git a/dlls/msi/table.c b/dlls/msi/table.c
index e7e2e68..a892be5 100644
--- a/dlls/msi/table.c
+++ b/dlls/msi/table.c
@@ -73,9 +73,8 @@ typedef struct tagMSIORDERINFO
struct tagMSITABLE
{
BYTE **data;
+BOOL *data_persistent;
UINT row_count;
-BYTE **nonpersistent_data;
-UINT nonpersistent_row_count;
struct list entry;
MSICOLUMNINFO *colinfo;
UINT col_count;
@@ -476,9 +475,7 @@ static void free_table( MSITABLE *table )
for( i=0; irow_count; i++ )
msi_free( table->data[i] );
msi_free( table->data );
-for( i=0; inonpersistent_row_count; i++ )
-msi_free( table->nonpersistent_data[i] );
-msi_free( table->nonpersistent_data );
+msi_free( table->data_persistent );
msi_free_colinfo( table->colinfo, table->col_count );
msi_free( table->colinfo );
msi_free( table );
@@ -520,6 +517,9 @@ static UINT read_table_from_storage( MSIDATABASE *db, MSITABLE *t, IStorage *stg
t->data = msi_alloc_zero( t->row_count * sizeof (USHORT*) );
if( !t->data )
goto err;
+t->data_persistent = msi_alloc_zero( t->row_count * sizeof(BOOL));
+if ( !t->data_persistent )
+goto err;
/* transpose all the data */
TRACE("Transposing data from %d rows\n", t->row_count );
@@ -528,6 +528,7 @@ static UINT read_table_from_storage( MSIDATABASE *db, MSITABLE *t, IStorage *stg
t->data[i] = msi_alloc( row_size );
if( !t->data[i] )
goto err;
+t->data_persistent[i] = TRUE;
for( j=0; jcol_count; j++ )
{
@@ -634,8 +635,7 @@ UINT msi_create_table( MSIDATABASE *db, LPCWSTR name, column_info *col_info,
table->ref_count = 1;
table->row_count = 0;
table->data = NULL;
-table->nonpersistent_row_count = 0;
-table->nonpersistent_data = NULL;
+table->data_persistent = NULL;
table->colinfo = NULL;
table->col_count = 0;
table->persistent = persistent;
@@ -783,8 +783,7 @@ static UINT get_table( MSIDATABASE *db, LPCWSTR name, MSITABLE **table_ret )
table->row_count = 0;
table->data = NULL;
-table->nonpersistent_row_count = 0;
-table->nonpersistent_data = NULL;
+table->data_persistent = NULL
Re: Office 2007 MSI Crash - Null dereference @ MsiViewExecute
On Sun, May 3, 2009 at 1:52 PM, Mike Kaplinskiy
wrote:
> On Thu, Apr 30, 2009 at 1:08 PM, James Hawkins wrote:
>> On Thu, Apr 30, 2009 at 4:03 AM, Austin English
>> wrote:
>>> On Tue, Apr 28, 2009 at 9:27 PM, Mike Kaplinskiy
>>> wrote:
I was looking at the trace of the crash from bug 17600, and it looks like
a custom action is calling MsiViewExecute with a null hRec.
I (sadly) don't know much about the wine MSI architecture, but the
msiobj_lock on line 484 should fail since rec will never be fetched
(null). I think the intention was to make it query->hdr (as it is
released later).
>>>
>>> A testcase for it would show if you're right or wrong ;-).
>>>
>>
>> Not really. If you grep through the msi tests, you'll see that we
>> call MsiViewExecute with NULL hRec all over the place. That doesn't
>> mean there isn't a bug, just saying.
>>
>> --
>> James Hawkins
>>
>
> So I got a little time to look into this, and was completely blown
> away. Apparently doing
>
> TRACE("dereferencing 0?=%p\n", (void *) &(((MSIRECORD *) NULL)->hdr));
>
> works, since nothing ever gets dereferenced. I will post a patch for
> this small nit.
>
> On a slightly different note, I have traced the problem in office 2007
> to the patch by James, and in particular to INSERT_execute. The row
> index gets set to 0 if the primary key is null (which is what office
> install is doing), but if the insert is temporary TABLE_insert assumes
> that row >= tv->table->row_count, and subtracts from the row index,
> putting us in the negatives (or high positives due to uint).
>
> I have a patch for this, but I don't know how to make a testcase (all
> I know is office installs), so would anyone mind pointing me to
> somewhere that explains msi temporary inserts?
>
> And should I post the patch up on wine-patches to get it critiqued?
> (sorry, first time)
>
I'll take a look at your patch. No offense intended, but it's
probably not correct. The problem is a beast and deeply rooted in the
way we store temporary rows in the DB. I have a huge test patch for
it, and I had a fix, but my linux HD got fragged (bummer).
--
James Hawkins
Re: Severity levels
2009/5/4 Austin English : > 2009/5/3 Nicklas Börjesson : >>>Why should there be multiple support forums? >> >> Well, not forums, but as I said different lists for different kinds >> of applications(games/business/graphics), since they should(?) have related >> problems. >> I would think so, anyway. That would be the case if *everyone* who *ever* produced software banded together and established a one-way-to-do-one-thing API set. Doesn't happen that way. Firefox and IE have drastically different success/failure/issues when running in Wine, as do MS Word and WordPerfect (I bet you thought I was going to say OOWriter!) > The forums seem to serve this well as is. Also AppDB has a browse feature, and lists bugs that apply to each application (when moderated correctly). >>>The wiki has _a lot_ of info, most of the time when bugs are closed invalid, >>>wiki links are given to fix the problem. Again, wine _is_ an open source >>>project. >>> If the wiki isn't good enough, add something. >> >> I am talking about avoiding a bug being submitted at all. By making the bug reporting system more confusing? >> Maybe to organize how-to-run information. >> Sure I could do a bit of that. It's like the idea you had about getting >> funding, >> did they tell you to go do it all by yourself? > > http://appdb.winehq.org ? > >>>How do you mean their priorities are important? It's an uncomfortable >>>truth, but users priorities aren't important, like has been said >>>dozens of times. Sure, we care about user's bugs, and want to fix >>>them. >> ... >> Users priorities probably affect what severity level they choose. >> But as I said to Ken, I can't believe that all users are morons. >> Anyway, regardless of their motives, I still think that they have to be >> included. User priorities do not affect which bug should be examined first. All bugs are created equal (and some bugs are more equal than others). Not really the case there, but all bugs of each severity (this is developer-side severity) are created equal and should be treated as such. > It doesn't affect anything, so there is no point. We can give every > user a gold star and say "yes, it's our highest priority", but it > doesn't do anything, so _there is no_ point. > >> If not, the project will slowly drift away and turn into a toy nobody have >> any use for. > > I highly doubt Wine is going to become irrelevant because users have > their bugs reassigned from critical to normal... You'd be surprised! Releases will stop, AJ will quit citing user unfriendliness, the Earth will spin off its axis and throw everyone save John Smith from Liverpool out in to space, and so forth, all because MY BUG WAS REDUCED FROM CRITICAL TO NORMAL! It's critical to me, so why is it not critical to the developers? >>>But every user also thinks *their* app is the most important >>>application to fix. >> >> Actually, I can't believe they all are that way. > > Again, you may not think it, but I've been triaging bugs for 3 years, > so I know what does happen. Maybe you should have said "the average user" instead of "every user", but it's true. If we leave the severity level up to the user, we'll get a whole lot of Critical bugs being submitted that aren't critical on the developer's side. >>>Wine can't stop development on _everything_ just to get one user's >>>application running. Making user's arbitrary priorities the most >>>important would be doing this. >> >> Good thing I didn't propose that then. :-) >> I said it should be a part of the priority and a considerable one. Not the >> largest one. So where should it sit exactly? In between "how long will this take to code" and "how many apps does this effect"? Should it be higher than "is there a simple, *correct* way to fix this"? >> And I am not talking about users arbitrary priorities, just including >> more intuitive severity levels(good or bad) when making bug fixing >> priorities. So, you mean allow the users to arbitrarily select whether THEY think their bug should have a high priority or not? > I think this argument is circular...Wine has no shortage of bugs being > reported, we have plenty of new users reporting bugs, and new > developers contributing often. You're proposing adding an extra > severity rating that no developer will look at, and will only add to > confusion (users now have to decide *two* levels rather than one). No, he's proposing to dump the developer-focused severity completely, because "component + priority should be good enough", and replace it with ill-defined, ambiguous Low, Medium, High, Critical. Blockers and metabugs would also disappear under his proposed model, it seems. After all, what good are metabugs to users? ;) > It > won't add any benefit, other than possibly giving users a warm fuzzy > feeling that their bug is 'important' to them (which they can already > do with voting), but adds confusion, wasted time, and wasted effort. +1
Re: Severity levels
2009/5/3 Nicklas Börjesson : > It just feels like the entire project should become a bit more user-centric. > Now I am not just talking about shinier graphics but about attitude. Bugzilla not user tool. Bugzilla developers' tool. Bugzilla need work like developers want. 2009/5/4 Nicklas Börjesson : >>So you suggest making the severity ratings meaningless to anyone but >>... well, you don't actually mention anyone knowing what they *really* >>mean, but I assume an exclusive clique of developers or bugzilla >>admins? Users have different opinions on what level of bug they >>encounter depending on what *task* they're trying to perform, which is >>not particularly useful to developers who need strict reproducability. > > No, I mean that the actual meaning of the words "low", "medium", "high" and > "Critical" will suffice. No they won't. In order for the severity levels to be meaningful, they need to be strictly defined. Take the example of contracts or legislation, where otherwise unambiguous words are defined in context just to make it 100% perfectly clear what's being talked about. Wine is a *big* project, and we really don't need massive confusion over what the severity levels mean. > I think most people have a fair understanding what "medium" and "critical" > means. Apparently not. Most people don't see the bigger picture, they only see what they're doing right now (e.g. Critical bugs filed because they have an assignment due the next day when it is in fact only a Minor or Normal bug). > This is not meaningless at all, to trying to clarify these levels is quite > pointless though. OK, so give examples of what would be "low", "medium", "high" and "critical" bugs. > Yes, some people tend to exaggerate their issues, but that's just the way it > is. And removing the definitions can in no way help this. > And to my experience, they are few. Most actually don't exaggerate as much. So you're suggesting to completely overhaul the system for only a FEW users to be more productive in submitting bugs? > To them, the situation IS critical, bordering on panic. > Rather, thinking that their users are exaggerating is a way for developers to > not let reality come to close. > Hell, I do it myself right now. :-) Yes, but that's not what the "severity" indicates. As it has already been said, focusing on a particular user's problem just because THEY think it's critical is completely unproductive for a large (massive?) project like Wine. Wine devs need to look at the big picture, as in "What is the overall impact of this bug? Who and what is affected? Roughly how many applications does it affect/break?" and THAT's what the "severity" setting is for. Another way to look at severity is a rough indication of how much code change is expected to be required to fix the bug. In theory (but by no means in all cases in practice), a Minor bug should have very little code changed compared to a Major bug. Again, severity is there for the *developers* to use and understand, not for the users. > I don't see how the reproducibility connects to the severity level? It doesn't. It connects to the interaction between user and developer. You're talking about user impressions - "THIS NEEDS TO BE FIXED NOW OR I WILL DIE" - I'm talking about REAL bug report information - "When you click on this button then hit this menu option, the application draws squiggly lines all over the screen. Graphics card has nVidia 180.29 drivers." > Regarding the priority flag..i was referring to it's visibility, not its > state. Bugzilla doesn't (and can't) know the difference between an average non-tech-savvy user and a hard-core developer. If the priority flag is hidden from average users because they shouldn't change it, then it will also be hidden from people who know how to use it properly, and more importantly the people who NEED to change it (to make their report complete). >>There already is a separate category flag. It's called "severity" and >>it indicates roughly the amount of *functionality* lost due to the >>bug. "Priority" does not indicate the severity of a bug; a bug may >>have low priority due to limitations outside of Wine (such as some >>blocker bugs for copy-protection systems which can't be supported in >>Wine). > > My point is that there should be no need for that flag. > Let the users have it as input, and let the developers use component+priority. Component + priority gives absolutely no indication on the overall impact of a bug, as I have mentioned before. Priority and severity (developer-side severity) do not have a 1-to-1 relationship. >>You're not going to like this, but users don't matter quite *that* >>much on bugzilla. The bug tracker is a developer's tool, and although >>users are essential to the process (submitting bugs and new >>information on request), it should be designed as a developer's tool. >>A user's impression of their problem is irrelevant to the hard data >>they can provide about lost or missing
Re: Severity levels
2009/5/3 Nicklas Börjesson : >>Why should there be multiple support forums? > > Well, not forums, but as I said different lists for different kinds > of applications(games/business/graphics), since they should(?) have related > problems. > I would think so, anyway. The forums seem to serve this well as is. >>The wiki has _a lot_ of info, most of the time when bugs are closed invalid, >>wiki links are given to fix the problem. Again, wine _is_ an open source >>project. >> If the wiki isn't good enough, add something. > > I am talking about avoiding a bug being submitted at all. > Maybe to organize how-to-run information. > Sure I could do a bit of that. It's like the idea you had about getting > funding, > did they tell you to go do it all by yourself? http://appdb.winehq.org ? >>How do you mean their priorities are important? It's an uncomfortable >>truth, but users priorities aren't important, like has been said >>dozens of times. Sure, we care about user's bugs, and want to fix >>them. > ... > Users priorities probably affect what severity level they choose. > But as I said to Ken, I can't believe that all users are morons. > Anyway, regardless of their motives, I still think that they have to be > included. It doesn't affect anything, so there is no point. We can give every user a gold star and say "yes, it's our highest priority", but it doesn't do anything, so _there is no_ point. > If not, the project will slowly drift away and turn into a toy nobody have > any use for. I highly doubt Wine is going to become irrelevant because users have their bugs reassigned from critical to normal... >>But every user also thinks *their* app is the most important >>application to fix. > > Actually, I can't believe they all are that way. Again, you may not think it, but I've been triaging bugs for 3 years, so I know what does happen. >>Wine can't stop development on _everything_ just to get one user's >>application running. Making user's arbitrary priorities the most >>important would be doing this. > > Good thing I didn't propose that then. :-) > I said it should be a part of the priority and a considerable one. Not the > largest one. > And I am not talking about users arbitrary priorities, just including > more intuitive severity levels(good or bad) when making bug fixing priorities. I think this argument is circular...Wine has no shortage of bugs being reported, we have plenty of new users reporting bugs, and new developers contributing often. You're proposing adding an extra severity rating that no developer will look at, and will only add to confusion (users now have to decide *two* levels rather than one). It won't add any benefit, other than possibly giving users a warm fuzzy feeling that their bug is 'important' to them (which they can already do with voting), but adds confusion, wasted time, and wasted effort. -- -Austin
Re: Severity levels
Nicklas Börjesson wrote: How many times does this have to be repeated? Severity levels are NOT determined by how much a user wants the app to work. They're just not, deal with it. I have never said it is, either. I said it think it should be determined by how severe the user thinks it is(if devs then cares about it is another matter). And you've already been told it shouldn't, and this has been explained to you. Junk.
Re: Giving up for now
Roderick Colenbrander ha scritto: Have you also tried to use the GDI AlphaBlend function? This is the one which should be used I think and we back it by XRender .. Roderick Sorry for the OT : apropos AlphaBlend and RGBA bitmaps... what happens with BitBlt on a destination DIB which has alpha channel ? it gets overwritten or the dest alpha channel is simply ignored ? I mean BitBlt(dstBmp..., SRC_COPY) what happens to dstBmp alpha ? and BitBlt(dstBmp..., SRC_AND) ??? Max
Re: Giving up for now
On Sun, May 3, 2009 at 6:28 PM, Roderick Colenbrander wrote: > On Sat, May 2, 2009 at 11:18 PM, Joel Holdsworth > wrote: >> On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >>> On Sat, May 2, 2009 at 8:57 PM, Joel Holdsworth >>> wrote: >>> > On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: >>> >> On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth >>> >> wrote: >>> >> > Hi All, >>> >> > >>> >> > I've hit a bit of a wall with alpha blended icons. CreateIcon is >>> >> > working >>> >> > fine for icon creation, but ExtractIcon and LoadIconFromResource etc. >>> >> > are all proving more of a problem. All of these use various GDI DIB >>> >> > functions to coerce the icon bitmap to the correct colour depth and >>> >> > size. The problem is that preserving the alpha channel through these >>> >> > DIB >>> >> > functions seems to be impossible because they go via X11, so until the >>> >> > dib engine is merged (after hell freezes over) I'm not sure I can go >>> >> > much further. >>> >> > >>> >> > Joel >>> >> > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> >>> >> If you say X11 might be problematic note that more and more display >>> >> drivers are offering visuals with alpha, so 32-bit ones instead of >>> >> 24-bit. You could force the selection of such a visual in winex11.drv >>> >> for testing. >>> >> >>> >> Roderick >>> > >>> > Is that right? I simply assumed it would screw it up. If the problem can >>> > be solved with fixes to user32 or gdi32, then I can probably find the >>> > solution. If it involves work on winex11, then I'm not really the right >>> > guy for the job. >>> > >>> > >>> > >>> >>> Why again did you need this specific alphablend method? The icon can't >>> be converted to use some basic color keying for transparency or so? >> >> The reason is that the outlines will look aliased, and there will be no >> drop-shadows - without alpha the Tango icons won't look better than the >> current set. Also, I figured that icon rendering should be fixed for the >> sake of wine as a whole - which I think it should. It seems like a good >> little task for a wine beginner, and indeed I've made a lot of progress >> - I'm just a bit stuck. >> >> The culprit is a transfer through StretchDIBits in user32 which strips >> the alpha channel. I can't see a way round it - using StretchBlt doesn't >> help, and neither does GdiTransparentBlt. >> >> Another insentive: I suspect fixing this would also fix bug #201 which >> is now over 8 years old! >> >> >> > > I just looked a little more into it. As you mentioned StretchDIBits in > user32 removes the alpha channel. According to this post at MSDN > (http://msdn.microsoft.com/en-us/library/dd145023(VS.85).aspx) the > function got extended in Vista to include PNG support because PNG is > used for most icons in Vista. It might be useful to check that out. > The page mentions it was meant for printers but most likely they also > use this for icon rendering. I think it can be used in cooperation > with XRender (there are various xrender examples for dealing with > alpha). > > Roderick > Have you also tried to use the GDI AlphaBlend function? This is the one which should be used I think and we back it by XRender .. Roderick
Re: Office 2007 MSI Crash - Null dereference @ MsiViewExecute
On Thu, Apr 30, 2009 at 1:08 PM, James Hawkins wrote:
> On Thu, Apr 30, 2009 at 4:03 AM, Austin English
> wrote:
>> On Tue, Apr 28, 2009 at 9:27 PM, Mike Kaplinskiy
>> wrote:
>>> I was looking at the trace of the crash from bug 17600, and it looks like
>>> a custom action is calling MsiViewExecute with a null hRec.
>>>
>>> I (sadly) don't know much about the wine MSI architecture, but the
>>> msiobj_lock on line 484 should fail since rec will never be fetched
>>> (null). I think the intention was to make it query->hdr (as it is
>>> released later).
>>
>> A testcase for it would show if you're right or wrong ;-).
>>
>
> Not really. If you grep through the msi tests, you'll see that we
> call MsiViewExecute with NULL hRec all over the place. That doesn't
> mean there isn't a bug, just saying.
>
> --
> James Hawkins
>
So I got a little time to look into this, and was completely blown
away. Apparently doing
TRACE("dereferencing 0?=%p\n", (void *) &(((MSIRECORD *) NULL)->hdr));
works, since nothing ever gets dereferenced. I will post a patch for
this small nit.
On a slightly different note, I have traced the problem in office 2007
to the patch by James, and in particular to INSERT_execute. The row
index gets set to 0 if the primary key is null (which is what office
install is doing), but if the insert is temporary TABLE_insert assumes
that row >= tv->table->row_count, and subtracts from the row index,
putting us in the negatives (or high positives due to uint).
I have a patch for this, but I don't know how to make a testcase (all
I know is office installs), so would anyone mind pointing me to
somewhere that explains msi temporary inserts?
And should I post the patch up on wine-patches to get it critiqued?
(sorry, first time)
Mike.
Re: Severity levels
IneedAname wrote: On Sun, 03 May 2009 18:10:03 +0100 Ken Sharp wrote: That would be the "Show Apps affected by this bug" link then. http://appdb.winehq.org/viewbugs.php?bug_id=16281 Thanks I missed that so how but my first point still stands. Not really. 16281 certainly isn't a major loss of functionality, no matter how many bugs are attached to it.
Re: Severity levels
2009/5/3 Nicklas Börjesson : >> You'd be surprised... > We'll I've looked around at "invalids", but to me it seems that people in > general(with a few exceptions of course), tries quite hard until they file a > bug report. > At least way harder than they do in other FOSS projects I have been involved > in, so I can't really say that I would think you've got a problem. > At least not yet. Despite the support forum only have one list. More stuff on > the wiki would help too. Why should there be multiple support forums? The wiki has _a lot_ of info, most of the time when bugs are closed invalid, wiki links are given to fix the problem. Again, wine _is_ an open source project. If the wiki isn't good enough, add something. > What I am talking about the fact that the ordinary users priorities are very > important. > Currently they are either: > 1.Completely disregarded or > 2. If they follow the instruction(where "commons sense" is not mentioned), > they're forced to adhere to severity levels that distort or hide their > opinion of the problem. And for each user reporting there are dozens that are > not. Bad will. How do you mean their priorities are important? It's an uncomfortable truth, but users priorities aren't important, like has been said dozens of times. Sure, we care about user's bugs, and want to fix them. But every user also thinks *their* app is the most important application to fix. I regularly change around 3-5 bugs _a day_ that are marked critical, because their favorite app XYZ doesn't run. A good portion of that time, the bug is invalid, because they forgot a runtime, e.g., the application didn't bundle msvcrt80 or the like. Wine can't stop development on _everything_ just to get one user's application running. Making user's arbitrary priorities the most important would be doing this. > It just feels like the entire project should become a bit more user-centric. > Now I am not just talking about shinier graphics but about attitude. > Maybe soften up a bit ask oneself, "WHY did this person ask this stupid > question?", "WHY did he do this EVEN though it says do this?" or "How would I > feel if someone said this to me?". No disagreement there. Most developers do have a friendly attitude towards users. If they don't, e-mail them in private, with a copy of what they said and ask them to be more civil. I'd encourage you to subscribe to wine-bugs for a while. Look how much mail/bugs we go through, and you'll quickly see why time to hold every users hand and fix _their_ most important bug is impossible. -- -Austin
Re: Severity levels
Nicklas Börjesson wrote: To every Wine user, their application not working is critical. This is clear by all the bugs that are logged incorrectly every day, because nobody bothered reading the FAQ. Yep, but that's more an indication on how much work remains to be done on wine than it is an incorrect severity level. No it isn't. It's an indication on how many people think they're more important than anyone else filing a bug. If Photoshop(the eternal example) should stop working on windows due to a regression, I am sure the users would consider it critical when they report it to Microsoft. It doesn't matter what the users think, we've been over this, it would be up to MS coders. They would put a high priority on it because Adobe it a major player, and I'm sure MS makes a lot of money out of them one way or another. This is a FOSS project and has no bearing on severity levels. If a set of devs decide to work on getting a particular app working that's up to them, and we've already been over this too. But as the wine project progresses, severity levels will hopefully drop so that there will be more nuances. As Wine progress, the higher severities will be less and less. Higher sev levels will stand out a lot more. That's what they're for. I just think there is something severely when registering a bug that results in unworkable applications is considered a "normal" or even "minor" bug. To me, that's sending the wrong signals about the ambition of the project. Nobody else seems to have this problem. Unless the "not yet suitable for general use" from the faq is everywhere with blinking warning signs. Bares no relevance whatsoever to severity levels in Bugzilla. //Nicklas Note to self: Reply to ALL.
Re: user32: combine horizontal and vertical window scroll bar info in a single structure.
On Fri, 01 May 2009 22:15:16 +0200, you wrote: >Rein Klazes writes: > >> What is already in the tests: >> >> 1) You need the alloc flag for instance when SetScrollInfo or >> SetScrollRange is called on a window without the WS_[HV]SCROLL styles. I >> can add a test that shows that the window styles remain unchanged when >> eg. SetScrollInfo creates the scrollinfo. >> >> 2) You need the style test when testing GetScrollInfo and GetScrollRange >> on windows with WS_[HV]SCROLL styles. >> >> Now the alloc flag may not be specified correctly in the other cases >> Additional tests to see whether the alloc flag is correctly passed for >> [GS}etScrollBarInfo and EnableScrollBar can be added. >> >> Would such tests address your concerns? > >No, what you'd need is a test that shows that calling a function that >doesn't create a scrollbar (alloc=FALSE) suddenly starts to create one >if WS_[HV]SCROLL is set. To test this meaningfully you'd need to set the >style by hand, not at window creation. Indeed you were right. Setting the WS_[HV]SCROLL with a SetWindowLong does not create the scrollbar info, which proves unambiguously that my idea was false. I guess to fix the windows style test failures some SetScrollSomething will have to be done in the CreateWindow functions. I'll postpone that for another patch and send now the patch which only fixes the separate scollinfo structures, which is enough for the bugzilla bug. Rein.
Re: Severity levels
IneedAname wrote: On Sat, 2 May 2009 16:52:06 +0200 Nicklas Börjesson wrote: 3. Major"Major loss of functionality for a wide range of applications - Isn't this just all bugs that has more than $arbitrary_number of applications linked to them? An aggregate, rather than a level? In that case #16281 would be major not minor, That is if all the applications that has that bug link to it. I think you can not find out how many applications link a bug. As that has not be coded. To find out that information you would have to scan the application data base or change the way the data base holds this data. I think you want to read bug #16284. That would be the "Show Apps affected by this bug" link then. http://appdb.winehq.org/viewbugs.php?bug_id=16281
RE: Severity levels
>I disagree. When first introduced to them, I found the severity levels >to be suitably vague to make me read the definitions. Once I read >them, it was clear to me what each level means. Suitably? Do you mean that the severity levels are the way they are to make people read their definitions? :-) Jokes aside, that's exactly what I don't want. I want them to be even more vague(Low, Medium, High and Critical) and without any definitions except for the highest level. This way, one will elicit more how the user perceives the overall impact of the bug, without having to shoehorn them into some level that only partly matches their impression. Done with the help of the users indisputable "common sense", of course. Also, the priority flag should not be visible to the user by default, it should be a strangely named setting somewhere in the user preferences. >But bear in mind the severity levels are there >to help the developers categorise the bugs, and they are not there to >provide feedback to the average non-coding user. For categorisation, there could be a separate category flag if the "component" categorisation + priority wouldn't suffice. Whatever. There are many ways to do it. But currently, the users' impression of the problem get lost and/or skewed. //Nicklas
RE: Severity levels
> You'd be surprised... We'll I've looked around at "invalids", but to me it seems that people in general(with a few exceptions of course), tries quite hard until they file a bug report. At least way harder than they do in other FOSS projects I have been involved in, so I can't really say that I would think you've got a problem. At least not yet. Despite the support forum only have one list. More stuff on the wiki would help too. >Not all critical bugs are caused by the loader. It's possible for >d3d/ole/etc. to have a similar effect. Yes, it is possible, but not likely enough to warrant an extra severity level. Yes, I have looked. >Keep in mind, most developers are unpaid as well. They're the ones >fixing the bugs, not users. While users are important, no work gets >done without the developers. I know that most developers are also unpaid. With "maintained" I didn't only mean maintainers of versions and so forth. >Developers have no way to prioritize one >user over another. The best way to prioritize *your* bug is to make a >*good* bug report. Make sure all needed information is included. Get a >testcase if possible. Provide the needed traces, etc. Even better, is >to write a patch yourself. The source is there, and there is nothing >stopping you from writing a patch. Again. This is not what I am talking about. I am not relevant because I am also an experienced developer, so I have no problems with these things. I can patch like there is no tomorrow, given time. What I am talking about the fact that the ordinary users priorities are very important. Currently they are either: 1.Completely disregarded or 2. If they follow the instruction(where "commons sense" is not mentioned), they're forced to adhere to severity levels that distort or hide their opinion of the problem. And for each user reporting there are dozens that are not. Bad will. It just feels like the entire project should become a bit more user-centric. Now I am not just talking about shinier graphics but about attitude. Maybe soften up a bit ask oneself, "WHY did this person ask this stupid question?", "WHY did he do this EVEN though it says do this?" or "How would I feel if someone said this to me?". //Nicklas
Re: Severity levels
On Sat, 2 May 2009 16:52:06 +0200 Nicklas Börjesson wrote: > 3. Major "Major loss of functionality for a wide range of applications > > - Isn't this just all bugs that has more than $arbitrary_number of > applications linked to them? An aggregate, rather than a level? In that case #16281 would be major not minor, That is if all the applications that has that bug link to it. I think you can not find out how many applications link a bug. As that has not be coded. To find out that information you would have to scan the application data base or change the way the data base holds this data. I think you want to read bug #16284.
Re: wine-devel Digest, Vol 46, Issue 10
wine-devel-requ...@winehq.org wrote: > ___ > wine-devel mailing list - wine-devel@winehq.org > http://www.winehq.org/mailman/listinfo/wine-devel > > > > > Subject: > Re: RFC on Base Wine Config > From: > Kai Blin > Date: > Sun, 3 May 2009 09:04:13 +0200 > To: > wine-devel@winehq.org > > To: > wine-devel@winehq.org > > > On Sunday 03 May 2009 07:07:35 Ben Klein wrote: > >> 2009/5/3 chris ahrendt : >> > > Replying to Ben's email as I didn't get Chris' email Ben replied to. > I would also like to note that I don't appreciate the tone both of these > emails are taking in the end. Please try to be civil. > > That being said, let me get to the technical part. > > >>> I guess I am not being completely clear somewhat >>> If I am in windows and go into explorer... >>> >> We've been through this before. Wine is not Windows. In Wine, the >> drive has to be mapped in dosdevices. >> >>> go to a network drive. I do >>> not nescisarily have to map that drive in order to run an application >>> (so long as the DLLS it needs, if any, are not just on that drive). I >>> can click the application >>> and it runs. I realise this may be a fundamental difference between unix >>> and windows but still they should theoretically run the same. >>> > > The important part here is that your local drives are local drives. Don't > confuse the Wine drive mappings with network drive mappings in Windows. Think > about a Wine drive mapping like plugging a new hdd into your box. > > >> But you're NOT running the test from a network drive, are you? And >> even if you were, you'd need some way to inform Wine that it's there, >> which would be to map it to a drive. Does Wine even support >> Windows-style shares? >> > > Nope. We could, but then you'd have to create a Samba share to allow us to > use > the directory. I'm pretty sure a wine drive mapping is easier and faster. > > >>> Also from >>> a command line I can do (I think if I am remembering correctly (been >>> doing to much z work lately) ) //server/directory/app.exe and it will >>> retrieve and run the app... (I think) >>> > > That's a bit besides the point, as this is still a valid UNC path. Now > imagine > I've got a USB hdd with my app on it, and that's usually connected at U:, > with my app being at U:\test\app.exe. Now the logic in Windows mapping my USB > drive to U: is just what the wine dosdevice mapping is like. If I now tell > windows to remove the USB device, my desktop link to U:\test\app.exe is not > going to work anymore. > > >> This message appears in your bug report: >> >>> Warning: could not find DOS drive for current working directory >>> '/home/cahrendt/wine-git/dlls/inetmib1/tests', starting in the Windows >>> directory. >>> > > Here my analogy would be a bit stretched, as in that you'd still manage to be > on the USB drive while it's already been disconnected. But basically you're > trying to run a program that's on a drive not connected to your wine "box". > > Cheers, > Kai > > > Thanks Kai, This is the kind of dialog I was looking for in the RFC. This makes sense. In a way with you are in a seperate 'region' and do not have access to that regions resources unless you map it. Even though wine is not a emulator it is essentially a VM running in userspace on the box that you need to allocate some resources to. (not so much like solaris 10 or zVM's where you can set up resources for everything). Ok clear now. Chris
Re: Giving up for now
On Sat, May 2, 2009 at 11:18 PM, Joel Holdsworth wrote: > On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >> On Sat, May 2, 2009 at 8:57 PM, Joel Holdsworth >> wrote: >> > On Sat, 2009-05-02 at 20:38 +0200, Roderick Colenbrander wrote: >> >> On Sat, May 2, 2009 at 6:55 PM, Joel Holdsworth >> >> wrote: >> >> > Hi All, >> >> > >> >> > I've hit a bit of a wall with alpha blended icons. CreateIcon is working >> >> > fine for icon creation, but ExtractIcon and LoadIconFromResource etc. >> >> > are all proving more of a problem. All of these use various GDI DIB >> >> > functions to coerce the icon bitmap to the correct colour depth and >> >> > size. The problem is that preserving the alpha channel through these DIB >> >> > functions seems to be impossible because they go via X11, so until the >> >> > dib engine is merged (after hell freezes over) I'm not sure I can go >> >> > much further. >> >> > >> >> > Joel >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> >> If you say X11 might be problematic note that more and more display >> >> drivers are offering visuals with alpha, so 32-bit ones instead of >> >> 24-bit. You could force the selection of such a visual in winex11.drv >> >> for testing. >> >> >> >> Roderick >> > >> > Is that right? I simply assumed it would screw it up. If the problem can >> > be solved with fixes to user32 or gdi32, then I can probably find the >> > solution. If it involves work on winex11, then I'm not really the right >> > guy for the job. >> > >> > >> > >> >> Why again did you need this specific alphablend method? The icon can't >> be converted to use some basic color keying for transparency or so? > > The reason is that the outlines will look aliased, and there will be no > drop-shadows - without alpha the Tango icons won't look better than the > current set. Also, I figured that icon rendering should be fixed for the > sake of wine as a whole - which I think it should. It seems like a good > little task for a wine beginner, and indeed I've made a lot of progress > - I'm just a bit stuck. > > The culprit is a transfer through StretchDIBits in user32 which strips > the alpha channel. I can't see a way round it - using StretchBlt doesn't > help, and neither does GdiTransparentBlt. > > Another insentive: I suspect fixing this would also fix bug #201 which > is now over 8 years old! > > > I just looked a little more into it. As you mentioned StretchDIBits in user32 removes the alpha channel. According to this post at MSDN (http://msdn.microsoft.com/en-us/library/dd145023(VS.85).aspx) the function got extended in Vista to include PNG support because PNG is used for most icons in Vista. It might be useful to check that out. The page mentions it was meant for printers but most likely they also use this for icon rendering. I think it can be used in cooperation with XRender (there are various xrender examples for dealing with alpha). Roderick
Re: Severity levels
Nicklas Börjesson wrote: I think that the users should have quite a say with regards to how important a bug is, because for every user putting in the (considerable for a user) effort of reporting a bug, there are dozens that don't say anything at all. To every Wine user, their application not working is critical. This is clear by all the bugs that are logged incorrectly every day, because nobody bothered reading the FAQ.
Re: Limit of todo_wine ?
Vincent Povirk ha scritto: This is by design. Each call to ok() is an individual test, independent of the others, and todo_wine marks them all as todo. If you have the same code running multiple tests, you can mark some of them as todo by putting a todo flag in your data. If you really want multiple checks to be dependent, you'll need to reduce them to one ok() call. Vincent Povirk Yep, that what I'm doing now but the code is quite less clean than before. Thank you for answer Max
Re: Limit of todo_wine ?
This is by design. Each call to ok() is an individual test, independent of the others, and todo_wine marks them all as todo. If you have the same code running multiple tests, you can mark some of them as todo by putting a todo flag in your data. If you really want multiple checks to be dependent, you'll need to reduce them to one ok() call. Vincent Povirk
Limit of todo_wine ?
Today writing a testcase I found a "problem" on todo_wine construct.
In short :
void first_test_part()
{
ok(test1(), "failed\n");
}
void second_test_part()
{
ok(test2(), "failed\n");
}
todo_wine
{
first_test_part();
second_test_part();
}
this "fails" (i.e. is marked as passing inside todo_wine block)
if first_test_part() passes, which is not what wished;
in this case the test should be considered passing if BOTH
first and second part passes, and failed otherwise.
The problem arose on bitmap creation test (gdiplus) on which
the testcase should check for creation success AND bitmap
internal consiscency.
My example is short, but in my case there's a single function used
to test many kind of bitmaps; that's impossible to do with
todo_wine actual construct.
It could be obviously separated into many functions, each enclosed
on its own todo_wine, but this would vanify the "single test function
for many bitmaps types" way.
Max
Re: Severity levels
2009/5/3 Nicklas Börjesson : > >>I disagree. When first introduced to them, I found the severity levels >>to be suitably vague to make me read the definitions. Once I read >>them, it was clear to me what each level means. > > Suitably? Do you mean that the severity levels are the way they are to make > people read their definitions? :-) > > Jokes aside, that's exactly what I don't want. > I want them to be even more vague(Low, Medium, High and Critical) and without > any definitions except for the highest level. > This way, one will elicit more how the user perceives the overall impact of > the bug, without having to shoehorn them into some level that only partly > matches their impression. Done with the help of the users indisputable > "common sense", of course. So you suggest making the severity ratings meaningless to anyone but ... well, you don't actually mention anyone knowing what they *really* mean, but I assume an exclusive clique of developers or bugzilla admins? Users have different opinions on what level of bug they encounter depending on what *task* they're trying to perform, which is not particularly useful to developers who need strict reproducability. > Also, the priority flag should not be visible to the user by default, it > should be a strangely named setting somewhere in the user preferences. It already is a strangely named setting, but the user preferences is far from the right place for it. It still has to be on a per-bug level, and although it may not be the most useful option on bugs it is still used by developers in-the-know, so maybe an additional message that says "Don't change the priority setting unless you know exactly what you're doing"? It's academic anyway, as the priority can be appropriately adjusted later. >>But bear in mind the severity levels are there >>to help the developers categorise the bugs, and they are not there to >>provide feedback to the average non-coding user. > For categorisation, there could be a separate category flag if the > "component" categorisation + priority wouldn't suffice. There already is a separate category flag. It's called "severity" and it indicates roughly the amount of *functionality* lost due to the bug. "Priority" does not indicate the severity of a bug; a bug may have low priority due to limitations outside of Wine (such as some blocker bugs for copy-protection systems which can't be supported in Wine). > Whatever. There are many ways to do it. But currently, the users' impression > of the problem get lost and/or skewed. You're not going to like this, but users don't matter quite *that* much on bugzilla. The bug tracker is a developer's tool, and although users are essential to the process (submitting bugs and new information on request), it should be designed as a developer's tool. A user's impression of their problem is irrelevant to the hard data they can provide about lost or missing functionality.
Re: Giving up for now
On Sun, May 3, 2009 at 2:44 AM, Ben Klein wrote: > 2009/5/3 Joel Holdsworth : >> On Sat, 2009-05-02 at 22:56 +0200, Roderick Colenbrander wrote: >>> Why again did you need this specific alphablend method? The icon can't >>> be converted to use some basic color keying for transparency or so? >> >> The reason is that the outlines will look aliased, and there will be no >> drop-shadows - without alpha the Tango icons won't look better than the >> current set. Also, I figured that icon rendering should be fixed for the >> sake of wine as a whole - which I think it should. It seems like a good >> little task for a wine beginner, and indeed I've made a lot of progress >> - I'm just a bit stuck. >> >> The culprit is a transfer through StretchDIBits in user32 which strips >> the alpha channel. I can't see a way round it - using StretchBlt doesn't >> help, and neither does GdiTransparentBlt. >> >> Another insentive: I suspect fixing this would also fix bug #201 which >> is now over 8 years old! > > What format are your Tango icons in? Are you converting them to .ICO > files as you go, or leaving them in PNG/some other known alpha channel > supporting format? > > > We do support some alpha support using XRender, can't you use this too? I think that's the general method for using alpha at the moment on X. Roderick
Re: [shell32] stub for ExtractVersionResource16W
2009/5/3 Dmitry Timoshkov : > "Stefan Leichter" wrote: > >>> Also you might be interested that according to >>> >>> http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shell32/h >>> istory/names351.htm ExtractVersionResource16W is discontinued starting >>> from >>> Windows Vista. >> >> What does the second point means for wine? > > That means that if Microsoft has dropped that API from Vista, > all apps that use it no more will function on Vista and newer > Windows generation. Therefore Wine is free to drop it as well. Not really. Wine is designed to run Windows programs on Linux, Mac, BSD and OpenSolaris platforms. That means that if an application is using this API, then Wine should support it. If this is Wine making the call internally (and no applications explicitly depend on it), then the API can be dropped from Wine as well. - Reece
Re: RFC on Base Wine Config
Am Sonntag, 3. Mai 2009 13:42:24 schrieb Paul TBBle Hampson: > The point made as I recall it in the earlier thread is that this is a > false sense of security, and that apps can already get outside the drive > mappings for filesystem access. > > I don't know how, but that was the point that was made. Linux syscalls. A Windows app can happily call int 0x80 to do whatever a Linux app running with the same permissions can do. It requires the app to be aware of Wine though.
Re: RFC on Base Wine Config
On Sun, May 03, 2009 at 08:54:32PM +1000, Ben Klein wrote: > 2009/5/3 Paul TBBle Hampson : >> On Sun, May 03, 2009 at 03:07:35PM +1000, Ben Klein wrote: >>> It's NOT a networked drive, is it? Drive mappings are the only way to >>> tell Wine and apps running in Wine where your files are in your >>> host-system (Unix-style) filesystem. >> The discussion on wine-devel in April related to bug 15883 suggested the >> implementation of \\?\unix\ which would in turn allow programs access to >> things that aren't mapped in the DosDevices list, unless specifically >> disallowed (which wasn't discussed at the time) >> A quick look at [1] suggests that \\?\unix\etc/hostname would seem to be >> a reasonable thing to expect to work under Wine. > But that requires either > 1) the app to be aware of \\?\unix, or This would be rather badly broken. The point of \\?\ is that apps (and in fact the Win32 API) doesn't parse such paths, but passes them on to the filesystem. > 2) Wine to map \\?\unix/foo/bar when no drive mapping to /foo/bar exists. The _point_ is that if Wine sees a \\?\unix/foo/bar path, it operates upon the file at /foo/bar, irrespective of the drive mappings. > #2 would also require some way to be configured to allow the > equivalent of removing the default Z: drive mapping for people who > want it. However, it would not provide any additional functionality > and could easily be considered a waste of time. Of course, that's not > up to me ;) The point of \\?\unix is not to add functionality, it's to allow removal of current functionality, specifically the magic recognition of "/x/y" as a unix path instead of "X:/x/y" with X as the drive of the current working directory, in order to fix bug 15883. >>> Note that it would be a breach of security to allow some method to >>> access / without a direct mapping in dosdevices. >> How so? I'm fairly sure this suggestion was dismissed in the >> above-mentioned email discussions as well. > AFAIK, the main reason people remove the Z: mapping is a security > concern. It's not an issue for me, but some people like to restrict > the files that win32 apps can access to a subdirectory in $HOME. If > there's some workaround to access files outside the drive mapping > (assuming pure win32 of course :D ), then unless it can be disabled by > the user, it's a security breach. The point made as I recall it in the earlier thread is that this is a false sense of security, and that apps can already get outside the drive mappings for filesystem access. I don't know how, but that was the point that was made. Off the top of my head, there's Win32 APIs that let you enumerate and map physical disk devices to DOS drive letters. So you could just readd Z:\ in your app if you wanted. Frankly I would like to break that illusion of security by providing \\?\unix, if I find the time. (The hard part is identifying all the parts of Wine that use the '/' recognition to function) -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpu3IVPdz8Wi.pgp Description: PGP signature
Re: Severity levels
2009/5/3 Nicklas Börjesson : > Ok..you seem to have misunderstood the tone in my mail. > >>Without common sense, all bug reports would be "Enhancement" requests, >>or "Critical", depending on how arrogant the reporter is. Common sense >>must *always* be applied. > > I should be needed to be applied only to the least possible amount. One > should never have to think for no reason. > The more "common sense" that have to be applied to make something work, the > less something works by itself. > Of course, you can't completely do away with common sense. I said "without > common sense" to point out the problems. > And, well, some have less common sense. Or a different kind. Or are just > tired, stressed out or something else. > So, the less common sense needed, the better, IMO. My other point is that > reporters are like to become less technical. > >> Oh, and use "Reply to all" so you stop just hitting Austin with responses! > > Huh? The mailing list is cc:d, Isn't that enough? I mean, it looks on you > mail you mailed me and cc:d? > Doesn't the mailing list propagate messages if it is only cc:d? > Have I misunderstood something? In that case I am sorry. My apologies. I received Austin's responses before receiving your original emails. >>Rosanne is an AppDB admin. What contribution have you made to Wine? >>Out of you and her, I don't think her credibility can be called in to >>question. And before you ask, I'm also an AppDB admin, I package the >>Debian packages for WineHQ, and have had a patch committed to Wine. >>I'll even send you the git revision code if you can't find it! :D > >>Note that like Rosanne, even when I was a newbie submitting bug >>reports, I understood the severity levels because I read the >>descriptions. The descriptions are fine as is, with the possible >>exception of "Blocker" (people submit "Blocker" bugs for "Normal" >>issues because it blocks the thing that they're doing). > > It's seems you missed the ":-)". I put in the end of the sentence on > credibility. > It was a joke and she seems to have took it that way, since she joked back. > With regards to the severity levels, to me, none of them means what one would > think they do intuitively. I disagree. When first introduced to them, I found the severity levels to be suitably vague to make me read the definitions. Once I read them, it was clear to me what each level means. Either way, severity levels can be changed, and often are due to user responses on the bugs. But bear in mind the severity levels are there to help the developers categorise the bugs, and they are not there to provide feedback to the average non-coding user.
Re: RFC on Base Wine Config
2009/5/3 Paul TBBle Hampson : > On Sun, May 03, 2009 at 03:07:35PM +1000, Ben Klein wrote: >> It's NOT a networked drive, is it? Drive mappings are the only way to >> tell Wine and apps running in Wine where your files are in your >> host-system (Unix-style) filesystem. > > The discussion on wine-devel in April related to bug 15883 suggested the > implementation of \\?\unix\ which would in turn allow programs access to > things that aren't mapped in the DosDevices list, unless specifically > disallowed (which wasn't discussed at the time) > > A quick look at [1] suggests that \\?\unix\etc/hostname would seem to be > a reasonable thing to expect to work under Wine. But that requires either 1) the app to be aware of \\?\unix, or 2) Wine to map \\?\unix/foo/bar when no drive mapping to /foo/bar exists. #2 would also require some way to be configured to allow the equivalent of removing the default Z: drive mapping for people who want it. However, it would not provide any additional functionality and could easily be considered a waste of time. Of course, that's not up to me ;) >> Note that it would be a breach of security to allow some method to >> access / without a direct mapping in dosdevices. > > How so? I'm fairly sure this suggestion was dismissed in the > above-mentioned email discussions as well. AFAIK, the main reason people remove the Z: mapping is a security concern. It's not an issue for me, but some people like to restrict the files that win32 apps can access to a subdirectory in $HOME. If there's some workaround to access files outside the drive mapping (assuming pure win32 of course :D ), then unless it can be disabled by the user, it's a security breach.
Re: Romanian translation (again)
2009/5/3 André Hentschel : > Dimitriu Petru schrieb: >> >> I'm here again for the Romanian translation of Wine. >> I only want somebody to change in the translation "Proprietă?i pentru" >> with "Proprietăţi pentru" because it shows ugly in ReactOS. >> >> Thanks in advance, >> Petru >> >> >> > > Patch sent: > http://www.winehq.org/pipermail/wine-patches/2009-May/072559.html > Thank you, André Hentschel.
Re: Romanian translation (again)
2009/5/3 Dimitriu Petru > I'm here again for the Romanian translation of Wine. > I only want somebody to change in the translation "Proprietă?i pentru" > with "Proprietăţi pentru" because it shows ugly in ReactOS. > > Thanks in advance, > Petru > > > you can send translations patches to wine (you don't need to be worried to work for reactOS for this kind of patches, if that's your problem), no need to ask other people to make the patches :P
Re: [shell32] stub for ExtractVersionResource16W
"Stefan Leichter" wrote: Also you might be interested that according to http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shell32/h istory/names351.htm ExtractVersionResource16W is discontinued starting from Windows Vista. What does the second point means for wine? That means that if Microsoft has dropped that API from Vista, all apps that use it no more will function on Vista and newer Windows generation. Therefore Wine is free to drop it as well. -- Dmitry.
Re: Romanian translation (again)
Dimitriu Petru schrieb: I'm here again for the Romanian translation of Wine. I only want somebody to change in the translation "Proprietă?i pentru" with "Proprietăţi pentru" because it shows ugly in ReactOS. Thanks in advance, Petru Patch sent: http://www.winehq.org/pipermail/wine-patches/2009-May/072559.html
Re: RFC on Base Wine Config
On Sun, May 03, 2009 at 03:07:35PM +1000, Ben Klein wrote: > It's NOT a networked drive, is it? Drive mappings are the only way to > tell Wine and apps running in Wine where your files are in your > host-system (Unix-style) filesystem. The discussion on wine-devel in April related to bug 15883 suggested the implementation of \\?\unix\ which would in turn allow programs access to things that aren't mapped in the DosDevices list, unless specifically disallowed (which wasn't discussed at the time) A quick look at [1] suggests that \\?\unix\etc/hostname would seem to be a reasonable thing to expect to work under Wine. > Note that it would be a breach of security to allow some method to > access / without a direct mapping in dosdevices. How so? I'm fairly sure this suggestion was dismissed in the above-mentioned email discussions as well. [1] http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ --- pgpxfSm1NQhcW.pgp Description: PGP signature
Romanian translation (again)
I'm here again for the Romanian translation of Wine. I only want somebody to change in the translation "Proprietă?i pentru" with "Proprietăţi pentru" because it shows ugly in ReactOS. Thanks in advance, Petru
Re: Severity levels
2009/5/2 Nicklas Börjesson : >>> 2. Critical "Critical problem that prevents all applications from working" >>> >>> - Possible, if everyone stopped testing code completely, and also unlikely >>> to be reported by a user. > >>No, critical bugs are usually opened by non-Linux users. > > Here I did search, and actually, most bugs have "linux" as an operating > system so I couldn't come to that conclusion. > Anyway, I get your point. Still don't really see why this is a separate > severity level, though. > Wouldn't this be a "wineloader" component or something? Not all critical bugs are caused by the loader. It's possible for d3d/ole/etc. to have a similar effect. >>> 3. Major "Major loss of functionality for a wide range of applications >>> >>> - Isn't this just all bugs that has more than $arbitrary_number of >>> applications linked to them? An aggregate, >>> rather than a level? > >>No, it's actually what it say, a WIDE RANGE of applications. > > Ok..I just thought that "wide range" could be translated into a number or > percentage instead of an expression. > I thought the opposite way...but couldn't possibly all bugs in wine affect a > wide range of appliacations? Sure, it's just not as common as you'd think. >> Bugzilla is to track bugs, it's not a user support forum, and the bugs >> should be classified as the dev's want them to be classified. > > No, I know it is not a support forum(Is users using is as such a big > problem?). You'd be surprised... > But it is nevertheless an interface towards the users of wine. A place they > go to when all else has failed(hopefully). > And as such it is utterly confusing(for them) and already leads to pointless > misunderstandings and frustrations > regarding, for example, the severity flag. > > Anyway. I can't help but feel that we are on completely different pages in > many ways. > I think that the users should have quite a say with regards to how important > a bug is, because for every user > putting in the (considerable for a user) effort of reporting a bug, there are > dozens that don't say anything at all. > In wine's case, because of it's size, this might actually be hundreds. It's > badwill. > > So currently, there is no way at all for users to influence these priorities. > To me, user priorities would be a > considerable factor, obviously not the only one, but considerable. > I know that wine, to a large extent, Is maintained by unpaid individuals(like > myself) that want to prioritize themselves. > I don't want to take that right away from them, I just feel that it's bad > practice to disregard the users' priorities. Keep in mind, most developers are unpaid as well. They're the ones fixing the bugs, not users. While users are important, no work gets done without the developers. Developers have no way to prioritize one user over another. The best way to prioritize *your* bug is to make a *good* bug report. Make sure all needed information is included. Get a testcase if possible. Provide the needed traces, etc. Even better, is to write a patch yourself. The source is there, and there is nothing stopping you from writing a patch. As a developer that spends more time testing than coding/etc., I see both sides of the coin. But keep in mind, that there are thousands of users, and just as many applications. Prioritizing one user/application over the other is almost always impossible, for obvious reasons. Picking your bug instead of Bob's bug just pisses Bob off, and vice versa. So how is most bug fixing done? Developers big bugs that interest them, that affect them personally, or that have good bug reports, which makes it fixing it much easier on them. -- -Austin
RE: Severity levels
Ok..you seem to have misunderstood the tone in my mail. >Without common sense, all bug reports would be "Enhancement" requests, >or "Critical", depending on how arrogant the reporter is. Common sense >must *always* be applied. I should be needed to be applied only to the least possible amount. One should never have to think for no reason. The more "common sense" that have to be applied to make something work, the less something works by itself. Of course, you can't completely do away with common sense. I said "without common sense" to point out the problems. And, well, some have less common sense. Or a different kind. Or are just tired, stressed out or something else. So, the less common sense needed, the better, IMO. My other point is that reporters are like to become less technical. > Oh, and use "Reply to all" so you stop just hitting Austin with responses! Huh? The mailing list is cc:d, Isn't that enough? I mean, it looks on you mail you mailed me and cc:d? Doesn't the mailing list propagate messages if it is only cc:d? Have I misunderstood something? In that case I am sorry. >Rosanne is an AppDB admin. What contribution have you made to Wine? >Out of you and her, I don't think her credibility can be called in to >question. And before you ask, I'm also an AppDB admin, I package the >Debian packages for WineHQ, and have had a patch committed to Wine. >I'll even send you the git revision code if you can't find it! :D >Note that like Rosanne, even when I was a newbie submitting bug >reports, I understood the severity levels because I read the >descriptions. The descriptions are fine as is, with the possible >exception of "Blocker" (people submit "Blocker" bugs for "Normal" >issues because it blocks the thing that they're doing). It's seems you missed the ":-)". I put in the end of the sentence on credibility. It was a joke and she seems to have took it that way, since she joked back. With regards to the severity levels, to me, none of them means what one would think they do intuitively. //Nicklas PS. I am sorry if I have broken the rules of this list, but I thought I followed them. I hope you don't let this detract from my arguments. DS.
RE: Severity levels
>I think "middle-aged college English teacher who couldn't code if her life >depended on it" counts as non-technical. :-) The only thing that sets me >>apart from most users is the fact that I actually do RTFM, but that's just >because I'm one of those eccentric academics who thinks reading is a >really >good way to learn. Reading? But you are going to end up all cross-eyed, dear? Everything I know about programming I have learned from stories my parents told me as a kid. And they heard them from their parents and now I am passing it on to my 3-year old daughter. She is very much into the older Windows API:s right now and just wants to hear that story about oleacc.dll again and again and again.
RE: Severity levels
>The problem is, however, that many of those problems only break an >application or two. What is a blocker for Photoshop isn't a blocker >for World of Warcraft or Microsoft Office, for example. You mean because Photoshop often use the more obscure parts of the APIs? Otherwise bugs in GUI shouldn't be less contagious than other kinds. Unless one regards UE issues as less severe, that is... :-) Anyway, I fail to see how this connects to the severity level discussion? >Please bottom post on wine mailing lists. Yep. But I was top posted earlier so I got confused. Also I am in a crappy exchange web mail client.. I hope you managed to read this post better. //Nicklas
RE: Severity levels
Not applications, issues. My point is that user experience issues gets a lower severity than they should. Let's take photoshop CS 4 with two old but relevant actual issues as an example. 1. There is a problem with the text tool functionality, it did not work. Everything else works, though. 2. There are serious graphics problems, huge artifacts, the entire application is almost unworkable under Gnome. With the current severity levels(without common sense), example 1 gets higher priority, which I think is wrong. //Nicklas PS. Yes I know the actual issue turned out to be a configuration thing. But that's not the point. DS. -Original Message- From: Austin English [mailto:austinengl...@gmail.com] Sent: Sat 2009-05-02 20:56 To: Nicklas Börjesson Cc: wine-devel@winehq.org Subject: Re: Severity levels 2009/5/2 Nicklas Börjesson : >>Wine is meant to support _ALL_ windows applications. It doesn't give >>priority to 'server' or 'desktop' applications (there is no >>difference, really), but instead tries to make all of them work. > > Yes, but I wasn't talking about server applikations per se, but that the > severity levels would be perfect for a server application, hence skewing the > priorities away from GUI and other, more "soft", user experience issues. I'm curious what non-gui applications you're talking about in regards to wine. -- -Austin
RE: Severity levels
The normal user doesn't even understand that the definitions should be read, most people think they know what "trivial", "minor","normal","major" means anyway. I actually discussed this with some friends recently. I just think that it could be more user-oriented. Non-technical? Posting on and following the wine-devel list? Severity levels perfectly clear? I must say, you've got some serious credibility issues.. :-) //Nicklas -Original Message- From: Rosanne DiMesio [mailto:dime...@earthlink.net] Sent: Sat 2009-05-02 19:09 To: Ken Sharp Cc: Nicklas Börjesson; wine-devel@winehq.org Subject: Re: Severity levels > > This is way easier to understand for normal people. Speaking as a non-technical user who does file bug reports now and then, I have always found the definitions of the severity levels to be perfectly clear, even when I was new to Wine, and from what I've seen, when a reporter sets the wrong severity level, it's usually because they didn't bother to read the definitions in the first place. -- Rosanne DiMesio
RE: Severity levels
>Wine is meant to support _ALL_ windows applications. It doesn't give >priority to 'server' or 'desktop' applications (there is no >difference, really), but instead tries to make all of them work. Yes, but I wasn't talking about server applikations per se, but that the severity levels would be perfect for a server application, hence skewing the priorities away from GUI and other, more "soft", user experience issues. I am not specifically talking about Photoshop, either. I am talking about all GUI-centered applications. Yes, I read about that, huge kudos to Google for still being benevolent(and Dan of course). But. Listen. I am not here to try and get Photoshop CS 4 fixed, that's already done, it works great for me. It's just that I have some ideas on what I would think would be simple but effective changes of the bug reporting and don't give up easily. :-) //Nicklas
RE: Severity levels
Ok, I have made better posts. >> 1. Blocker "Blocks development and/or testing work" >> >> - Is this even possible? >Yes. I am sorry. Of course it is possible to have these problems. I thought it meant that it blocks ALL development and/or testing work(since it is above critical). In the list, there are mostly platform-specific issues. My mistake. >> 2. Critical "Critical problem that prevents all applications from working" >> >> - Possible, if everyone stopped testing code completely, and also unlikely >> to be reported by a user. >No, critical bugs are usually opened by non-Linux users. Here I did search, and actually, most bugs have "linux" as an operating system so I couldn't come to that conclusion. Anyway, I get your point. Still don't really see why this is a separate severity level, though. Wouldn't this be a "wineloader" component or something? >> 3. Major "Major loss of functionality for a wide range of applications >> >> - Isn't this just all bugs that has more than $arbitrary_number of >> applications linked to them? An aggregate, >> rather than a level? >No, it's actually what it say, a WIDE RANGE of applications. Ok..I just thought that "wide range" could be translated into a number or percentage instead of an expression. I thought the opposite way...but couldn't possibly all bugs in wine affect a wide range of appliacations? > Bugzilla is to track bugs, it's not a user support forum, and the bugs > should be classified as the dev's want them to be classified. No, I know it is not a support forum(Is users using is as such a big problem?). But it is nevertheless an interface towards the users of wine. A place they go to when all else has failed(hopefully). And as such it is utterly confusing(for them) and already leads to pointless misunderstandings and frustrations regarding, for example, the severity flag. Anyway. I can't help but feel that we are on completely different pages in many ways. I think that the users should have quite a say with regards to how important a bug is, because for every user putting in the (considerable for a user) effort of reporting a bug, there are dozens that don't say anything at all. In wine's case, because of it's size, this might actually be hundreds. It's badwill. So currently, there is no way at all for users to influence these priorities. To me, user priorities would be a considerable factor, obviously not the only one, but considerable. I know that wine, to a large extent, Is maintained by unpaid individuals(like myself) that want to prioritize themselves. I don't want to take that right away from them, I just feel that it's bad practice to disregard the users' priorities. //Nicklas PS. >Your line length needs fixing. I have to admit I sent this using my employers horrible web mail (no idea why it says 6.5 though, think it is 2005). We will pretty soon "exchange" it, though. :-) DS.
RE: Severity levels
I am not sure that common sense is the issue. I think it is a question of who you are and what you know. Among the ones submitting bugs now is a quickly rising percentage of normal-to-advanced end users, and that percentage is likely to rise even further, as Linux adoption rates increase. 10 million desktops is the last number I've heard..and people are learning how to report problems. Hell, my mom(77 years old) reported a bug a while ago. My point is, why not adapt the severity levels to the competence level of the submitters instead of having to correct them all the time, creating badwill? Can't the three highest severity levels just be removed? Are they relevant? 1. Blocker "Blocks development and/or testing work" - Is this even possible? 2. Critical "Critical problem that prevents all applications from working" - Possible, if everyone stopped testing code completely, and also unlikely to be reported by a user. 3. Major"Major loss of functionality for a wide range of applications - Isn't this just all bugs that has more than $arbitrary_number of applications linked to them? An aggregate, rather than a level? Then, the severity(or "impact") levels could be: Critical High Medium Low This is way easier to understand for normal people. Also, the definition of each level should not be all that clear(except maybe critical) either, the levels will be discussed anyway, so it is easier to motivate for the developers to grade down a bug without too much discussion. Because the more people start using wine to actually make a living, the more important it will be to them. One would think that vague levels would create more discussion, but according to my experience, and with end-users, it seems to work the other way. And yes, I know that the bug reporting system is used by the developers internally as well, but do you really use the first two levels so often that you need them(I hope not)? //Nicklas
Re: RFC on Base Wine Config
On Sunday 03 May 2009 07:07:35 Ben Klein wrote: > 2009/5/3 chris ahrendt : Replying to Ben's email as I didn't get Chris' email Ben replied to. I would also like to note that I don't appreciate the tone both of these emails are taking in the end. Please try to be civil. That being said, let me get to the technical part. > > I guess I am not being completely clear somewhat > > If I am in windows and go into explorer... > > We've been through this before. Wine is not Windows. In Wine, the > drive has to be mapped in dosdevices. > > go to a network drive. I do > > not nescisarily have to map that drive in order to run an application > > (so long as the DLLS it needs, if any, are not just on that drive). I > > can click the application > > and it runs. I realise this may be a fundamental difference between unix > > and windows but still they should theoretically run the same. The important part here is that your local drives are local drives. Don't confuse the Wine drive mappings with network drive mappings in Windows. Think about a Wine drive mapping like plugging a new hdd into your box. > > But you're NOT running the test from a network drive, are you? And > even if you were, you'd need some way to inform Wine that it's there, > which would be to map it to a drive. Does Wine even support > Windows-style shares? Nope. We could, but then you'd have to create a Samba share to allow us to use the directory. I'm pretty sure a wine drive mapping is easier and faster. > > Also from > > a command line I can do (I think if I am remembering correctly (been > > doing to much z work lately) ) //server/directory/app.exe and it will > > retrieve and run the app... (I think) That's a bit besides the point, as this is still a valid UNC path. Now imagine I've got a USB hdd with my app on it, and that's usually connected at U:, with my app being at U:\test\app.exe. Now the logic in Windows mapping my USB drive to U: is just what the wine dosdevice mapping is like. If I now tell windows to remove the USB device, my desktop link to U:\test\app.exe is not going to work anymore. > This message appears in your bug report: > > Warning: could not find DOS drive for current working directory > > '/home/cahrendt/wine-git/dlls/inetmib1/tests', starting in the Windows > > directory. Here my analogy would be a bit stretched, as in that you'd still manage to be on the USB drive while it's already been disconnected. But basically you're trying to run a program that's on a drive not connected to your wine "box". Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
