2009/8/13 :
> I'm using Ubuntu Intrepid with Intel i915 graphics.
> Is that worth regresion testing or is somebody already looking at this?
I don't see it here, please do a regression test.
Hi,
did anyone notice this recent bug? The d3d9 and d3d8 testsuites fail for me
since 1.1.27. My crash backtrace is similar to that already visible in
test.winehq.org "WinXP-AMD2600-1.1.27" (submitted by somebody else):
http://test.winehq.org/data/b79639699766e7c8f3e236f3fef54e5daac0e5f9/index_Wi
Andrew Eikum wrote:
---
dlls/gdiplus/graphics.c | 19 -
dlls/gdiplus/tests/graphics.c | 162
+
2 files changed, 177 insertions(+), 4 deletions(-)
Could you do it in opposite direction - implement "I" version on top of
GdipIsVisiblePoint?
Am Thursday 13 August 2009 21:19:38 schrieb Chris Robinson:
> There are patches in the works that do this, but there's straggling issues
> that AJ hasn't been able to work out yet. This is something that really
> needs to be done anyway, as GL/D3D are really suffering on cards with a lot
> of VRAM,
From 60e82c0890e7f435afcd200752226ed1fa4ee669 Mon Sep 17 00:00:00 2001
From: Mike Kaplinskiy
Date: Sun, 9 Aug 2009 00:12:52 -0400
Subject: kernel32: implement CancelIoEx
---
dlls/kernel32/file.c| 26 ++
dlls/kernel32/kernel32.spec |1 +
include/winbase.h
On Thu, Aug 13, 2009 at 09:07:29PM +0200, Alexandre Julliard wrote:
> Austin English writes:
>
> > On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote:
> >>> All the more reason to use the existing libmpg123 instead of trying to
> >>> maintain our own version, IMO.
> >>
> >> Aric already explained t
Hi EA, some comments on your tiny little app:
+#define WIN32_LEAN_AND_MEAN
+
+#include "config.h"
+
+#include
+#include
+#include
You don't need to define WIN32_LEAN_AND_MEAN for compiling with Wine's
headers, and you don't need to include , either. Also,
since you never use any of the standa
2009/8/13 Alexandre Julliard :
> Austin English writes:
>
>> On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote:
All the more reason to use the existing libmpg123 instead of trying to
maintain our own version, IMO.
>>>
>>> Aric already explained that we can't: it doesn't exist on the Mac.
On Thursday 13 August 2009 12:03:02 pm Reece Dunn wrote:
> But there is a reason for using our own version -- the HeapAlloc/Free
> and Wine tracing changes that Aric mentioned in the initial email. So
> for that reason, it won't be practical to dynamically link.
Needing to change malloc->HeapAlloc
Austin English writes:
> On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote:
>>> All the more reason to use the existing libmpg123 instead of trying to
>>> maintain our own version, IMO.
>>
>> Aric already explained that we can't: it doesn't exist on the Mac.
>
> Not to nitpick, but if that's the
> I was not suggesting that libmpg123 should be made dynamic.
>
> You asked what the rationale was - citing disk space as the only
> reason. I was saying that disk space is not the only valid reason for
> wanting to do this.
I misunderstood you. Sorry for putting words in your mouth.
--Juan
> Not to nitpick, but if that's the reason for bundling libmpg, there
> are several other libraries we should bundle...
You won't get disagreement from me there, but now we're changing the subject.
--Juan
2009/8/13 Juan Lang :
>> The reason you'd want to use dynamic linking is to ease security fix
>> updates. If a flaw is found in libmpg123 that allows remote code
>> execution (for example), any package that has its own version, or that
>> statically links it into the program, needs updating, rebuil
On Thu, Aug 13, 2009 at 1:41 PM, Juan Lang wrote:
>> All the more reason to use the existing libmpg123 instead of trying to
>> maintain our own version, IMO.
>
> Aric already explained that we can't: it doesn't exist on the Mac.
Not to nitpick, but if that's the reason for bundling libmpg, there
> The reason you'd want to use dynamic linking is to ease security fix
> updates. If a flaw is found in libmpg123 that allows remote code
> execution (for example), any package that has its own version, or that
> statically links it into the program, needs updating, rebuilding and
> repackaging.
A
2009/8/13 Juan Lang :
>> How hard is it to make a configure option whether to link to libmpg123
>> dynamically or statically, and probably default to dynamic linking(not
>> dlopen).
>>
>> That way package providers can build a package that doesn't need extra
>> dependencies, self-compilers(where bu
> All the more reason to use the existing libmpg123 instead of trying to
> maintain our own version, IMO.
Aric already explained that we can't: it doesn't exist on the Mac.
--Juan
On Thursday 13 August 2009 11:23:45 am Juan Lang wrote:
> Developer resources are a much bigger constraint.
All the more reason to use the existing libmpg123 instead of trying to
maintain our own version, IMO.
> How hard is it to make a configure option whether to link to libmpg123
> dynamically or statically, and probably default to dynamic linking(not
> dlopen).
>
> That way package providers can build a package that doesn't need extra
> dependencies, self-compilers(where build system == runtime system
Am Thursday 13 August 2009 00:30:33 schrieb Aric Stewart:
> Well the main advantage I can see is that we are able to have mp3
> support without adding a new library dependency. This will be
> especially useful for platforms other than Linux where libmpg123 is not
> present. Such as the Mac.
How ha
2009/8/13 Cheer Xiao :
> Henri Verbeet told me that I should provide my
> full name in the file as well as in my e-mail account name. Here is
> the new patch.
>
Actually, that patch doesn't apply. Looks like it's against a version
of Wine from before commit 4e046a6759b059b3c424480bea052af01cc85ebe
On Thu, Aug 13, 2009 at 6:59 PM, Stefan Dösinger wrote:
> Am Wednesday 12 August 2009 10:04:10 schrieb Sun, Sunny:
>
>> I think you can first detect GL_ATI_meminfo in
>> glGetString(GL_EXTENSIONS); if GL_ATI_meminfo exists, then you can use
>> glGetIntegerv(GL_VBO_FREE_MEMORY_ATI, param) to get the
Am Wednesday 12 August 2009 10:04:10 schrieb Sun, Sunny:
> I think you can first detect GL_ATI_meminfo in
> glGetString(GL_EXTENSIONS); if GL_ATI_meminfo exists, then you can use
> glGetIntegerv(GL_VBO_FREE_MEMORY_ATI, param) to get the current free
> video memory, you can see more info at:
A mino
On Wed, Aug 12, 2009 at 6:30 PM, Aric Stewart wrote:
> Well the main advantage I can see is that we are able to have mp3 support
> without adding a new library dependency. This will be especially useful for
> platforms other than Linux where libmpg123 is not present. Such as the Mac.
Heh yeah I d
2009/8/12 Sun, Sunny :
> I think you can first detect GL_ATI_meminfo in glGetString(GL_EXTENSIONS);
> if GL_ATI_meminfo exists, then you can use
> glGetIntegerv(GL_VBO_FREE_MEMORY_ATI, param) to get the current free video
> memory, you can see more info at:
>
Is VBO_FREE_MEMORY_ATI the most appropr
2009/8/13 Stefan Dösinger :
> I'd say give wine-patches a try :-) Make sure Alexandre can see how these
> patches will work together with the wpp ones and the actual implementation of
> D3DXAssembleShader
>
If you do, try to split it up a bit more where possible, it's still a
pretty large patch to
Am Wednesday 12 August 2009 21:57:36 schrieb Matteo Bruni:
> > I think it doesn't need two include files, especially since both of them
> > are d3dx9-private anyway. The question is, is it better to just merge
> > them into d3dx9_36_private.h, or have assembler things in a separate
> > file? I tend
27 matches
Mail list logo
