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

Re: Shuttleworth on Wine

by Austin English

2009/5/9 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >> http://socghop.appspot.com/student_project/show/google/gsoc2009/wine/t12402… >> http://www.nabble.com/SOC-2009%3A-Application-Test-Suite-tc22692224.html > > Interesting project. At my workplace, we use TestComplete for testing GUI-applications, > I have had some problems finding similar applications for Linux, which is kind of strange, > since X11 should make it really easy to create positively fantastic testing facilities. > > After reading about it, though, I still don't see what would be the point in downloading > the application as a part of the test, not being a part of the applications functionality. The idea is to make the test as automated as possible. That way anyone can run the tests, not just people with certain programs. -- -Austin

May 10, 2009

DIB Engine : Almost 100% working

by Massimo Del Fedele

Well, after some (many) bugfixes and additions, the mighty DIB Engine is almost 100% operational. On one of tested apps (MSN Messenger) it behaves even better than original one :-) For whom wish to test it, bug 421 page. Ciao Max

May 9, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

> http://socghop.appspot.com/student_project/show/google/gsoc2009/wine/t12402… > http://www.nabble.com/SOC-2009%3A-Application-Test-Suite-tc22692224.html Interesting project. At my workplace, we use TestComplete for testing GUI-applications, I have had some problems finding similar applications for Linux, which is kind of strange, since X11 should make it really easy to create positively fantastic testing facilities. After reading about it, though, I still don't see what would be the point in downloading the application as a part of the test, not being a part of the applications functionality. IMHO. //Nicklas

May 9, 2009

Re: Shuttleworth on Wine

by Austin English

2009/5/9 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > > >>It's the registering/download manager that makes it not useful. It's >>much harder to script all of that. > > Why script that? One doesn't need wine to download a file, right? > I really don't see what the point would be to test that. > Once you downloaded the file, you don't need to download that version > again. The only thing that needs testing is the actual running of that > file and the following installation. > Why test the Adobe website? > Or have I misunderstood you completely? http://socghop.appspot.com/student_project/show/google/gsoc2009/wine/t12402… http://www.nabble.com/SOC-2009%3A-Application-Test-Suite-tc22692224.html -- -Austin

May 9, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

>It's the registering/download manager that makes it not useful. It's >much harder to script all of that. Why script that? One doesn't need wine to download a file, right? I really don't see what the point would be to test that. Once you downloaded the file, you don't need to download that version again. The only thing that needs testing is the actual running of that file and the following installation. Why test the Adobe website? Or have I misunderstood you completely? //Nicklas

May 9, 2009

Re: Shuttleworth on Wine

by Austin English

2009/5/9 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >>Photoshop, however, is harder to test, >>since it doesn't have an easy free download available. > > Free photoshop trial download, you do need to register (and > download through the "download manager") though: > https://www.adobe.com/cfusion/tdrc/index.cfm?product=photoshop It's the registering/download manager that makes it not useful. It's much harder to script all of that. -- -Austin

May 9, 2009

Re: New icons for 1.1.21

by Warren Dumortier

2009/5/9 Scott Ritchie <scott(a)open-vote.org>: > Warren Dumortier wrote: >> >> Nice, however i have a little suggestion... >> Would it be possible to assign an icon to WINE when you select a >> program from the list? This would be nice! ;) > > Huh? It's not clear to me what you're referring to here. Which list? Which > icon? > > Thanks, > Scott Ritchie > Because i don't know how to explain it in english, i've made a little screenshot: http://i44.tinypic.com/2rcxriu.png Kind regards.

May 9, 2009

Re: New icons for 1.1.21

by Scott Ritchie

Warren Dumortier wrote: > > Nice, however i have a little suggestion... > Would it be possible to assign an icon to WINE when you select a > program from the list? This would be nice! ;) Huh? It's not clear to me what you're referring to here. Which list? Which icon? Thanks, Scott Ritchie

May 9, 2009

RE: Severity levels

by Nicklas Börjesson

>make sure you're sending >mails with the same address you're receiving them on. That would be it, thanks! I feel pretty silly, I had registered to the mailing list as nicklas_at_ws.se, but my sender is my long adress, nicklas.borjesson_at_ws.se. It did not use to be that way, I forgot that it had changed. I'll change my adress and hope that solves it. Sorry if I bothered you all. //Nicklas

May 9, 2009

Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)

by Vitaliy Margolen

Daniel Santos wrote: > I think I just need to create a working solution and propose it as a > patch. It's already possible - see task manager. The only requirement for disabling/enabling debug channels from within the progrm is the debug channel have to be enabled at the start (WINEDEBUG=+all). Vitaliy

May 9, 2009

Re: [2/2] kernel32: Fix GetVolumeNameForVolumeMountPointW to match Mountmgr

by Vitaliy Margolen

Few nitpicks about your patch. Guy Albertelli wrote: > + if (!(input = HeapAlloc( GetProcessHeap(), 0, i_size ))) > + { > + SetLastError( ERROR_NOT_ENOUGH_MEMORY ); > + goto err_ret; > + } > + memset( input, 0, i_size ); To zero out allocated memory you should use HEAP_ZERO_MEMORY allocation flag: input = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, i_size ); However there is no need to do any of that - do not just clear memory without a good reason. It takes time to do it, especially that you doing it several times. What you do need to do in your code is explicitly zero-terminate all strings you receive from mount manager after you copy them. > + p = (WCHAR *) input; This is wrong - types of "p" and "input" has nothing to do with each other. > + p = (WCHAR*)((char *)input + sizeof(MOUNTMGR_MOUNT_POINT)); > + input->DeviceNameOffset = (char *)p - (char *)input; > + memcpy( p, nonpersist_name, lstrlenW( nonpersist_name )*sizeof(WCHAR) ); > + input->DeviceNameLength = lstrlenW( nonpersist_name )*sizeof(WCHAR); This is ugly. You can write it like this: input->DeviceNameOffset = sizeof(*input); input->DeviceNameLength = lstrlenW( nonpersist_name ) * sizeof(WCHAR) memcpy( input + 1, nonpersist_name, input->DeviceNameLength ); > + /* is there space in the return variable ?? */ > + if ((o1->SymbolicLinkNameLength/sizeof(WCHAR))+2 > size) > + { > + SetLastError( ERROR_INVALID_PARAMETER ); > + goto err_ret; > + } This doesn't look right. There are several other error codes that more appropriate. You should expand your tests to check what native returns here. Also are you sure that "size" is in chars not bytes? > + /* make string null terminated */ > + p = (WCHAR*)((char*)volume + o1->SymbolicLinkNameLength); > + memset( p, 0, sizeof(WCHAR) ); Again ugly. You can write it like: volume[o1->SymbolicLinkNameLength / sizeof(WCHAR)] = 0; > + if (input) HeapFree( GetProcessHeap(), 0, input ); > + if (output) HeapFree( GetProcessHeap(), 0, output ); You do not need to check for pointer != NULL before freeing it. All free() functions already doing it. Vitaliy.

May 9, 2009

Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)

by Daniel Santos

What I'm proposing shouldn't interfere with that. However, my original proposal is lacking (as I discovered when trying it out) because most of the object files that use debug logging end up with a static struct __wine_debug_channel variable that can't be changed from libwine after initialization. I think I just need to create a working solution and propose it as a patch. Performance is a pretty huge issue where, especially when running with WINEDEBUG=+all, so whatever I come up with will have to be very performance sensitive. Either way, the idea is to provide a mechanism for dynamically changing debug channels. Since this isn't something that many people should need (and especially not end users) this should be disabled by default. --- On Fri, 5/8/09, André Hentschel <nerv(a)dawncrow.de> wrote: From: André Hentschel <nerv(a)dawncrow.de> Subject: Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags) To: daniel.santos(a)pobox.com, wine-devel(a)winehq.org Date: Friday, May 8, 2009, 7:07 AM The Problem with a pre-processor setting would be that the endusers may not be able to make good logs for the devs. At the moment you can say to a user "send a log using 'WINEDEBUG=commctrl wine program.exe'", the user doesnt have to know what he is doing exactly, but he sends a usefull text. That wouldnt be possible anymore as i understand it. Best regards André Hentschel Daniel Santos schrieb: > It would seem quite helpful for debugging odd situations to be able to turn debugging on and off programmatically. I like not having every debug class loaded in memory by default (and everything that goes with maintaining that global list), but it would seem quite helpful for troubleshooting, testing and debugging special cases (mostly where one doesn't have the sources of the troublesome app). > > Thus, perhaps __wine_dbg_set_channel_flags could add the debug channel to debug_options if it doesn't exist and even allow setting the default_flags (say by having a zero-length name in the channel argument) or even another function which would allow it. I'm not sure what thread synchronization implications this would bring about (and the associated costs of the sync objects), it seems it would require at the least the use of a critical section to modify the debug_options, but perhaps this can be a pre-processor driven option? The configure could have a --enable-dynamic-channels or some such that would set a pre-processor macro, etc. > > Alternatively, a cheaper (hackier) mechanism of thread-safety could be achived by having the debug_options be contained in a struct along with the nb_debug_options and have them heap-allocated so that the debug_options pointer could be changed in a single machine instruction. A similar mechanism (i.e., hack) could be use to free the old debug_options struct. That's ugly, but I'm just presenting options. > > Daniel > > > ------------------------------------------------------------------------ > > >

May 9, 2009

Re: New icons for 1.1.21

by IneedAname

On Fri, 08 May 2009 19:41:31 -0700 Scott Ritchie <scott(a)open-vote.org> wrote: > Anyway, please feel free to give way too much feedback :) I like then but not the one with the folder on. The gray colour just does not work for me.

