On Sep 27, 2012, at 5:10 PM, Austin English wrote:
> --
> -Austin
>
> -- Forwarded message --
> From: Martín Ferrari
> Date: Thu, Sep 27, 2012 at 3:52 PM
> Subject: CIA going down: KGB wants your commits!
> To: debian-proj...@lists.debian.org, Debian Developers
>
>
>
> Hi th
Le 27/09/2012 11:26, Hans Leidekker a écrit :
On Thu, 2012-09-27 at 09:59 +0200, Christian Costa wrote:
diff --git a/dlls/msi/media.c b/dlls/msi/media.c
index 612624d..8a39fcd 100644
--- a/dlls/msi/media.c
+++ b/dlls/msi/media.c
@@ -358,8 +358,18 @@ static INT_PTR cabinet_next_cabinet(FDINOTIFI
Am 27.09.2012 09:13, schrieb joerg-cyril.hoe...@t-systems.com:
> Hi,
>
> Recently I thought I found a use-case for CreateThread(CREATE_SUSPENDED).
> The idiom is to get the thread handle before the thread starts a life on its
> own.
>
> I looked at the kernel tests,
> http://source.winehq.org/so
I'm pretty sure CREATE_SUSPENDED works. It's such a basic thing that
would cause many race conditions if it did not, including in parts of
Wine that use it and in the test you just linked.
If the new thread were not initially suspended, it would be possible
for the thread to return between the ini
The series looks good to me. Very cool to have a fix for this.
> @@ -3898,7 +3894,7 @@ GpStatus WINGDIPAPI GdipImageSelectActiveFrame(GpImage
> *image, GDIPCONST GUID *d
> return Ok;
> }
>
> -IStream_Release(stream);
> +IStream_Release(image->stream);
> return stat;
> }
I don't think it's necessary to AddRef/Release the stream any
Hello,
While working on more of the 'for' processing in the command shell, I've
come across a stumbling block that wildcard expansion 'ordering' is not
guaranteed (findfirst/findnext) meaning I cannot automate tests for some of
the key bits - this is frustrating as we really need tests for the thi
Well I think, if you rework a series, please add something like try xyz
or so ... Also try to avoid to add / remove some patches, at least if
they actually don't have anything todo with the rest of the patch set
(if they could be submitted on their own).
On 27.09.2012 10:00, Nozomi Kodama wrot
On Thu, 2012-09-27 at 09:59 +0200, Christian Costa wrote:
> diff --git a/dlls/msi/media.c b/dlls/msi/media.c
> index 612624d..8a39fcd 100644
> --- a/dlls/msi/media.c
> +++ b/dlls/msi/media.c
> @@ -358,8 +358,18 @@ static INT_PTR cabinet_next_cabinet(FDINOTIFICATIONTYPE
> fdint,
>
> if (str
On 27.09.2012 09:56, Nozomi Kodama wrote:
+FLOAT* WINAPI D3DXSHMultiply4(FLOAT *out, CONST FLOAT *a, CONST FLOAT *b)
FLOAT * WINAPI D3DXSHMultiply4(FLOAT *out, const FLOAT *a, const FLOAT *b)
A minor nitpick, anyone against something like? I think that was what
Matteo meant in
http://www.wineh
Hello Jörg,
as always it depends.
On 09/27/2012 09:37 AM, joerg-cyril.hoe...@t-systems.com wrote:
>> +#include
>
> your patch is already committed, yet I believe that the least that dsound
> needs is new asserts.
>
> Asserts in dsound have been a PITA in Wine for the last decade.
>
> It's ok
On 27.09.2012 09:57, Nozomi Kodama wrote:
-FLOAT a[64], b[64], got;
+FLOAT a[49], b[49], got;
CONST FLOAT expected[] =
{ 0.5f, 0.5f, 25.0f, 262.5f, 1428.0f, 5362.0f, 15873.0f, 39812.0f,
88400.0f, };
-for (i = 0; i < 64; i++)
+for (i = 0; i < 49; i++)
-for (i = 0
Michael,
>+#include
your patch is already committed, yet I believe that the least that dsound needs
is new asserts.
Asserts in dsound have been a PITA in Wine for the last decade.
It's ok for the kernel to crash in an assert. IMHO it is not ok for an optional
thing like sound.
The assert's
Hi,
Recently I thought I found a use-case for CreateThread(CREATE_SUSPENDED).
The idiom is to get the thread handle before the thread starts a life on its
own.
I looked at the kernel tests,
http://source.winehq.org/source/dlls/kernel32/tests/thread.c#L460
However, both invocations with CREATE_S
14 matches
Mail list logo
