October 2007 - Wine-Devel - list.winehq.org

Re: Photoshop Elements 5 Tryout? (Maintainer requests)

by Jan Zerebecki

On Mon, Oct 22, 2007 at 12:22:35AM +0200, Alexander Nicolaysen Sørnes wrote: > On Sunday 21 October 2007 21:11:53 Vitaliy Margolen wrote: > > Jan Zerebecki wrote: > > > No. Let me rephrase what vitamin already said: I accepted a > > > request he made but the only effect was that it was removed from > > > the queue. (Although I didn't check that, I suspect that neither > > > a reject nor accept mail was generated.) > > I have not received any e-mails. > There wouldn't have been any; the maintainer entries would be silently deleted > without any notification. But I _accepted_ his request. Do we agree that this is a bug? And I would say that also rejection of a maintainer request should generate a mail to the requester. Jan

Oct. 22, 2007

Re: [4/5] WineD3D: Enable the draw buffers extension only when used

by Stefan Dösinger

Am Montag, 22. Oktober 2007 17:41:33 schrieb H. Verbeet: > Probably, but the warnings are a driver problem, not a wined3d > problem. The really bad part is that if the drivers ever get fixed we > end up with workarounds for problems that no longer exist. This is a good point, if we put such a workaround in it is pretty unlikely that we'll retest for it and remove it, unless it makes active problems. On the other hand, broken drivers tend stay around even if the newest version. This here happens on MacOS 10.4, and since 10.5 is due to ship in a few days, I don't expect any more than security updates for 10.4, but it will remain important for quite some more time because the update is not free. I looked for some other reports of this issue, and it seems that some fglrx and card combinations are affected by a similar problem. I never saw it myself, but fglrx floods us with spec-violating success messages, so I never spent much attention at the driver output...

Oct. 22, 2007

Re: [4/5] WineD3D: Enable the draw buffers extension only when used

by H. Verbeet

On 22/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Montag, 22. Oktober 2007 14:57:40 schrieb H. Verbeet: > > On 22/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > > The shader works in the end, but the complaints pollute the logs and > > > make tracking real failures more difficult. > > > > I don't think this change makes things better there. > One issue is that those ignorable warnings spam the debug output and make it > difficult to spot real warnings. The draw_buffer warning is only one of them, > Apple also warns about BindAttribLocation calls for undefined Attributes. At > some point the driver seems to cut off further warnings, so real issues get > lost. > > My other concern is that some GL implementations do not realize that > draw_buffers isn't really used, and turns on things we do not need because we > request the extension. I doubt this applies to macos, its optimizer is quite > sane as far as I can see. > > I agree that this patch makes the glsl code a bit more complex, and I am fine > with keeping it in my junk branch. But I think having it in the tree makes > the life easier for newcomer developers and users by making sure they don't > get flooded with false warnings. (Not that we have any mac d3d developers > except me, but false warnings won't help with that). > Probably, but the warnings are a driver problem, not a wined3d problem. The really bad part is that if the drivers ever get fixed we end up with workarounds for problems that no longer exist.

Oct. 22, 2007

Re: gdi32 (1/2): fix unchecked NULL ptr in BIDI_Reorder

by Alexandre Julliard

Alexander Dorofeyev <alexd14(a)hushmail.com> writes: > >> One problem is that it wasn't assured lpOutString isn't NULL, and NULL > >> was getting passed to this routine by GetCharacterPlacementW. so it was > >> crashing in memcpy. This patch creates a temporary buffer when > >> lpOutString is NULL and it is used for in-place modifications instead in > >> such case. You shouldn't need to allocate a new buffer, the output modifications should be skipped when no output string is requested. -- Alexandre Julliard julliard(a)winehq.org

Oct. 22, 2007

Re: urlmon: Add tests for BindToObject for URL monikers based on the existing tests for BindToStorage.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > dlls/urlmon/tests/url.c | 201 > +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 196 insertions(+), 5 deletions(-) Some of the todos are succeeding here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c && touch url.ok url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider make[2]: *** [url.ok] Error 12 -- Alexandre Julliard julliard(a)winehq.org

Oct. 22, 2007

Re: [4/5] WineD3D: Enable the draw buffers extension only when used

by Stefan Dösinger

Am Montag, 22. Oktober 2007 14:57:40 schrieb H. Verbeet: > On 22/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > The shader works in the end, but the complaints pollute the logs and > > make tracking real failures more difficult. > > I don't think this change makes things better there. One issue is that those ignorable warnings spam the debug output and make it difficult to spot real warnings. The draw_buffer warning is only one of them, Apple also warns about BindAttribLocation calls for undefined Attributes. At some point the driver seems to cut off further warnings, so real issues get lost. My other concern is that some GL implementations do not realize that draw_buffers isn't really used, and turns on things we do not need because we request the extension. I doubt this applies to macos, its optimizer is quite sane as far as I can see. I agree that this patch makes the glsl code a bit more complex, and I am fine with keeping it in my junk branch. But I think having it in the tree makes the life easier for newcomer developers and users by making sure they don't get flooded with false warnings. (Not that we have any mac d3d developers except me, but false warnings won't help with that).

Oct. 22, 2007

Re: pdh: Remove or fix tests that fail on Windows.

by Hans Leidekker

On Monday 22 October 2007 14:43:59 Jeff Latimer wrote: > to test with and hence the delay. The current patch I submitted was > cleaning up the Null reference issue before moving on to sorting out the I don't see any crash on Wine or XP when running the test. You are trying to protect against a hypothetical case where an app specifies a size > 0 but no buffer. XP won't accept that anyway and it's unlikely any app will do that on non-XP systems. In fact your patch will break in another - also unlikely - situation where an app relies on non-XP behaviour, which is to accept a null buffer and size > 0 but less than the required size. So a crash is even desirable here, because it tells us immediately that the app is doing something peculiar. -Hans

Oct. 22, 2007

Re: [5/5] WineD3D: A point size fix

by Stefan Dösinger

Am Montag, 22. Oktober 2007 14:57:12 schrieb H. Verbeet: > On 22/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > D3D's point size limit is the output point size, GLs the input. Modify > > the scale parameters to deal with this. > > Shouldn't the caps be changed as well then? No, I think the point size reported in the caps is ok. The point size the app can draw on the screen is still the same. The situation the patch fixes is that the app sets a point size of 128, and a scale of 0.5, which results in a 64x64 pixel point. I don't see any caps that need adjustment there.

Oct. 22, 2007

Re: [4/5] WineD3D: Enable the draw buffers extension only when used

by H. Verbeet

On 22/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > The shader works in the end, but the complaints pollute the logs and > make tracking real failures more difficult. I don't think this change makes things better there.

Oct. 22, 2007

Re: [5/5] WineD3D: A point size fix

by H. Verbeet

On 22/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > D3D's point size limit is the output point size, GLs the input. Modify > the scale parameters to deal with this. Shouldn't the caps be changed as well then?

Oct. 22, 2007