May 9, 2009

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try3)

by Vitaliy Margolen

André Hentschel wrote: > now using SNDMSGW > --- > dlls/comctl32/listview.c | 1 - > dlls/comctl32/tests/listview.c | 8 ++++++++ > include/commctrl.h | 6 ++++++ > 3 files changed, 14 insertions(+), 1 deletions(-) > > +#define ListView_SetCheckState(hwndLV, iIndex, bCheck) \ > + { LVITEMA _LVi; _LVi.state = ((bCheck?2:1) << 12); _LVi.stateMask = LVIS_STATEIMAGEMASK;\ > + SNDMSGW(hwndLV, LVM_SETITEMSTATE, (WPARAM)(INT)(iIndex), (LPARAM) (LPLVITEMA)&_LVi);} If you using SendMessageW you must use W structures (LVITEMW not LVITEMA). Also why are you typecasting WP & LP two times? Vitaliy.

May 9, 2009

Re: New icons for 1.1.21

by Warren Dumortier

2009/5/9 Scott Ritchie <scott(a)open-vote.org>: > Hey everyone, > > I just wanted to say that the icon discussion I started a couple weeks back > has born even more fruit, and I'm really happy with the current state of the > icons that I'm now using in the 1.1.21 Ubuntu packages. I've attached them, > and will be sending them as patches soon as well. > > I'm still not quite done with them, and they will likely change a bit after > I get some UI feedback at the Ubuntu Developer Summit at the end of the > month, but in the meantime I think they're quite better than what we have. > > Unlike the ubuntustudio icons I found (and packaged with 1.1.20 as an > experiment), these should be a bit more visible (and fully tango-compliant). > In particular, the stem of the glass is no longer two semitransparent > pixels at normal 48x48 size, but instead has a full Tango border/inner brush > stroke. > > Smaller icons for the other standard sizes are being worked on as well, > however they have to be retouched individually to maintain the 1 pixel > border/brush stroke in the Tango style. Eventually I'll submit a patch for > our website's mini icon as well. > > Anyway, please feel free to give way too much feedback :) > > Thanks, > Scott Ritchie > > > > Nice, however i have a little suggestion... Would it be possible to assign an icon to WINE when you select a program from the list? This would be nice! ;)

May 9, 2009

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try3)

by Nikolay Sivov

André Hentschel wrote: > now using SNDMSGW > --- > dlls/comctl32/listview.c | 1 - > dlls/comctl32/tests/listview.c | 8 ++++++++ > include/commctrl.h | 6 ++++++ > 3 files changed, 14 insertions(+), 1 deletions(-) I still don't follow you. How will it run on systems without unicode support? In general it's better to correct all A-only macros to SNDMSG. This eliminates problem with missed SendMessageW and superfluous AtoW conversion when it's present. In native header ListView_SetCheckSate is implemented as a wrapper over ListView_SetItemState which in turn is defined as SNDMSG.

May 9, 2009

Re: Severity levels

by Henri Verbeet

2009/5/9 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >>When you're not subscribed to the list, your posts have to go through >>moderation. Sometimes that can take a while. > > I do subscribe to the list(and did, from the beginning). > Or maybe subscription is more than registering to the mailing list? > You also need to follow the confirmation link, of course, but if you receive mails from the list that should be ok. The only other obvious thing I can think of at the moment is to make sure you're sending mails with the same address you're receiving them on.

May 9, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

>Photoshop, however, is harder to test, >since it doesn't have an easy free download available. Free photoshop trial download, you do need to register (and download through the "download manager") though: https://www.adobe.com/cfusion/tdrc/index.cfm?product=photoshop I have only tried to install licensed versions myself, however the installation shouldn't be totally different, except for being a bit easier to start(not having to mount a dvd and so on). I think testing the trial version would be quite sufficient. //Nicklas

May 9, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

> a better strategy would be to target particular users who only > need one application that is almost working. At least, that's > what the model I wrote told me: > http://yokozar.org/blog/archives/48 That strategy(to no ones surprise) appeals to me, since it feels like common sense, and is close to how most of those I work/worked with think. But I am not sure it would have worked earlier in the project when having nearly working use cases would be less usual and when having broad, or no focus would make the project more interesting for its developers. Anyway, It seems likely to make the most number of users happy with the least amount of work. However, since some applications(no names) are very widespread/pirated AND close to working, it will have the effect of more or less officially focusing on certain applications, which i think would be hard to push through in this project for different reasons. To try and define the most usual "near working" use cases also means defining the most usual use cases since it then would be important to keep the "working" use cases from becoming "near working". To do that, one need needs user input which would make the project user centric. Of course, the *entire* project wouldn't have to have the same focus but it would be affected. I'd think that this would be good and appeal more to me and others as developers wanting to do good things(tm). But I know that many does not agree. //Nicklas

May 9, 2009

RE: Severity levels

by Nicklas Börjesson

>When you're not subscribed to the list, your posts have to go through >moderation. Sometimes that can take a while. I do subscribe to the list(and did, from the beginning). Or maybe subscription is more than registering to the mailing list?

May 9, 2009

RE: Severity levels

by Nicklas Börjesson

>I don't believe your earlier mains have been resent. I certainly >haven't received them. Ok, then it's ok. I was afraid that there was something wrong.

May 9, 2009

Re: Shuttleworth on Wine

by Austin English

2009/5/8 Scott Ritchie <scott(a)open-vote.org>: > We had "no application regressions" as a release goal for 1.0, more or less > - in practice that meant we were targeting every application users wanted to > test it on. But there were also 4 specific apps targeted too - IIRC stuff > like word viewer. In principle there's no reason an application like > Photoshop couldn't be considered release critical in much the same fashion > these were. Yes, the targets were Microsoft Word/Powerpoint viewer, while cheap and free to download, they're both actually pretty complex (office based). As a shameless plug, this is the kind of stuff I'm planning on testing this summer for Summer of Code. Photoshop, however, is harder to test, since it doesn't have an easy free download available. Adobe reader/photoshop album, however, may be a bit easier to test, and have the bonus of some similar bugs. If anyone has some simple applications that are easy to test (preferably, with no installer), shoot me an e-mail and I'll add it to my my list of applications to look at. -- -Austin

May 9, 2009

New icons for 1.1.21

by Scott Ritchie

Hey everyone, I just wanted to say that the icon discussion I started a couple weeks back has born even more fruit, and I'm really happy with the current state of the icons that I'm now using in the 1.1.21 Ubuntu packages. I've attached them, and will be sending them as patches soon as well. I'm still not quite done with them, and they will likely change a bit after I get some UI feedback at the Ubuntu Developer Summit at the end of the month, but in the meantime I think they're quite better than what we have. Unlike the ubuntustudio icons I found (and packaged with 1.1.20 as an experiment), these should be a bit more visible (and fully tango-compliant). In particular, the stem of the glass is no longer two semitransparent pixels at normal 48x48 size, but instead has a full Tango border/inner brush stroke. Smaller icons for the other standard sizes are being worked on as well, however they have to be retouched individually to maintain the 1 pixel border/brush stroke in the Tango style. Eventually I'll submit a patch for our website's mini icon as well. Anyway, please feel free to give way too much feedback :) Thanks, Scott Ritchie

May 9, 2009

Re: Shuttleworth on Wine

by Scott Ritchie

Ben Klein wrote: > 2009/5/8 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >> And the *rest* of the world DO revolve around a few applications. >> That is why they think so. > > No, the rest of the world does not revolve around a few applications, > it's just that the #1 complaint against free operating systems has > been traditionally "it won't run Photoshop". In my experience, most > people who argue this don't even care about it, and in fact some > people miss the point entirely and dismiss Wine as "not a solution", > because they expect it to run natively, fluidly, with complete desktop > integration etc. > The great thing about this is these are all solvable problems, even in the near term. Photoshop almost works. Desktop integration is almost there. I'm doing what I can to make Wine a very impressive piece of software to the point where its integration into the desktop seems completely natural. >>> Though, I must say, the majority of people I see/hear using Photoshop >>> *are* using it as a toy/hobby, not for 'real' work, i.e., a full time >>> job. >> I have the same impression. And most haven't paid for it either. >> Anyway, that really isn't important. > > Except that WineHQ does not officially support pirated software (it > may run, but you'll get no official help getting it to run or work > properly). > Internet Explorer: Free as in beer. Wine: Free as in speech. Photoshop: Free as in stolen. >> The important thing is that they want it, no why. > > As it stands, yes, the fact that they want it is more important than > why. It's also unimportant to Wine's goals (which is for *all* > applications to run, not just Photoshop), and should not be considered > a factor in determining when the next release is ready. > > We had "no application regressions" as a release goal for 1.0, more or less - in practice that meant we were targeting every application users wanted to test it on. But there were also 4 specific apps targeted too - IIRC stuff like word viewer. In principle there's no reason an application like Photoshop couldn't be considered release critical in much the same fashion these were. For practical reasons, however, we probably don't want to target particular applications just because they're popular - a better strategy would be to target particular users who only need one application that is almost working. At least, that's what the model I wrote told me: http://yokozar.org/blog/archives/48 Thanks, Scott Ritchie

May 9, 2009

Re: Severity levels

by Henri Verbeet

2009/5/9 Remco <remco47(a)gmail.com>: > 2009/5/9 Ben Klein <shacklein(a)gmail.com>: >> Still not your problem? Still feeling bullied, but this time by the >> mailing list server? >> >> I don't believe your earlier mains have been resent. I certainly >> haven't received them. > > My Gmail account tells me that all those mails are like 4 days old. > This has happened to me before. I thought it was a problem with Gmail, > but it may as well be the wine mailing list server, or something else > entirely. > When you're not subscribed to the list, your posts have to go through moderation. Sometimes that can take a while.

