On Thu, May 19, 2011 at 11:58:47AM -0700, Scott Ritchie wrote:
> So, multiarch is going along well in Debian/Ubuntu, and by next distro
> release Wine should be building as a proper multiarch package. Previous
> hacks like ia32-libs will be dead for good.
>
>
> A side effect of this change, howe
I think I'd rather just change the way the test works.
Scott Ritchie wrote:
> So, multiarch is going along well in Debian/Ubuntu, and by next distro
> release Wine should be building as a proper multiarch package. Previous
> hacks like ia32-libs will be dead for good.
>
>
> A side effect of this change, however, is the current build daemons ONLY
> h
So, multiarch is going along well in Debian/Ubuntu, and by next distro
release Wine should be building as a proper multiarch package. Previous
hacks like ia32-libs will be dead for good.
A side effect of this change, however, is the current build daemons ONLY
have packages for one architecture.
Piotr Caban writes:
> ---
> dlls/msvcrt/file.c | 448
>
> 1 files changed, 314 insertions(+), 134 deletions(-)
This one should probably be split. It also breaks badly on 64-bit:
../../../../wine/tools/runtest -q -P wine -M mshtml.dll -T ../
Andrew Nguyen writes:
> diff --git a/programs/hostname/Makefile.in b/programs/hostname/Makefile.in
> new file mode 100644
> index 000..300d727
> --- /dev/null
> +++ b/programs/hostname/Makefile.in
> @@ -0,0 +1,12 @@
> +EXTRADEFS = -DWINE_NO_UNICODE_MACROS
> +MODULE= hostname.exe
> +APPMOD
On 05/19/2011 06:34 PM, Dylan Smith wrote:
On Thu, May 19, 2011 at 6:16 AM, Joris Huizer wrote:
Hello,
I found a possibly memory leak in the patch.
In this function:
+static HRESULT parse_mesh(IDirectXFileData *filedata, struct mesh_data
*mesh_data, DWORD provide_flags)
These may leak the
On Thu, May 19, 2011 at 6:16 AM, Joris Huizer wrote:
>
> Hello,
>
> I found a possibly memory leak in the patch.
> In this function:
>
>> +static HRESULT parse_mesh(IDirectXFileData *filedata, struct mesh_data
>> *mesh_data, DWORD provide_flags)
>
> These may leak the allocated blocks:
>>
>> +
>>
On Thu, May 19, 2011 at 11:30 AM, Austin English
wrote:
> --
> -Austin
>
>
>
>
This test should use a table+loop I think.
On 05/18/2011 12:03 PM, siro wrote:
This patch don't clear the dinput queue in IDirectInputDevice2WImpl_Acquire
Clearly this is wrong. Of course you can prove otherwise with some tests.
You can also test with native dinput to see if it has the same issue or not.
Vitaliy.
Alistair Leslie-Hughes wrote:
> gdi32: Add support in DeviceCaps CURVECAPS, LINECAPS, POLYGONALCAPS
> for EnhMetafiles
I'd guess they should be cached and returned for the parent device instead.
--
Dmitry.
Hello,
I found a possibly memory leak in the patch.
In this function:
+static HRESULT parse_mesh(IDirectXFileData *filedata, struct mesh_data
*mesh_data, DWORD provide_flags)
These may leak the allocated blocks:
+
+mesh_data->vertices = HeapAlloc(GetProcessHeap(), 0,
+mesh_da
Alexandre Julliard writes:
Lauri Kenttä writes:
With my touchpad the results are much more interesting.
Most likely because XInput raw events don't take acceleration into
account. I'm not sure there's a whole lot we can do about that.
I've disabled acceleration, and the problem persists. Un
On Wed, May 18, 2011 at 10:57:59AM +0200, Alexandre Julliard wrote:
> Marcus Meissner writes:
>
> > ---
> > dlls/dinput/Makefile.in|1 -
> > dlls/dinput/data_formats.c | 566
> >
> > dlls/dxguid/dxguid.c | 545
> > +++
adding c:test.txt (and friends) as input should be also interesting
UNC paths should also be tested
A+
+} Paths[] = { {"C:/directory/test.txt", "C:", "/directory/",
> "test", ".txt"},
> +{"C:\\directory\\test.txt", "C:", "\\directory\\",
> "test", ".txt"},
> +
Patch can be discarded. Spreading casts all over is probably a bad thing.
16 matches
Mail list logo