May 9, 2009

Re: Severity levels

by Remco

2009/5/9 Ben Klein <shacklein(a)gmail.com>: > Still not your problem? Still feeling bullied, but this time by the > mailing list server? > > I don't believe your earlier mains have been resent. I certainly > haven't received them. My Gmail account tells me that all those mails are like 4 days old. This has happened to me before. I thought it was a problem with Gmail, but it may as well be the wine mailing list server, or something else entirely. Remco

May 9, 2009

Re: Severity levels

by Ben Klein

2009/5/8 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > 2009/5/8 Austin English <austinenglish(a)gmail.com>: >> No offense, but you should probably take the lack of (repeated) >> responses as a sign. > > I did leave it alone. > That post was a reaction to what I considered as bullying. > The answers has almost never been to anything I have said, > but rather to things I haven't said. You've been repeatedly informed why your proposed changes to the severity levels are a bad idea by many people on this list. Let's take an analogy: Imagine you're a fresh, young car tester at Ford. Using an open-door policy to contact an executive, you promise a new, efficient design to replace the current combustion engines completely. You present your idea at a board meeting. The board is not receptive to your proposed changes. The engineering department doesn't believe it will solve any problems, and in fact that it will reduce fuel efficiency and increase pollution. The other board members point out that you're very new to the company, and that you have no experience in engine design or engineering and you are only present in the company as a tester. In this scenario, are you being bullied by the board members? > //Nicklas > PS. > No, I am new to the wine project. > But there is a world outside of it. > DS. You'd have some credibility if you researched what the Wine project does with bugzilla, how it currently works, etc. rather than just assuming it's the wrong way to do it. 2009/5/8 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > 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. Still not your problem? Still feeling bullied, but this time by the mailing list server? I don't believe your earlier mains have been resent. I certainly haven't received them.

May 9, 2009

Re: Shuttleworth on Wine

by Ben Klein

2009/5/8 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > And the *rest* of the world DO revolve around a few applications. > That is why they think so. No, the rest of the world does not revolve around a few applications, it's just that the #1 complaint against free operating systems has been traditionally "it won't run Photoshop". In my experience, most people who argue this don't even care about it, and in fact some people miss the point entirely and dismiss Wine as "not a solution", because they expect it to run natively, fluidly, with complete desktop integration etc. >>Though, I must say, the majority of people I see/hear using Photoshop >>*are* using it as a toy/hobby, not for 'real' work, i.e., a full time >>job. > > I have the same impression. And most haven't paid for it either. > Anyway, that really isn't important. Except that WineHQ does not officially support pirated software (it may run, but you'll get no official help getting it to run or work properly). > The important thing is that they want it, no why. As it stands, yes, the fact that they want it is more important than why. It's also unimportant to Wine's goals (which is for *all* applications to run, not just Photoshop), and should not be considered a factor in determining when the next release is ready.

May 9, 2009

possible-wrong return value of PdhMakeCounterPathA

by Joris Huizer

Obviously mostly a small and theoretical problem, but anyway: Looking at git commit 754b97c72c38f736100c6542af234c31a4bf7a5b, it seems, PdhMakeCounterPathA may be returning the wrong error in this case: Everything goes well until the allocation of bufferW. Assuming this fails, the function will return PDH_MORE_DATA, which seems the wrong error value (instead it should probably return PDH_MEMORY_ALLOCATION_FAILURE ? ) regards, Joris

May 8, 2009

Re: Shuttleworth on Wine

by IneedAname

On Fri, 8 May 2009 18:43:20 +0100 IneedAname <wineappdb(a)gmail.com> wrote: > Windows is not free. You can buy a EeePC running Linux that has 8GB more then the windows version. Both the Linux and Windows versions are at the same price. Sorry I send this email with out finishing it.

May 8, 2009

Re: Shuttleworth on Wine

by IneedAname

On Thu, 7 May 2009 16:47:32 +0100 David Gerard <dgerard(a)gmail.com> wrote: > Yes. The biggest problem for free-as-in-freedom software - Linux and > GIMP, and to some extent Wine - is that Windows and Photoshop are > effectively free-as-in-beer software ... > > http://autotelic.com/windows_is_free Windows is not free. You can buy a EeePC running Linux that has 8GB more then the windows version.

May 8, 2009

Re: comctl32/test: test CheckState Macros

by Vitaliy Margolen

Nikolay Sivov wrote: > No actually. Native uses ListView_SetItemState for that macro which is > SNDMSGA in wine and SNDMSG in native. He asked why his patch is not getting in - that's one of the reasons. You should always use SendMessageW where possible. Especially for things that don't care if it's A or W. This is to prevent extra A->W conversions. Vitaliy.

May 8, 2009

Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)

by André Hentschel

The Problem with a pre-processor setting would be that the endusers may not be able to make good logs for the devs. At the moment you can say to a user "send a log using 'WINEDEBUG=commctrl wine program.exe'", the user doesnt have to know what he is doing exactly, but he sends a usefull text. That wouldnt be possible anymore as i understand it. Best regards André Hentschel Daniel Santos schrieb: > It would seem quite helpful for debugging odd situations to be able to > turn debugging on and off programmatically. I like not having every > debug class loaded in memory by default (and everything that goes with > maintaining that global list), but it would seem quite helpful for > troubleshooting, testing and debugging special cases (mostly where one > doesn't have the sources of the troublesome app). > > Thus, perhaps __wine_dbg_set_channel_flags could add the debug channel > to debug_options if it doesn't exist and even allow setting the > default_flags (say by having a zero-length name in the channel > argument) or even another function which would allow it. I'm not sure > what thread synchronization implications this would bring about (and > the associated costs of the sync objects), it seems it would require > at the least the use of a critical section to modify the > debug_options, but perhaps this can be a pre-processor driven option? > The configure could have a --enable-dynamic-channels or some such that > would set a pre-processor macro, etc. > > Alternatively, a cheaper (hackier) mechanism of thread-safety could be > achived by having the debug_options be contained in a struct along > with the nb_debug_options and have them heap-allocated so that the > debug_options pointer could be changed in a single machine > instruction. A similar mechanism (i.e., hack) could be use to free > the old debug_options struct. That's ugly, but I'm just presenting > options. > > Daniel > > > ------------------------------------------------------------------------ > > >

May 8, 2009

Re: tools/winedump: sign compare fixes

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > -static const char *debugstr_wn(const WCHAR *wstr, int n) > +static const char *debugstr_wn(const WCHAR *wstr, uint n) > { > static char buf[80]; > char *p; > - int i; > + uint i; uint is not a standard type. Use "unsigned int" instead. -- Alexandre Julliard julliard(a)winehq.org

May 8, 2009

Re: comctl32/test: test CheckState Macros

by Nikolay Sivov

Vitaliy Margolen wrote: > André Hentschel wrote: > >> I made one patch out of them and improved my tests. >> now i wonder again why its not getting in... >> > > You should use SNDMSGW. > > Vitaliy. > > > No actually. Native uses ListView_SetItemState for that macro which is SNDMSGA in wine and SNDMSG in native.

May 8, 2009

Re: comctl32/test: test CheckState Macros

by Vitaliy Margolen

André Hentschel wrote: > I made one patch out of them and improved my tests. > now i wonder again why its not getting in... You should use SNDMSGW. Vitaliy.

May 8, 2009

Fwd: [Wine] How to Rip DVD and Convert video on OS X

by Austin English

I know it's been mentioned a few times on wine-users, and the signup question was recently changed, but is there anything else we can do to prevent the forum spam? It's getting a bit out of hand. There is at least one message similar to the below daily. -- -Austin ---------- Forwarded message ---------- From: rahul6 <wineforum-user(a)winehq.org> Date: Fri, May 8, 2009 at 1:31 AM Subject: [Wine] How to Rip DVD and Convert video on OS X To: wine-users(a)winehq.org Now portable devices can be seen everywhere. They don't take so much space and are easy to use. Many people use their devices such as iPod, iPhone, PSP, Mobile Phone, Zune, Creative Zen, iRiver, Sansa, etc. to be served as their DVD Players or Video players. But the first thing kept in mind is that most such devices can not support DVD and some other video formats. But it is not difficult, some third-party conversion software such as Mac DVD Ripper

May 8, 2009

RE: Severity levels

by Nicklas Börjesson

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

May 8, 2009

Re: Severity levels

by James McKenzie

IneedAname wrote: > > Wine does have meta bugs look at the application data base. Each application has a list of bugs that effect that program. > I think that you missed what a meta-bug is in the Bugzilla sense. A meta-bug would collect all of the applications affected by a particular problem, we do that by adding them to the comments area and closing out the duplicates. > Why Wine does not use meta bugs in bugzilla is because they end up being "Make my all programs work with wine! Now" list. > > Either that, or they get abused by folks adding bugs that have NOTHING to do with the original bug. In any case, meta-bugs are not allowed in Bugzilla, period. James McKenzie

May 8, 2009

Re: Severity levels

by Ben Klein

2009/5/8 richardvoigt(a)gmail.com <richardvoigt(a)gmail.com>: > 2009/5/7 Austin English <austinenglish(a)gmail.com> >> >> 2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: >> > Explained to me?? ...this is just incredible. >> > Regardless of what I have said, you have repeated almost the same >> > things, >> > it's like you haven't been reading my posts! Or that you're not reading other people's posts, like every time they mention the phrase "developers, not users", you assume the entire post is irrelevant to the discussion. >> > Leave me alone, I want to talk to someone else. I've said it before, you're one man against the world in this argument. >> Bugzilla is a developer's tool, with bugs reported by users. Severity >> levels are there for how they affect Wine *overall*, not the user >> experience. Such things belong in the AppDB/etc., not bugzilla. > > Having it in a field in bugzilla with a list of options is potentially a lot > better than expecting users to enter the information in the description > without being prompted. I'd suggest: > Application can't start. > (default) Something I need to do is broken, but enough of the app still > works to be useful for other tasks (e.g. a word processor with broken > equation editor). > The app is totally useless (e.g. a word processor with broken Open & Save > dialogs). > Part of the app is broken but I can work around the problems. This is not very useful to the people who matter on bugzilla (developers). "Something is broken" is too close to "The app is useless" (at best these would be Minor and Normal bugs, at worst both Normal) and "Part of the app is broken" is exactly the same as "Something is broken" except a workaround is present (this is guaranteed to be Minor). Users need to provide much more detail to their bug descriptions than this. Adding a field that describes the problem in a vague way will encourage users to minimise their descriptions (BAD). Imagine: "I already said that something is broken, why are you asking for more information? FIX IT! It's really important! I need it to live!" If any improvement can be made to the bug submission system, it would be to encourage users to provide *more* descriptive detail (especially for steps taken to reproduce the bug) in their initial report. Any suggestion for adding or modifying a field to indicate "Impact on user experience" will not affect that. > along with instructions to file installer bugs under "Installer for XYZ" > because installers have the same potential for partial breakage (can't > select install directory vs shows negative free space and refuses to install > at all) > This was already suggested, but the options addressed multiple orthogonal > issues (how usable is the app vs what kind of breakage) which someone > pointed out would be even more confusing. Keep the what broke in the > description where users will naturally report it, and provide only an impact > (hey that might not be a bad name for the field -- "impact") level in a new > dropdown list. It's been said before: bugzilla is not the place for this type of thing. The "impact on user experience" is not a factor in determining bug priorities, nor will it ever be. Remember, WineHQ is not a company, Wine is not proprietary, so Wine does not have to behave like a commercial product. If someone is willing to work on a bug, then patches will get submitted and reviewed. If the patches are well-formed and functional, and don't cause obvious regressions, then the patches are committed and the bug fixed. That's how collaborative open-source development works, especially in such massive projects as Wine.

May 8, 2009

Re: Severity levels

by richardvoigt＠gmail.com

2009/5/7 Austin English <austinenglish(a)gmail.com> > 2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > > Explained to me?? ...this is just incredible. > > Regardless of what I have said, you have repeated almost the same things, > > it's like you haven't been reading my posts! > > > > Leave me alone, I want to talk to someone else. > > No offense, but you should probably take the lack of (repeated) > responses as a sign. > > You've been answered several times by several people, and the answer > has been (mostly) the same. > > Bugzilla is a developer's tool, with bugs reported by users. Severity > levels are there for how they affect Wine *overall*, not the user > experience. Such things belong in the AppDB/etc., not bugzilla. Having it in a field in bugzilla with a list of options is potentially a lot better than expecting users to enter the information in the description without being prompted. I'd suggest: Application can't start. (default) Something I need to do is broken, but enough of the app still works to be useful for other tasks (e.g. a word processor with broken equation editor). The app is totally useless (e.g. a word processor with broken Open & Save dialogs). Part of the app is broken but I can work around the problems. along with instructions to file installer bugs under "Installer for XYZ" because installers have the same potential for partial breakage (can't select install directory vs shows negative free space and refuses to install at all) This was already suggested, but the options addressed multiple orthogonal issues (how usable is the app vs what kind of breakage) which someone pointed out would be even more confusing. Keep the what broke in the description where users will naturally report it, and provide only an impact (hey that might not be a bad name for the field -- "impact") level in a new dropdown list.

May 8, 2009

Dynamically adding debug channels (__wine_dbg_set_channel_flags)

by Daniel Santos

It would seem quite helpful for debugging odd situations to be able to turn debugging on and off programmatically. I like not having every debug class loaded in memory by default (and everything that goes with maintaining that global list), but it would seem quite helpful for troubleshooting, testing and debugging special cases (mostly where one doesn't have the sources of the troublesome app). Thus, perhaps __wine_dbg_set_channel_flags could add the debug channel to debug_options if it doesn't exist and even allow setting the default_flags (say by having a zero-length name in the channel argument) or even another function which would allow it. I'm not sure what thread synchronization implications this would bring about (and the associated costs of the sync objects), it seems it would require at the least the use of a critical section to modify the debug_options, but perhaps this can be a pre-processor driven option? The configure could have a --enable-dynamic-channels or some such that would set a pre-processor macro, etc. Alternatively, a cheaper (hackier) mechanism of thread-safety could be achived by having the debug_options be contained in a struct along with the nb_debug_options and have them heap-allocated so that the debug_options pointer could be changed in a single machine instruction. A similar mechanism (i.e., hack) could be use to free the old debug_options struct. That's ugly, but I'm just presenting options. Daniel

May 7, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Dewdman42

Thanks for that. Hope we can get to the bottom of the issue. Ken Thomases wrote: > > On May 6, 2009, at 11:20 PM, Dewdman42 wrote: > > As far as I know, only Emmanuel Maillard has touched the MIDI code in > the Core Audio driver. I'm CC'ing him, just to be sure he sees this. > > Cheers, > Ken > > -- View this message in context: http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… Sent from the Wine - Devel mailing list archive at Nabble.com.

May 7, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Steve Schow

Thanks a lot for that. Would be nice to get to the bottom of this issue and I am happy to run some tests if he can help me set debug flags or whatever to figure it out. On May 7, 2009, at 1:14 PM, Ken Thomases wrote: > On May 6, 2009, at 11:20 PM, Dewdman42 wrote: > >> Does anyone know if Darwine can be fixed to handle virtual midi ports >> correctly? They work very sporadically right now. It seems to be >> related >> to getting the ports flushed or initialized or something. When >> there is a >> virtual midi port present (under OSX), Wine seems to see it and >> lists it as >> an available midi port, but I have not been able to consistently >> get that >> port to function correctly. Sometimes it does and sometimes it >> doesn't and >> it seems to related to switching it on and off in some fashion >> makes it >> work, though I can't seem to find a pattern that will work >> consistently. >> >> All I can figure is that somehow Wine is not handling midi ports in >> a way >> that is compatible with OSX virtual midi ports. >> >> Anyone have any experience or knowledge in this area? > > As far as I know, only Emmanuel Maillard has touched the MIDI code > in the Core Audio driver. I'm CC'ing him, just to be sure he sees > this. > > Cheers, > Ken > ------------------------- Steve Schow steve(a)bstage.com 206-724-8083

May 7, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Ken Thomases

On May 6, 2009, at 11:20 PM, Dewdman42 wrote: > Does anyone know if Darwine can be fixed to handle virtual midi ports > correctly? They work very sporadically right now. It seems to be > related > to getting the ports flushed or initialized or something. When > there is a > virtual midi port present (under OSX), Wine seems to see it and > lists it as > an available midi port, but I have not been able to consistently get > that > port to function correctly. Sometimes it does and sometimes it > doesn't and > it seems to related to switching it on and off in some fashion makes > it > work, though I can't seem to find a pattern that will work > consistently. > > All I can figure is that somehow Wine is not handling midi ports in > a way > that is compatible with OSX virtual midi ports. > > Anyone have any experience or knowledge in this area? As far as I know, only Emmanuel Maillard has touched the MIDI code in the Core Audio driver. I'm CC'ing him, just to be sure he sees this. Cheers, Ken

May 7, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

>I think you're seriously underestimating Wine, and the amount of >'real' work it can accomplish. The world doesn't revolve around Adobe >products, contrary to what many recent converts to GNU/Linux may >think. As usual, I am not talking about myself, but people in generals' perception of it, which reflected quite well in Shuttleworths comments. Whatever you think of the guy, remember he was a developer on the Debian project in the nineties. He's not totally unitiated. And I don't think he is unique in any way. Also, (quoting http://www.winehq.org/about/) "Wine is still under development, and it is not yet suitable for general use." Doesn't say stability. Especially when the version has passed 1.0. And the *rest* of the world DO revolve around a few applications. That is why they think so. >Though, I must say, the majority of people I see/hear using Photoshop >*are* using it as a toy/hobby, not for 'real' work, i.e., a full time >job. I have the same impression. And most haven't paid for it either. Anyway, that really isn't important. The important thing is that they want it, no why.

May 7, 2009

RE: Severity levels

by Nicklas Börjesson

>No offense, but you should probably take the lack of (repeated) >responses as a sign. I did leave it alone. That post was a reaction to what I considered as bullying. The answers has almost never been to anything I have said, but rather to things I haven't said. //Nicklas PS. No, I am new to the wine project. But there is a world outside of it. DS.

May 7, 2009

Re: msvcrt crash issue, tracing

by Austin English

On Tue, May 5, 2009 at 6:08 PM, Kjell Rune Skaaraas <kjella79(a)yahoo.no> wrote: > 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. Add traces to the untraced functions. > 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? +relay? -- -Austin

May 7, 2009

Re: Severity levels

by Austin English

2009/5/3 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > Explained to me?? ...this is just incredible. > Regardless of what I have said, you have repeated almost the same things, > it's like you haven't been reading my posts! > > Leave me alone, I want to talk to someone else. No offense, but you should probably take the lack of (repeated) responses as a sign. You've been answered several times by several people, and the answer has been (mostly) the same. Bugzilla is a developer's tool, with bugs reported by users. Severity levels are there for how they affect Wine *overall*, not the user experience. Such things belong in the AppDB/etc., not bugzilla. Again, no offense, but you're relatively unknown to the Wine project. Looking for your name in the git log shows no records. The only place I recognize your name from is this thread and from bugzilla bugs. Trying to tell all of Wine's developers that the way they've been handling bug reports has been wrong for years is a bit pompous. Granted, I'm not saying it can't be improved. Surely it can. But, as has been said before, Bugzilla is there for developers, not user's. Lastly, as I said before, I encourage you to subscribe to wine-bugs/patches/devel/users and keep up with everything going on in wine. See how many bug reports we have, what they describe, and the quality of them. It helps to have experience seeing these bug reports before arbitrarily saying how the system should be changed. The horse has been beaten way past the point of Jell-O. Can we put this to a rest, please? -- -Austin

May 7, 2009

Re: Shuttleworth on Wine

by David Gerard

2009/5/7 Austin English <austinenglish(a)gmail.com>: > Though, I must say, the majority of people I see/hear using Photoshop > *are* using it as a toy/hobby, not for 'real' work, i.e., a full time > job. Yes. The biggest problem for free-as-in-freedom software - Linux and GIMP, and to some extent Wine - is that Windows and Photoshop are effectively free-as-in-beer software ... http://autotelic.com/windows_is_free - d.

May 7, 2009

Re: [5/5] wined3d: Add support for immediate constants to the GLSL backend.

by Henri Verbeet

2009/5/7 Stefan Dösinger <stefandoesinger(a)gmx.at>: > 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? > I think it's a bug in that specific version of the driver, but haven't heard back from Alexandre.

May 7, 2009

Re: Shuttleworth on Wine

by Austin English

2009/5/6 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>: > If I were the leader of the wine project, the moment photoshop CS4 works all the way, that would be the basis of the next stable version(to avoid regessions to the highest degree).. As has been said plenty of times before, we don't want to base Wine releases around particular applications. > I believe that the popularity of wine(yes, popularity is extra important for a FOSS project) would skyrocket. > Then it would be a toy no more. I think you're seriously underestimating Wine, and the amount of 'real' work it can accomplish. The world doesn't revolve around Adobe products, contrary to what many recent converts to GNU/Linux may think. Though, I must say, the majority of people I see/hear using Photoshop *are* using it as a toy/hobby, not for 'real' work, i.e., a full time job. -- -Austin

May 7, 2009

Re: Resend of xinput patch for bug 18218

by Austin English

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

May 7, 2009

Re: [5/5] wined3d: Add support for immediate constants to the GLSL backend.

by Stefan Dösinger

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?

May 7, 2009

Re: comctl32/test: test CheckState Macros

by André Hentschel

Austin English schrieb: > 2009/5/5 André Hentschel <nerv(a)dawncrow.de>: > >> --- >> dlls/comctl32/tests/listview.c | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> > > This patch fails without your other patch. In the future, please > combine them into one patch, or number them in a series. > > Wine must compile and pass the tests before and after every patch. > > Howdy, I made one patch out of them and improved my tests. now i wonder again why its not getting in... I know these questions are ugly... A System would be cool, where Alexandre always could do a one-click select of tags why a patch dont get in... Things like that are a difficult subject, are there good solutions in other projects?

May 7, 2009

Re: [1/3](resend)msctf: implement ITfKeystrokeMgr::PreserveKey

by Alexandre Julliard

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

May 7, 2009

Re: gdiplus: use the mode passed to GdipCreateLineBrushFromRect

by Alexandre Julliard

"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

May 7, 2009

RE: Getting my test for DrawIcon and DrawIconEx included

by Ge van Geldorp

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.

May 7, 2009

Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.

by Alexandre Julliard

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

May 7, 2009

Re: resubmit: [PATCH] crypt32: change salt allocation to handle errors (Coverity 133)

by Alexandre Julliard

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

May 7, 2009

Re: notepad: Use the explicit W-form of the types.

by Michael Stefaniuc

Reece Dunn wrote: > 2009/5/7 Michael Stefaniuc <mstefani(a)redhat.de>: >> LoadString(Globals.hInstance, STRING_ERROR, szTitle, SIZEOF(szTitle)); >> FormatMessage( >> FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, >> - NULL, error, 0, >> - (LPTSTR) &lpMsgBuf, 0, NULL); >> + NULL, error, 0, (LPWSTR)&lpMsgBuf, 0, NULL); > > Shouldn't you be using FormatMessageW here? > > Also, should the LoadString call be fixed as well? Of course it should. I'm not finished yet; that will be a separate patch. bye michael

May 7, 2009

Re: notepad: Use the explicit W-form of the types.

by Reece Dunn

2009/5/7 Michael Stefaniuc <mstefani(a)redhat.de>: > LoadString(Globals.hInstance, STRING_ERROR, szTitle, SIZEOF(szTitle)); > FormatMessage( > FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, > - NULL, error, 0, > - (LPTSTR) &lpMsgBuf, 0, NULL); > + NULL, error, 0, (LPWSTR)&lpMsgBuf, 0, NULL); Shouldn't you be using FormatMessageW here? Also, should the LoadString call be fixed as well? - Reece

May 7, 2009

Re: Getting my test for DrawIcon and DrawIconEx included

by Nikolay Sivov

Joel Holdsworth wrote: > 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. > > Joel+ > Just a quick look: 1) + Sleep(200); + + return hWnd; +} + Why are you sleeping here? 2) Why do you need a window here? It seems that you use it only to retrieve HDC. 3) It's better to pass a LINE in such cases (to check_icon_draw helper): + todo_wine + { + check_icon_draw(hwnd, drawiconex, TRUE, 0xFFA0B0C0, 32, 0x00FFFFFF, 0x00C0B0A0); + + check_icon_draw(hwnd, drawiconex, FALSE, 0x80A0B0C0, 32, 0x00000000, 0x00605850); + check_icon_draw(hwnd, drawiconex, TRUE, 0x80A0B0C0, 32, 0x00000000, 0x00605850); + check_icon_draw(hwnd, drawiconex, FALSE, 0x80A0B0C0, 32, 0x00FFFFFF, 0x00DFD7CF); + check_icon_draw(hwnd, drawiconex, TRUE, 0x80A0B0C0, 32, 0x00FFFFFF, 0x00DFD7CF); + + check_icon_draw(hwnd, drawiconex, FALSE, 0x01FFFFFF, 32, 0x00000000, 0x00010101); + check_icon_draw(hwnd, drawiconex, TRUE, 0x01FFFFFF, 32, 0x00000000, 0x00010101); + check_icon_draw(hwnd, drawiconex, FALSE, 0xFEFFFFFF, 32, 0x00000000, 0x00FEFEFE); + check_icon_draw(hwnd, drawiconex, TRUE, 0xFEFFFFFF, 32, 0x00000000, 0x00FEFEFE); + } 4) How do these tests behave on older platforms < NT5 by means of alpha channel? Maybe it's handled somehow, put a comment about it please.

May 7, 2009

Getting my test for DrawIcon and DrawIconEx included

by 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. Joel

May 7, 2009

Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.

by Reece Dunn

2009/5/7 Rein Klazes <wijn(a)online.nl>: > On Thu, 7 May 2009 01:54:23 -0500, you wrote: > >>On Thu, May 7, 2009 at 1:52 AM, Rein Klazes <wijn(a)online.nl> wrote: >>> Fixes bug 10845 >>> >>> Changes from previous patch: menu position calculations moved to >>> nonclient.c. >> >>Can you add a testcase? > > I don't see what you would like to test. The menu->Height == zero has > the meaning "menusize needs recalculation" all over the code. That you > need to have the menu size right before doing a hittest (in > MENU_ButtonDown) is even more obvious. > > I expect the problem is more the form: touching sensitive nonclient > code. + /* eg if the application modified the menu in the WM_INITMENU message */ Does Wine have test cases for this workflow? Also, you mention needing it for the hit test, so can you test performing a hit test (if not, testing that it provides sensible values is useful)? It's not so much about touching sensitive nonclient code. It is about being able to say something like "if a program does this, Windows gives the menu a non-zero height, but Wine does not. This can be fixed by ...". The analogy I gave someone a while back is of a series of light bulbs, switches and a black box (http://www.mail-archive.com/wine-devel(a)winehq.org/msg38385.html) You may know, for example, that a function f is generating a sine wave (i.e. it is the sin function), but can you prove that? Tests let you verify that behaviour. What about edge cases? Is the argument in degrees or radians? If someone switched to an algorithm for f that used degrees instead of radians, how would you know that f is now broken? Or if they mistype one of the numbers, how would you know that it is incorrect? - Reece

May 7, 2009

Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.

by Nicolas Le Cam

2009/5/7 Rein Klazes <wijn(a)online.nl>: > On Thu, 7 May 2009 01:54:23 -0500, you wrote: > >>On Thu, May 7, 2009 at 1:52 AM, Rein Klazes <wijn(a)online.nl> wrote: >>> Fixes bug 10845 >>> >>> Changes from previous patch: menu position calculations moved to >>> nonclient.c. >> >>Can you add a testcase? > > I don't see what you would like to test. The menu->Height == zero has > the meaning "menusize needs recalculation" all over the code. That you > need to have the menu size right before doing a hittest (in > MENU_ButtonDown) is even more obvious. > > I expect the problem is more the form: touching sensitive nonclient > code. > > Rein. > > > Even if it's obvious that this is the right behavior, it's always useful to add a test, at least to prevent regressions. -- Nicolas Le Cam

May 7, 2009

Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.

by Rein Klazes

On Thu, 7 May 2009 01:54:23 -0500, you wrote: >On Thu, May 7, 2009 at 1:52 AM, Rein Klazes <wijn(a)online.nl> wrote: >> Fixes bug 10845 >> >> Changes from previous patch: menu position calculations moved to >> nonclient.c. > >Can you add a testcase? I don't see what you would like to test. The menu->Height == zero has the meaning "menusize needs recalculation" all over the code. That you need to have the menu size right before doing a hittest (in MENU_ButtonDown) is even more obvious. I expect the problem is more the form: touching sensitive nonclient code. Rein.

May 7, 2009

Re: (resubmit: need a hint) user32: when needed, recalculate menu size of menu bar before tracking starts.

by Austin English

On Thu, May 7, 2009 at 1:52 AM, Rein Klazes <wijn(a)online.nl> wrote: > Fixes bug 10845 > > Changes from previous patch: menu position calculations moved to > nonclient.c. Can you add a testcase? -- -Austin

May 7, 2009

Does wine handle virtual midi ports correct on OSX?

by Dewdman42

Does anyone know if Darwine can be fixed to handle virtual midi ports correctly? They work very sporadically right now. It seems to be related to getting the ports flushed or initialized or something. When there is a virtual midi port present (under OSX), Wine seems to see it and lists it as an available midi port, but I have not been able to consistently get that port to function correctly. Sometimes it does and sometimes it doesn't and it seems to related to switching it on and off in some fashion makes it work, though I can't seem to find a pattern that will work consistently. All I can figure is that somehow Wine is not handling midi ports in a way that is compatible with OSX virtual midi ports. Anyone have any experience or knowledge in this area? Thanks -- View this message in context: http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… Sent from the Wine - Devel mailing list archive at Nabble.com.

May 7, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Stefan Dösinger

Am Mittwoch, 6. Mai 2009 16:33:01 schrieb Roderick Colenbrander: > Actually ATI/AMD is quite interested in Wine. I have been in contact > with them for joining their developer program and helping them fix > issues. I didn't have time to fill out all the info yet. I could get > them look at it then. Note that the issue here is not getting the bug fixed(it is fixed in the 9.4 driver, as you've verified with my test apps), but that on older radeons we'll be stuck with a broken driver until one of the 3 existing Mesa radeon drivers becomes useable(I think the radeon-rewrite branch is the target, not the radeonhd one).

May 6, 2009

Re: Wine on Solaris 10 and SXCE

by Austin English

On Wed, May 6, 2009 at 9:55 AM, David Gerard <dgerard(a)gmail.com> wrote: > 2009/5/6 Vit Hrachovy <vit.hrachovy(a)sandbox.cz>: > >> *rumour* >> IMO one of technical barriers preventing Wine in /release repo could be >> that Wine doesn't compile with SunStudio compiler, only with gcc. >> *eof rumour* > > > Obviously that sort of thing consititutes a set of bugs that should be > reported and/or fixed by those it affects ;-) > > (Wine's cross-platform abilities are presently dismal. But there are > people working on fixing this.) Actually, wine works well on many platforms. Compiler wise, however, gcc is the compiler of choice (most variants, if not all). -- -Austin

May 6, 2009

Re: Wine on Solaris 10 and SXCE

by David Gerard

2009/5/6 Vit Hrachovy <vit.hrachovy(a)sandbox.cz>: > *rumour* > IMO one of technical barriers preventing Wine in /release repo could be > that Wine doesn't compile with SunStudio compiler, only with gcc. > *eof rumour* Obviously that sort of thing consititutes a set of bugs that should be reported and/or fixed by those it affects ;-) (Wine's cross-platform abilities are presently dismal. But there are people working on fixing this.) - d.

May 6, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Roderick Colenbrander

On Wed, May 6, 2009 at 3:52 PM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/5/6 Francois Gouget <fgouget(a)free.fr>: >> I have a feeling that Wine is the only 'application' that really tests >> the Unix OpenGL drivers, by virtue of being the only application to run >> the really complex vertex and pixel shaders that are found only in >> Windows games. Maybe I am wrong, but if I am right it means that the >> driver developpers would do well to take Wine seriously, and probably >> use it as a matter of course, if they want to produce quality code. > > I've been in contact with developers at Linux Game Publishing for a > while (and am now in fact a Junior Developer for them :D), and from > what I gather, regular OpenGL apps on Linux implement hacks to work > around bugs/shortcomings in ATI/AMD drivers. Wine is a special case > where it's been decided that hacks for specific drivers is a bad idea > except in extreme cases, and that there should be generalised > solutions for everything (which is, by the way, the whole point of > OpenGL :) ). > > As a result, the question of hacks in Wine comes up quite often > (ATI/AMD card owners want their games to work!) and it's (almost?) > always rejected. With any luck, we'll see some sensible, functional, > open-source radeonhd drivers coming soonish, so the issue of hacks at > the application level can be minimised. > > > Actually ATI/AMD is quite interested in Wine. I have been in contact with them for joining their developer program and helping them fix issues. I didn't have time to fill out all the info yet. I could get them look at it then. Roderick

May 6, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Ben Klein

2009/5/6 Francois Gouget <fgouget(a)free.fr>: > I have a feeling that Wine is the only 'application' that really tests > the Unix OpenGL drivers, by virtue of being the only application to run > the really complex vertex and pixel shaders that are found only in > Windows games. Maybe I am wrong, but if I am right it means that the > driver developpers would do well to take Wine seriously, and probably > use it as a matter of course, if they want to produce quality code. I've been in contact with developers at Linux Game Publishing for a while (and am now in fact a Junior Developer for them :D), and from what I gather, regular OpenGL apps on Linux implement hacks to work around bugs/shortcomings in ATI/AMD drivers. Wine is a special case where it's been decided that hacks for specific drivers is a bad idea except in extreme cases, and that there should be generalised solutions for everything (which is, by the way, the whole point of OpenGL :) ). As a result, the question of hacks in Wine comes up quite often (ATI/AMD card owners want their games to work!) and it's (almost?) always rejected. With any luck, we'll see some sensible, functional, open-source radeonhd drivers coming soonish, so the issue of hacks at the application level can be minimised.

May 6, 2009

RE: Severity levels

by Nicklas Börjesson

>However, a developer should be aware of the impact on the user experience and >the user's determined severity of a problem. That has been my point all the time. I was told that the users perceptions were not important since, a least according what I understood, they could not be trusted to be objective in their classification. Also, it was not very important to know their priorities anyway. >Users should not be determining this through the use of the severity and >priority fields. I have discussed the use of an impact field to have the >user state what impact the problem has on their ability to use/install a >particular application. However, I thought adding a extra field would be too bold a proposition, so I proposed to change the severity field instead(which I felt was unlinear anyway). Regarding the interface of the bug reporting I am also with you. It is simply not simple enough for normal users. Too many "knobs". The "problem" is that it is felt that enough bugs are reported anyway, and that therefore, no improvements are needed. Maybe that's correct, but I just can't help to think it is a bit of a strange mindset. //Nicklas

May 6, 2009

Re: Wine on Solaris 10 and SXCE

by Vit Hrachovy

Austin English wrote: > On Wed, May 6, 2009 at 5:15 AM, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote: >> Austin English wrote: >>>> OpenSolaris >>>> package wine in repository http://pkg.opensolaris.org/contrib >>> Is the contrib repository enabled by default? I haven't noticed it >>> when using OpenSolaris...or is it new for 2009.06? >> No, you have to add contrib repo manually. contrib repo exists since 2008.11 >> release. > > Ahh, thanks. > > Do you know if there's any plan on OpenSolaris's end to include Wine > in its repository? There are no plans to add Wine to /release repository by now (no ARC case I'm aware of). However, anyone can use SourceJuicer [1] and SFE wine spec file [2] to contribute latest Wine release to /pending repo and ask /contrib repo maintainers to update the package here. *rumour* IMO one of technical barriers preventing Wine in /release repo could be that Wine doesn't compile with SunStudio compiler, only with gcc. *eof rumour* Regards Vit [1]http://opensolaris.org/os/project/sourcejuicer/ [2]https://pkgbuild.svn.sourceforge.net/svnroot/pkgbuild/spec-files-extra/tr…

May 6, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Henri Verbeet

2009/5/6 Henri Verbeet <hverbeet(a)gmail.com>: > Mesa (that includes e.g. the intel and radeon drivers) is generally > responsive to bug reports, as is NVIDIA. It's really just AMD and > Apple that are problematic wrt. getting bugs fixed. > Just for the record, I'm not trying to just make AMD look bad here, I think it's great that they released the GPU documentation, and that they're paying people to work on the Mesa driver. Also, going by what I hear from other people, fglrx improved a lot in the more recent versions (certainly compared to the kind of support my Radeon 9800 Pro had...), so it's not all bad. They just *really* need to fix their developer relations stuff.

May 6, 2009

Re: Wine on Solaris 10 and SXCE

by Austin English

On Wed, May 6, 2009 at 5:15 AM, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote: > Austin English wrote: >>> OpenSolaris >>> package wine in repository http://pkg.opensolaris.org/contrib >> >> Is the contrib repository enabled by default? I haven't noticed it >> when using OpenSolaris...or is it new for 2009.06? > > No, you have to add contrib repo manually. contrib repo exists since 2008.11 > release. Ahh, thanks. Do you know if there's any plan on OpenSolaris's end to include Wine in its repository? -- -Austin

May 6, 2009

Re: Wine on Solaris 10 and SXCE

by Vit Hrachovy

Austin English wrote: > On Wed, May 6, 2009 at 3:56 AM, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote: >> Hi people, >> Apostolos provided me links to download Sun packages of latest Wine (1.1.20) >> at sunfreepacks. Could someone responsible please update WineHQ page with >> the following info: > > The sources are available at http://source.winehq.org/git/ Ahh, thx. will send patch. > >> OpenSolaris >> package wine in repository http://pkg.opensolaris.org/contrib > > Is the contrib repository enabled by default? I haven't noticed it > when using OpenSolaris...or is it new for 2009.06? No, you have to add contrib repo manually. contrib repo exists since 2008.11 release. Cheers Vit

May 6, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Henri Verbeet

2009/5/6 Stefan Dösinger <stefan(a)codeweavers.com>: > Am Mittwoch, 6. Mai 2009 10:10:07 schrieb Henri Verbeet: >> ...and on the other ones it will create hard to diagnose / explain >> bugs. Just disabling the extension if it's broken also avoids the >> crash, and will at least have predictable behaviour. > Not in this case. As I explain in a comment in the test, there's no d3d cap > flag for point sprites. So the games will just go ahead and try to do the > same kind of rendering and just fail in the same or worse way. > > The only advantage we get from disabling point sprites altogether is the WARN > we get if the game tries to use them. I'll add a similar WARN to the point > sprite function if the game uses them and this workaround is active. > Well, the point is that if you disable the extension it will just not work at all, instead of "sometimes, depending on which texture unit the texture is mapped on". >> Of course it would also help if AMD took these kind of >> things seriously, or at least replied to my posts >> (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107) > That specific issue is fixed in 9.4 I think. They confirmed the bug and > replied here: > http://ati.cchtml.com/show_bug.cgi?id=1462 > Sure, I read that too, but it's not my point of course.

May 6, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Stefan Dösinger

Am Mittwoch, 6. Mai 2009 10:10:07 schrieb Henri Verbeet: > 2009/5/5 Stefan Dösinger <stefan(a)codeweavers.com>: > > + * quirk only enables point sprites on the first texture unit. This > > keeps point sprites working in + * most games, but avoids the crash > > ...and on the other ones it will create hard to diagnose / explain > bugs. Just disabling the extension if it's broken also avoids the > crash, and will at least have predictable behaviour. Not in this case. As I explain in a comment in the test, there's no d3d cap flag for point sprites. So the games will just go ahead and try to do the same kind of rendering and just fail in the same or worse way. The only advantage we get from disabling point sprites altogether is the WARN we get if the game tries to use them. I'll add a similar WARN to the point sprite function if the game uses them and this workaround is active. > I also *still* think us working around AMD's bugs is the wrong > approach. I agree in general, if this was just a rendering bug I'd put the workaround as a hack into CrossOver and be happy. However, we're trying to prevent a kernel panic here, and on the last two Wineconfs we agreed that we should try to prevent kernel panics while running our d3d tests, even if it is ugly(we have similar workarounds for old Mesa glDrawPixels / glReadPixels issues). If the tests crash the systems people will refuse to run them, making them useless. > Of course it would also help if AMD took these kind of > things seriously, or at least replied to my posts > (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107) That specific issue is fixed in 9.4 I think. They confirmed the bug and replied here: http://ati.cchtml.com/show_bug.cgi?id=1462 (unfortunately no 9.4 for <= r500 cards, so we have to keep our workaround in directx.c)

May 6, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Henri Verbeet

2009/5/6 Francois Gouget <fgouget(a)free.fr>: > On Wed, 6 May 2009, Henri Verbeet wrote: > [...] >> I also *still* think us working around AMD's bugs is the wrong >> approach. Of course it would also help if AMD took these kind of >> things seriously, or at least replied to my posts >> (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107) > > Do we have a more formal way of reporting bugs to AMD/ATI? Something > like a Bugzilla? Concerning this issue (the driver reporting a number of > vec4s instead of the number of uniforms), do we have a way of checking > independently of AMD? If so that would strengthen our bug report. > I think they're aware of that particular issue because Stefan talked privately to one of their developers, but unless things changed recently http://ati.cchtml.com/ is probably the closest to a bug tracker there is, and I'm not completely sure they read that regularly. > But hey, I got a quick answer to my bug report to the Intel developpers > so it's not always bad. Unfortunately now I'm the one that's slow to > answer as I have not had time to test their proposed fix. But I have not > forgotten... > Mesa (that includes e.g. the intel and radeon drivers) is generally responsive to bug reports, as is NVIDIA. It's really just AMD and Apple that are problematic wrt. getting bugs fixed.

May 6, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Francois Gouget

On Wed, 6 May 2009, Henri Verbeet wrote: [...] > I also *still* think us working around AMD's bugs is the wrong > approach. Of course it would also help if AMD took these kind of > things seriously, or at least replied to my posts > (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107) Do we have a more formal way of reporting bugs to AMD/ATI? Something like a Bugzilla? Concerning this issue (the driver reporting a number of vec4s instead of the number of uniforms), do we have a way of checking independently of AMD? If so that would strengthen our bug report. I have a feeling that Wine is the only 'application' that really tests the Unix OpenGL drivers, by virtue of being the only application to run the really complex vertex and pixel shaders that are found only in Windows games. Maybe I am wrong, but if I am right it means that the driver developpers would do well to take Wine seriously, and probably use it as a matter of course, if they want to produce quality code. But hey, I got a quick answer to my bug report to the Intel developpers so it's not always bad. Unfortunately now I'm the one that's slow to answer as I have not had time to test their proposed fix. But I have not forgotten... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...

May 6, 2009

Re: Wine on Solaris 10 and SXCE

by Tom Wickline

On Wed, May 6, 2009 at 5:02 AM, Austin English <austinenglish(a)gmail.com>wrote: > On Wed, May 6, 2009 at 3:56 AM, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> > wrote: > > Hi people, > > Apostolos provided me links to download Sun packages of latest Wine > (1.1.20) > > at sunfreepacks. Could someone responsible please update WineHQ page with > > the following info: > > The sources are available at http://source.winehq.org/git/ > > > OpenSolaris > > package wine in repository http://pkg.opensolaris.org/contrib > > Is the contrib repository enabled by default? I haven't noticed it > when using OpenSolaris...or is it new for 2009.06? Contrib still shows Wine 1.0.1 http://pkg.opensolaris.org/contrib/en/search.shtml?token=wine&action=Search > > -- > -Austin > > >

May 6, 2009

Re: Wine on Solaris 10 and SXCE

by Austin English

On Wed, May 6, 2009 at 3:56 AM, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote: > Hi people, > Apostolos provided me links to download Sun packages of latest Wine (1.1.20) > at sunfreepacks. Could someone responsible please update WineHQ page with > the following info: The sources are available at http://source.winehq.org/git/ > OpenSolaris > package wine in repository http://pkg.opensolaris.org/contrib Is the contrib repository enabled by default? I haven't noticed it when using OpenSolaris...or is it new for 2009.06? -- -Austin

May 6, 2009

Wine on Solaris 10 and SXCE

by Vit Hrachovy

Hi people, Apostolos provided me links to download Sun packages of latest Wine (1.1.20) at sunfreepacks. Could someone responsible please update WineHQ page with the following info: http://winehq.org Run Windows applications on Linux, BSD, Solaris and Mac OS X. http://winehq.org/download/ Solaris http://www.sunfreepacks.com/listing/?limit=1000&offset=0 Solaris 10 http://www.sunfreepacks.com/pkgpool/ASwine-1.1.20.pkg.7z Solaris SXCE http://www.sunfreepacks.com/pkgpool/ASwine-SXCE-1.1.20.pkg.7z OpenSolaris package wine in repository http://pkg.opensolaris.org/contrib Thank you very much! Regards Vit Hrachovy -------- Original Message -------- Subject: Re: wine web pages update Date: Fri, 1 May 2009 11:31:53 -0700 (PDT) From: Apostolos Syropoulos <asyropoulos(a)yahoo.com> To: Vít Hrachový <vit.hrachovy(a)sandbox.cz> Hello there, We have exchanged a couple of messages back in March about the inclusion of Solaris/OpenSolaris download link in the wine pages, but still there is no progress. If you visit the following URL http://www.sunfreepacks.com/listing/?limit=10&offset=20 you will be able to download binary packages for both platforms. Could you please update your web pages? Kind regards, Apostolos ---------------------- Apostolos Syropoulos Xanthi, Greece

May 6, 2009

Re: [4/5] WineD3D: Work around a bad crash in fglrx

by Henri Verbeet

2009/5/5 Stefan Dösinger <stefan(a)codeweavers.com>: > + * quirk only enables point sprites on the first texture unit. This keeps point sprites working in > + * most games, but avoids the crash ...and on the other ones it will create hard to diagnose / explain bugs. Just disabling the extension if it's broken also avoids the crash, and will at least have predictable behaviour. I also *still* think us working around AMD's bugs is the wrong approach. Of course it would also help if AMD took these kind of things seriously, or at least replied to my posts (http://www.phoronix.com/forums/showpost.php?p=63527&postcount=107)

May 6, 2009

Re: [2/5] WineD3D: Keep track of used float constants

by Henri Verbeet

> + reg_maps->constf = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(*reg_maps->constf) * (constf_size / (sizeof(*reg_maps->constf) * 8) + 1)); This is flawed, it will allocate too much memory. You essentially want "(bit_count + 31) / 32" to calculate the number of DWORDs. > static void shader_record_register_usage(IWineD3DBaseShaderImpl *This, struct shader_reg_maps *reg_maps, > - DWORD register_type, UINT register_idx, BOOL has_rel_addr, BOOL pshader) > + DWORD register_type, UINT register_idx, BOOL has_rel_addr, BOOL pshader, unsigned char size) I don't think this is very nice, it's better to just call shader_record_register_usage() multiple times for the appropriate instructions. I.e., handle this the same way all the other opcodes are handled.

May 6, 2009

Re: Shuttleworth on Wine

by Scott Ritchie

nn wrote: > Shuttleworth on Wine > http://www.osnews.com/story/21438/Shuttleworth_on_Wine > > > Yahoo!7 recommends that you update your browser to the new Internet Explorer 8.Get it now. > > The reason stuff like this makes the news is because everyone wants to know about Wine in Ubuntu. The past two talks I've given on Wine at Ubuntu Open Week were similarly plastered with questions, even though this time I didn't speak directly after Mark. The reason everyone wants to know about Wine in Ubuntu is because it feels like a big thing. Ubuntu wants to attract Windows users to a free software platform, Wine helps them switch. The partnership is obvious, and Ubuntu doesn't even have to do that much - just include some of the integration projects I'm cobbling together. I've said it before, but I mean it this time - I predict big things for the next release, especially if we can get Wine 1.2 in there. Now, someone please finish one of Alexandre's release goals in the next 5 months so this can happen ;) Thanks, Scott Ritchie

May 6, 2009

RE: Shuttleworth on Wine

by Nicklas Börjesson

I'd say that attitutudes might change, though. For example, he is mentioning photoshop(of course) which I use at home under win. It works great there. There are only a few quirks with the installation: 1. it need 1.1.17 to work 2. a DLL is needed for the text-tool to work. 3. A winetricks has to be done. When those things are fixed(I guess 1. is the most important), gradually more people will start using wine, hence acceptance will grow, and eventually even Mark Shuttleworth will come around. If I were the leader of the wine project, the moment photoshop CS4 works all the way, that would be the basis of the next stable version(to avoid regessions to the highest degree).. I believe that the popularity of wine(yes, popularity is extra important for a FOSS project) would skyrocket. Then it would be a toy no more. //Nicklas -----Original Message----- From: wine-devel-bounces(a)winehq.org [mailto:wine-devel-bounces(a)winehq.org] On Behalf Of Remco Sent: den 6 maj 2009 01:35 To: Ben Klein Cc: wine-devel(a)winehq.org Subject: Re: Shuttleworth on Wine On Wed, May 6, 2009 at 1:28 AM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/5/6 nn <saturn_systems(a)yahoo.com>: >> >> And the slashdot thread: >> Shuttleworth Says Ubuntu Can't Just Be Windows >> http://linux.slashdot.org/article.pl?sid=09/05/05/1546230 > > This is nothing new. It's just now we have a celebrity saying it. Not only that. Canonical has decided a few years ago that Wine would not be included for this reason. [1] So it's really really really old news. Remco [1] http://linux.slashdot.org/article.pl?sid=07/05/11/1220219&art_pos=4

May 6, 2009

Re: comctl32/test: test CheckState Macros

by Austin English

2009/5/5 André Hentschel <nerv(a)dawncrow.de>: > --- > dlls/comctl32/tests/listview.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) This patch fails without your other patch. In the future, please combine them into one patch, or number them in a series. Wine must compile and pass the tests before and after every patch. -- -Austin

May 6, 2009

Re: Shuttleworth on Wine

by Ben Klein

2009/5/6 Remco <remco47(a)gmail.com>: > On Wed, May 6, 2009 at 1:22 AM, Ben Klein <shacklein(a)gmail.com> wrote: >> Basically, what Shuttleworth is saying is that running Windows apps (whether >> via Wine or via porting) is unimportant to Ubuntu (or the opensource world in >> general) > > He uses the word important, not unimportant. But he also says that the > interviewer missed the third aspect that is important: good free > software itself. Reading between the lines here. "They're both important, but what's REALLY important is ..." He can't really shout the interviewer down and say "you're missing the point entirely" directly. That's bad PR. :)

May 5, 2009

Re: Shuttleworth on Wine

by Remco

On Wed, May 6, 2009 at 1:28 AM, Ben Klein <shacklein(a)gmail.com> wrote: > 2009/5/6 nn <saturn_systems(a)yahoo.com>: >> >> And the slashdot thread: >> Shuttleworth Says Ubuntu Can't Just Be Windows >> http://linux.slashdot.org/article.pl?sid=09/05/05/1546230 > > This is nothing new. It's just now we have a celebrity saying it. Not only that. Canonical has decided a few years ago that Wine would not be included for this reason. [1] So it's really really really old news. Remco [1] http://linux.slashdot.org/article.pl?sid=07/05/11/1220219&art_pos=4

May 5, 2009

Re: Shuttleworth on Wine

by Remco

On Wed, May 6, 2009 at 1:22 AM, Ben Klein <shacklein(a)gmail.com> wrote: > Basically, what Shuttleworth is saying is that running Windows apps (whether > via Wine or via porting) is unimportant to Ubuntu (or the opensource world in > general) He uses the word important, not unimportant. But he also says that the interviewer missed the third aspect that is important: good free software itself. Remco

May 5, 2009

Re: Shuttleworth on Wine

by Ben Klein

2009/5/6 nn <saturn_systems(a)yahoo.com>: > > And the slashdot thread: > Shuttleworth Says Ubuntu Can't Just Be Windows > http://linux.slashdot.org/article.pl?sid=09/05/05/1546230 This is nothing new. It's just now we have a celebrity saying it. I also don't like the wording used; I'd prefer "Shuttleworth Says Ubuntu Can't Be Just Windows", referring to "he said that Ubuntu cannot ***be simply*** a better platform to run Windows apps." (instead of "simply be"). Connotation is different, and much closer to what he actually said in the discussion.

May 5, 2009

Re: Shuttleworth on Wine

by Ben Klein

2009/5/6 nn <saturn_systems(a)yahoo.com>: > > Shuttleworth on Wine > http://www.osnews.com/story/21438/Shuttleworth_on_Wine >From that page: > While Wine might play a role in some user's lives, I must admit that I > personally never felt compelled to use it. Linux has its own set of > applications that work just fine, with lots of choices and different > approaches to the same task. This is someone who has never used Wine, but feels compelled to comment on how it's slow and unstable. Wonderfully uninteresting. The article he's discussing is more interesting, and much more on-topic for Shuttleworth's comments. http://ostatic.com/blog/open-free-functional-and-wrapped-in-a-strong-sense-… (Stupidly long URLs are fantastic) Basically, what Shuttleworth is saying is that running Windows apps (whether via Wine or via porting) is unimportant to Ubuntu (or the opensource world in general), but that developing solid, unixy-but-friendly alternatives is essential. > Yahoo!7 recommends that you update your browser to the new Internet Explorer 8.Get it now. Eeew, yet another reason to hate Yahoo! mail service.

May 5, 2009

Re: Shuttleworth on Wine

by nn

And the slashdot thread: Shuttleworth Says Ubuntu Can't Just Be Windows http://linux.slashdot.org/article.pl?sid=09/05/05/1546230 --- On Wed, 6/5/09, nn <saturn_systems(a)yahoo.com> wrote: > From: nn <saturn_systems(a)yahoo.com> > Subject: Shuttleworth on Wine > To: wine-devel(a)winehq.org > Received: Wednesday, 6 May, 2009, 9:04 AM > > Shuttleworth on Wine > http://www.osnews.com/story/21438/Shuttleworth_on_Wine > > > Yahoo!7 recommends that you update > your browser to the new Internet Explorer 8.Get it now. > > > The new Internet Explorer 8 optimised for Yahoo!7: Faster, Safer, Easier.

May 5, 2009

msvcrt crash issue, tracing

by Kjell Rune Skaaraas

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

May 5, 2009

Shuttleworth on Wine

by nn

Shuttleworth on Wine http://www.osnews.com/story/21438/Shuttleworth_on_Wine Yahoo!7 recommends that you update your browser to the new Internet Explorer 8.Get it now.

May 5, 2009

Re: Severity levels

by Ben Klein

2009/5/5 Paul TBBle Hampson <Paul.Hampson(a)pobox.com>: > I've got a whole bunch of bugs linked from Warhammer Online which have > really unuseful bug titles, causing readers of the page to end up > reporting the same things in the comments. Bug titles can and should be changed. 2009/5/6 James Mckenzie <jjmckenzie51(a)earthlink.net>: > Since the severity and priority fields are developer only, they should not > be present. Developers use bugzilla too. Any restriction we put on casual users will affect experienced users, unless there is some flag in each user's profile for whether the fields will be visible. Big question is, is it THAT much of a problem? I vote no. 2009/5/6 Rosanne DiMesio <dimesio(a)earthlink.net>: >>This allows the user to provide input >> and allow the triage team to provide feedback to the user as well as >> assign appropriate severity and priorities to bug reports. >> > > There's already a field that does exactly that: the description. It allows users to describe the problem in as much detail as they wish, including its impact, and unlike a drop-down list, is not limited to common issues. I don't see what an additional field to repeat this information in vague terms will do to help anyone. +1. Also note that vague or misleading descriptions are common, users often don't respond to bugs with more information, and in extreme cases, bugs get closed due to a lack of activity. Adding a field that basically says "it's broken" (in a variety of weird and wonderful ways) won't help with improving descriptions.

May 5, 2009