Re: [PATCH 2/2] msvcrt: Implement _strnicoll.

[Eryk Wieliczko]

Please reject this set as it is obviously wrong.

--
Eryk Wieliczko

2011/2/11 Dmitry Timoshkov :
> Eryk Wieliczko  wrote:
>
>>  /*
>> + *           _strnicoll (MSVCRT.@)
>> + */
>> +int CDECL MSVCRT__strnicoll(const char* str1, const char* str2, int digits)
>> +{
>> +    int res;
>> +
>> +    res = strncmp(str1, str2, digits);
>> +    if (res > 0)
>> +        res = 1;
>> +    else if (res < 0)
>> +        res = -1;
>> +
>> +    return res;
>> +}
>
> The API name implies case insensitive comparison, please add the tests
> for that.
>
> --
> Dmitry.
>
>
>

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

[David Laight]

On Fri, Feb 11, 2011 at 11:16:55PM +0100, Stefan D?singer wrote:
>  Its just that this function goes to great lengths to 
> make sure it doesn't rely on the actual encoding that it is annoying that we 
> have to give it up for detecting the sign of zeroes.

In that case why not?

int
is_neq_z(double x)
{
union {
char i[sizeof (double)];
double d;
} ux, u0;
int i;

if (x != 0.0)
return 0;
u0.d = 0.0;
ux.d = x;
for (i = 0; i < sizeof (double); i++) {
if (ux.i[i] != u0.i[i])
return 1;
}
return 0;
}

Which works provided that there are only 2 encoding patterns for zero.

David

-- 
David Laight: da...@l8s.co.uk

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

[Stefan Dösinger]

Am Freitag 11 Februar 2011, 22:39:05 schrieb David Laight:
> The 'usual' non-IEEE fp systems are vax (you probably can't put enough
> memory in a vax to run wine!) and some arm systems where the two 32bit
> words of a double aren't stored in the expected order!
I don't expect to find any non-IEEE system where wine runs in the near future, 
or maybe in our lifetime. Its just that this function goes to great lengths to 
make sure it doesn't rely on the actual encoding that it is annoying that we 
have to give it up for detecting the sign of zeroes.

If anything I'd say lets just make the actual sign depend on the bits:

if(in == 0.0)
{
if( ((unsigned int) in) == 0x) return 0x;
else return 0x8000;
}
That way if a crazy system crosses our way that happens to encode 42.0 as 
0x8000 we'll get it right and just get the sign of zeroes wrong. However, 
I'd be glad if we had a really foolproof function.

---

For IEEE systems we could optimize the entire routine, protected by ifdefs:
1) Pick apart the 32 bit float like we do in the 16->32 case
2) Shift mantissa and exponent a bit to the right, taking care of rounding
3) Put them together as 16 bit
4) profit!

No exp() and other stuff needed.


signature.asc
Description: This is a digitally signed message part.

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

[David Laight]

On Fri, Feb 11, 2011 at 10:20:10PM +0100, Stefan D?singer wrote:
> Am Freitag 11 Februar 2011, 20:48:58 schrieb Misha Koshelev:
> 
> > +if (*((unsigned int *)&in) == 0x) return 0x;
> > +if (*((unsigned int *)&in) == 0x8000) return 0x8000;
> Thinking about it, there's something about this line that is not so nice: It 
> relies on the actual encoding of the float, which may technically be platform 
> specific if there's a CPU that implements non-IEEE- 754 floats.

The 'usual' non-IEEE fp systems are vax (you probably can't put enough
memory in a vax to run wine!) and some arm systems where the two 32bit
words of a double aren't stored in the expected order!

Some embedded systems might not bother with denormalised encodings
for values near zero. I don't know if anything uses an abolute offset
to avoid that gap (the main difference between aLaw anf uLaw audio).

It also requires that the compiler use stricter data aliasing rules
than are required by the C standard.
Using a union is ok (but you must write and read a union variable,
not just cast to a union type.

David

-- 
David Laight: da...@l8s.co.uk

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

[Stefan Dösinger]

Am Freitag 11 Februar 2011, 20:48:58 schrieb Misha Koshelev:

> +if (*((unsigned int *)&in) == 0x) return 0x;
> +if (*((unsigned int *)&in) == 0x8000) return 0x8000;
Thinking about it, there's something about this line that is not so nice: It 
relies on the actual encoding of the float, which may technically be platform 
specific if there's a CPU that implements non-IEEE- 754 floats.

You could try something like this(pseudo code, I removed the *s)

if(in == 0.0)
{
if(sign(1.0 / in) == positive) return 0x;
else return 0x8000;
}

The idea is that 1.0 / 0.0 returns Inf and 1.0 / -0.0 -Inf. I may be mistaken 
about that though.


signature.asc
Description: This is a digitally signed message part.

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

[Misha Koshelev]

On Fri, Feb 11, 2011 at 3:58 PM, Stefan Dösinger  wrote:
> Am Freitag 11 Februar 2011, 20:48:58 schrieb Misha Koshelev:
>> Stefan et al:
>>
>> Thank you. How about this guy?
>
>> +    if (exp > 31)
>> +    {
>> +        /* too big */
>> +        ret = 0x7fff; /* INF */
>> +    }
> That's not INF, that is NaN. Or, if you don't read it as a special value the
> highest possible positive number in a float16 format that doesn't understand
> NaNs or INFs
>
> Otherwise it looks OK
>

Thank you.

Misha

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

[Stefan Dösinger]

Am Freitag 11 Februar 2011, 20:48:58 schrieb Misha Koshelev:
> Stefan et al:
> 
> Thank you. How about this guy?

> +if (exp > 31)
> +{
> +/* too big */
> +ret = 0x7fff; /* INF */
> +}
That's not INF, that is NaN. Or, if you don't read it as a special value the 
highest possible positive number in a float16 format that doesn't understand 
NaNs or INFs

Otherwise it looks OK


signature.asc
Description: This is a digitally signed message part.

Re: d3dx9: Implement D3DXFloat16to32Array and D3DXFloat32to16Array.

[Misha Koshelev]

On Wed, Feb 9, 2011 at 4:40 AM, Stefan Dösinger  wrote:
> Am Dienstag 08 Februar 2011, 22:45:52 schrieb Misha Koshelev:
>> I don't have msvc. Please suggest how I can check this. Thank you. Yours
>> Misha
> According to http://www.johndcook.com/math_h.html it exists, but has a
> different name. So we'd need some wrapper around it in libwine. Maybe one
> exists already, I can't check right now. If not I recommend to stick to
> isnan() and isinf()
>

Stefan et al:

Thank you. How about this guy?

I'm using isnan(), isinf(), and a hex comparison for +0.0f and -0.0f.

Misha
From c623532b3aa1e48869ec62e8eda0e15faaa950fd Mon Sep 17 00:00:00 2001
From: Misha Koshelev 
Date: Fri, 11 Feb 2011 14:01:55 -0500
Subject: d3dx9: Implement D3DXFloat32To16Array and D3DXFloat16To32Array.
To: wine-patches 
Reply-To: wine-devel 

---
 dlls/d3dx9_36/d3dx9_36.spec |4 +-
 dlls/d3dx9_36/math.c|  104 +++
 dlls/d3dx9_36/tests/math.c  |   50 
 include/d3dx9math.h |   18 +++
 include/d3dx9math.inl   |   31 +
 5 files changed, 205 insertions(+), 2 deletions(-)

diff --git a/dlls/d3dx9_36/d3dx9_36.spec b/dlls/d3dx9_36/d3dx9_36.spec
index cbb6d20..55fe0cb 100644
--- a/dlls/d3dx9_36/d3dx9_36.spec
+++ b/dlls/d3dx9_36/d3dx9_36.spec
@@ -130,8 +130,8 @@
 @ stub D3DXFillVolumeTextureTX
 @ stdcall D3DXFilterTexture(ptr ptr long long)
 @ stdcall D3DXFindShaderComment(ptr long ptr ptr)
-@ stub D3DXFloat16To32Array
-@ stub D3DXFloat32To16Array
+@ stdcall D3DXFloat16To32Array(ptr ptr long)
+@ stdcall D3DXFloat32To16Array(ptr ptr long)
 @ stub D3DXFrameAppendChild
 @ stub D3DXFrameCalculateBoundingSphere
 @ stub D3DXFrameDestroy
diff --git a/dlls/d3dx9_36/math.c b/dlls/d3dx9_36/math.c
index fdb5f92..30ba523 100644
--- a/dlls/d3dx9_36/math.c
+++ b/dlls/d3dx9_36/math.c
@@ -1769,3 +1769,107 @@ D3DXVECTOR4* WINAPI D3DXVec4TransformArray(D3DXVECTOR4* out, UINT outstride, CON
 }
 return out;
 }
+
+static inline unsigned short float_32_to_16(const float in)
+{
+int exp = 0;
+float tmp = fabs(in);
+int sign = signbit(in);
+unsigned int mantissa;
+unsigned short ret;
+
+/* Deal with special numbers */
+if (isinf(in)) return (sign ? 0x : 0x7c00);
+if (isnan(in)) return (sign ? 0x : 0x7fff);
+if (*((unsigned int *)&in) == 0x) return 0x;
+if (*((unsigned int *)&in) == 0x8000) return 0x8000;
+if (fabs(in) > 65520) return (sign ? 0xfc00 : 0x7c00);
+
+if (tmp < powf(2, 10))
+{
+do
+{
+tmp = tmp * 2.0f;
+exp--;
+} while (tmp < powf(2, 10));
+}
+else if (tmp >= powf(2, 11))
+{
+do
+{
+tmp /= 2.0f;
+exp++;
+} while (tmp >= powf(2, 11));
+}
+
+mantissa = (unsigned int) tmp;
+if (tmp - mantissa > 0.5f) mantissa++; /* round to nearest, away from zero */
+
+exp += 10;  /* Normalize the mantissa */
+exp += 15;  /* Exponent is encoded with excess 15 */
+
+if (exp > 31)
+{
+/* too big */
+ret = 0x7fff; /* INF */
+}
+else if (exp <= 0)
+{
+/* exp == 0: Non-normalized mantissa. Returns 0x (=0.0) for too small numbers */
+while (exp <= 0)
+{
+mantissa = mantissa >> 1;
+exp++;
+}
+ret = mantissa & 0x3ff;
+}
+else
+{
+ret = (exp << 10) | (mantissa & 0x3ff);
+}
+
+ret |= ((sign ? 1 : 0) << 15); /* Add the sign */
+return ret;
+}
+
+D3DXFLOAT16 *WINAPI D3DXFloat32To16Array(D3DXFLOAT16 *pout, CONST FLOAT *pin, UINT n)
+{
+unsigned int i;
+
+for (i = 0; i < n; ++i)
+{
+pout[i].value = float_32_to_16(pin[i]);
+}
+
+return pout;
+}
+
+static inline float float_16_to_32(const unsigned short in)
+{
+const unsigned short s = (in & 0x8000);
+const unsigned short e = (in & 0x7C00) >> 10;
+const unsigned short m = in & 0x3FF;
+const float sgn = (s ? -1.0f : 1.0f);
+
+if (e == 0)
+{
+if (m == 0) return sgn * 0.0f; /* +0.0 or -0.0 */
+else return sgn * powf(2, -14.0f) * ((float)m / 1024.0f);
+}
+else
+{
+return sgn * powf(2, (float)e - 15.0f) * (1.0f + ((float)m / 1024.0f));
+}
+}
+
+FLOAT *WINAPI D3DXFloat16To32Array(FLOAT *pout, CONST D3DXFLOAT16 *pin, UINT n)
+{
+unsigned int i;
+
+for (i = 0; i < n; ++i)
+{
+pout[i] = float_16_to_32(pin[i].value);
+}
+
+return pout;
+}
diff --git a/dlls/d3dx9_36/tests/math.c b/dlls/d3dx9_36/tests/math.c
index e455a96..34d16a9 100644
--- a/dlls/d3dx9_36/tests/math.c
+++ b/dlls/d3dx9_36/tests/math.c
@@ -21,6 +21,7 @@
 
 #include "wine/test.h"
 #include "d3dx9.h"
+#include 
 
 #define ARRAY_SIZE 5
 
@@ -2216,6 +2217,54 @@ static void test_D3DXVec_Array(void)
 compare_planes(exp_plane, out_plane);
 }
 
+static void test_D3DXFloat_Array(void)
+{
+unsigned int i;
+void *out = NULL;
+D3DX

Re: [rfc] dsound: decrease sound latency

[Austin English]

On Fri, Feb 11, 2011 at 01:43, Maarten Lankhorst
 wrote:
>  Hi all,
>
> Please test this and let me know if it's causing any problems in sound
> playback, preferably with media applications and games, any feedback would
> be appreciated. The patch won't fix existing problems, it should just
> decrease the audio lag. As such I would prefer only to receive feedback on
> issues INTRODUCED or FIXED by this patch.
>
> If it's causing issues, I want to know:
> 1. Whether pulseaudio is running, and pulseaudio --version
> 2. What distribution you're using
> 3. (If you know it) the version of alsa's libraries, packages libasound2 and
> libasound2-plugins in debian/ubuntu

I sent this to wine-users, but just for the record, you can set the
values in the registry, if compiling is inconvenient for some reason:

[HKCU\\Software\\Wine\\DirectSound]
"SndQueueMax"="4"
"SndQueueMin"="4"

-- 
-Austin

Re: iphlpapi: Hint what to do when icmp does not work

[Charles Davis]

On 2/11/11 11:31 AM, Janne Hakonen wrote:
> Maybe this information could be added to http://wiki.winehq.org/FAQ
> instead?
Judging from wine-users, nobody bothers to read that, at least until
someone tells them to.

For that matter, nobody bothers to read the logs either. It's kinda sad,
actually. Most users on wine-users expect someone else to read the logs
for them and then magically fix everything. No, it's worse than that:
all they usually see is that something bad happened, and then they post
to wine-users and somebody has to *tell* them to post logs. (And there's
probably a sticky on the forum telling them to do that!) And like I
said, they don't even look at the log; they just copy from Terminal (or
Konsole, or whatever xterm-like app they use) and paste into their email
or forum post, and never even bother to see what the log actually says
because it's all gibberish to them. So then the people who actually know
what they're doing have to sift through the log for them, and they can't
be too happy about that.

On second thought, maybe it would be best if we put it into the FAQ. At
least then the forum moderators can post a terse "look in the FAQ"
response. Like I said earlier, we certainly shouldn't print this message
unconditionally to the winediag channel.

Also, for the future, I recommend bottom-posting instead of top-posting.
Just a little style note.

Chip

Re: iphlpapi: Hint what to do when icmp does not work

[Janne Hakonen]

Maybe this information could be added to http://wiki.winehq.org/FAQ instead?

Janne

-Original Message- 
From: Charles Davis

Sent: Friday, February 11, 2011 8:17 PM
To: wine-devel@winehq.org
Subject: Re: iphlpapi: Hint what to do when icmp does not work

On 2/11/11 11:12 AM, André Hentschel wrote:
Otherwise the user might try running wine as root or doesn't know that 
this error can be easily fixed when needed.

---
 dlls/iphlpapi/icmp.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/dlls/iphlpapi/icmp.c b/dlls/iphlpapi/icmp.c
index d8ee101..41d1940 100644
--- a/dlls/iphlpapi/icmp.c
+++ b/dlls/iphlpapi/icmp.c
@@ -155,6 +155,7 @@ HANDLE WINAPI IcmpCreateFile(VOID)
 int sid=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP);
 if (sid < 0) {
 ERR_(winediag)("Failed to use ICMP (network ping), this requires 
special permissions.\n");
+ERR_(winediag)("Try running \"sudo setcap cap_net_raw+epi 
/usr/bin/wine-preloader\".\n");

That only works on systems that support POSIX capabilities (Linux, and
maybe OpenBSD).

Chip

Re: iphlpapi: Hint what to do when icmp does not work

[Charles Davis]

On 2/11/11 11:12 AM, André Hentschel wrote:
> Otherwise the user might try running wine as root or doesn't know that this 
> error can be easily fixed when needed.
> ---
>  dlls/iphlpapi/icmp.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/dlls/iphlpapi/icmp.c b/dlls/iphlpapi/icmp.c
> index d8ee101..41d1940 100644
> --- a/dlls/iphlpapi/icmp.c
> +++ b/dlls/iphlpapi/icmp.c
> @@ -155,6 +155,7 @@ HANDLE WINAPI IcmpCreateFile(VOID)
>  int sid=socket(AF_INET,SOCK_RAW,IPPROTO_ICMP);
>  if (sid < 0) {
>  ERR_(winediag)("Failed to use ICMP (network ping), this requires 
> special permissions.\n");
> +ERR_(winediag)("Try running \"sudo setcap cap_net_raw+epi 
> /usr/bin/wine-preloader\".\n");
That only works on systems that support POSIX capabilities (Linux, and
maybe OpenBSD).

Chip

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

[Juan Lang]

> It looks like introducing bigger patches is a kind of mission impossible.

That's not a bad analogy.  Your mission, Krzysztof, should you choose
to accept it, to improve sound resampling in Wine :)
--Juan

Re: Resend: Who does c2man?

[Juan Lang]

> It looks like Jon Griffiths is the one I need to contact. Is he still
> around?

He's often disconnected, but he does respond to email from time to time.
--Juan

Re: Resend: Who does c2man?

[Max TenEyck Woodbury]

On 02/11/2011 12:20 PM, GOUJON Alexandre wrote:

On 02/11/2011 05:19 PM, Max TenEyck Woodbury wrote:

I have just been going over tools/c2man and have a fair number of
questions about it.


You can ask them here. This is why wine-devel exists.
There is also IRC (http://wiki.winehq.org/IRC)

But keep in mind that everyone is very busy. So ask something useful.
If you are too lazy to read the source code, then don't be surprised if
you don't get any answer.


Umm, I HAVE been reading the source code. There is quite a lot of it
and there are not a lot of descriptive comments. There are a few things
I think need changing but some people might consider those changes
controversial. Such things as links that go nowhere and mangled names.
Also places where the parsing of the input does one thing while the
comments say it does something slightly different (and the comments are
what should be done).


Please send me
email with contact information, or indicate that you want this done on
some forum.


wine/tools$ git blame c2man.pl


Thanks, that was useful. Summary:

Mike McCormack who was the original author around Aug 2000.
Jon Griffiths who rewrote most of it from Mar 2003 thru Dec 2004.
Francois Gouget who made some changes in Oct 2004.
Stefan Stranz who added XML stuff in Jun 2009.
A few others with small changes some time ago.

It looks like Jon Griffiths is the one I need to contact. Is he still
around?

Max

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

[Krzysztof Nikiel]

2011/2/11  :
> Hi,
>
> The question how to split is interesting.  I haven't found the answer
> about how to split my future MIDI player rewrite either.  Like yours,
> it will replace old functions with something new.

It looks like introducing bigger patches is a kind of mission impossible.

>
> Some guidelines are:
>  - Each patch should be self contained and a logical unit, e.g.
>  + a bug fix, possibly with test
>e.g. ZeroMemory => FillMemory wBitsPerSample == 8 ? 128 : 0
>  + a change in configuration (e.g. sampling rate 48000)
>=> split change of default & introduction new of registry key
>  + some refactoring in preparation for future work
>  + changes to logic & functionality
>e.g. DSDDESC_DONTNEEDWRITELEAD, leadin
>  - It must compile.
>  - It should pass tests (a rule, not a dogma).
>
> In this light, [PATCH 08/13] (remove 2x HeapFree) looks wrong, unless
> it fixed a bug in the old code.  It should be part of something else.

But the question is: remove everything unused in one patch or split
the removing.

>
> Try and explain design changes.  Your code is not only a resampler, it
> also changes the way DSound performs mixing, such that
> DSOUND_MixToTemporary becomes superfluous.
>
>
> What's not so nice -- yet that has happened several times already --
> is to have a patch like "Now use the new functions added in the last 12
> patches instead of the old ones", because regression testing will
> irremediably identify that patch as culprit and not help identify
> which of the 12 introducing patches caused the "actual" regression via
> a subtle change in behaviour or side effects.

I would reduce it to two options:
1. Add first, remove last;
2. Remove/stubify first, add last.

First option looks more reasonable to me.

>
> Conversely, if you think about how regression testing can work well,
> you'll find recommendations for patches yourself.

Do you mean bisecting it? I would just wish a good luck to anyone
bisecting such patch.
In this case, I would rather fix bugs more traditional way.

>
> About ordering: Move the patch introducing the new registry key
> towards the end, and work with a constant prior to that.  Doing so,
> this patch becomes working code instead of being ground work not
> testable until the resampler is in place.
>
> I suggest isolating
>  - the FIR generator + Makefile change.
>  - keeping patch 11 -- remove unused files & code last -- so as to
>   minimize size of patches that introduce code.
>
> As a side note, I'm wondering whether I'd insert resample.c into mixer.c.

No way, at least I'm not going to realize such a crazy idea. You're
welcome to try.

>
> +TRACE("resample quality: %d\n", dsb->quality);
> +TRACE("resample firstep %d\n", dsb->firstep);
> Logging is expensive (when on) and known to cause race
> conditions.  Hence I'd combine all these into one line.

Those were used for debugging but now are no longer useful, can be removed.

Thanks.

Re: CD handling on MacOS - the big picture?

[Ken Thomases]

On Feb 11, 2011, at 10:23 AM,  
 wrote:

> Mixed CDs occur in some games, but some audio CDs
> contain "bonus content" as well.
> 
> On MacOS, mixed CDs are mounted as two volumes
> - the audio part,
> - the data/binary section
> not unlike Gnome which also displays 2 disc icons on the desktop.
> 
> On Linux, Wine manages to map both to a single CD-ROM
> drive letter like D:, such that
> - D:\data\foo.exe works as well as
> - MCICDA: open D: type cdaudio alias D; play D work (but see bug 20555),
> which mimics native's behaviour.
> 
> On MacOS, we're not there yet. I've no idea how that can be made to work.
> How would Wine on MacOS join the pieces?

I guess I'd say that Wine should create a drive letter only for the data/binary 
section.  I suspect that that's already the case due to the logic in 
mountmgr.sys/diskarb.c.

Then, if some code needs to find the whole-media device that contains that 
section, it could use something like the get_parent_device() function in 
dlls/ntdll/cdrom.c.  From there, it might have to enumerate the child entries 
to find the audio part.  I don't know how one checks for that.  Playing with 
such a mixed CD and /Developer/Applications/Utilities/IORegistryExplorer.app 
might be helpful in figuring that out.

Cheers,
Ken

Re: Resend: Who does c2man?

[GOUJON Alexandre]

On 02/11/2011 05:19 PM, Max TenEyck Woodbury wrote:

I have just been going over tools/c2man and have a fair number of
questions about it.

You can ask them here.
This is why wine-devel exists.
There is also IRC (http://wiki.winehq.org/IRC)

But keep in mind that everyone is very busy.
So ask something useful.
If you are too lazy to read the source code, then don't be surprised if 
you don't get any answer.



Please send me
email with contact information, or indicate that you want this done on
some forum.

wine/tools$ git blame c2man.pl

[PATCH 01/13] dsound: New sample rate converter core functions.

[Joerg-Cyril.Hoehle]

Hi,

The question how to split is interesting.  I haven't found the answer
about how to split my future MIDI player rewrite either.  Like yours,
it will replace old functions with something new.

Some guidelines are:
 - Each patch should be self contained and a logical unit, e.g.
  + a bug fix, possibly with test
e.g. ZeroMemory => FillMemory wBitsPerSample == 8 ? 128 : 0
  + a change in configuration (e.g. sampling rate 48000)
=> split change of default & introduction new of registry key
  + some refactoring in preparation for future work
  + changes to logic & functionality
e.g. DSDDESC_DONTNEEDWRITELEAD, leadin
 - It must compile.
 - It should pass tests (a rule, not a dogma).

In this light, [PATCH 08/13] (remove 2x HeapFree) looks wrong, unless
it fixed a bug in the old code.  It should be part of something else.

Try and explain design changes.  Your code is not only a resampler, it
also changes the way DSound performs mixing, such that
DSOUND_MixToTemporary becomes superfluous.


What's not so nice -- yet that has happened several times already --
is to have a patch like "Now use the new functions added in the last 12
patches instead of the old ones", because regression testing will
irremediably identify that patch as culprit and not help identify
which of the 12 introducing patches caused the "actual" regression via
a subtle change in behaviour or side effects.

Conversely, if you think about how regression testing can work well,
you'll find recommendations for patches yourself.

About ordering: Move the patch introducing the new registry key
towards the end, and work with a constant prior to that.  Doing so,
this patch becomes working code instead of being ground work not
testable until the resampler is in place.

I suggest isolating
 - the FIR generator + Makefile change.
 - keeping patch 11 -- remove unused files & code last -- so as to
   minimize size of patches that introduce code.

As a side note, I'm wondering whether I'd insert resample.c into mixer.c.

+TRACE("resample quality: %d\n", dsb->quality);
+TRACE("resample firstep %d\n", dsb->firstep);
Logging is expensive (when on) and known to cause race
conditions.  Hence I'd combine all these into one line.

Also keep in mind that your reactions here will influence acceptance
of your code -- "Does this person sound like s/he's going to support
and fix regressions in her/his code or is it 'take or leave, bye'?"

Regards,
 Jörg Höhle

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

[Krzysztof Nikiel]

2011/2/11 Maarten Lankhorst :
>> Well, previous version of this patch was rejected as "needs
>> splitting", it's basically too big to be send as a single patch. It
>> can be applied as several smaller chunks or rejected as a whole. I
>> don't think there is any other option.
>
> Thanks for looking at the format conversion functions. The splitting can
> probably be done in 4 parts:
> 1. If you have any generic bugfixes, put them in the first few patches. Once
> those are in you can look at the other parts. Each bugfix should probably be
> its own separate patch.
> 2. Single patch to remove the old behavior. At this point you probably only
> want the mixing to work without requiring reconversion, and have a FIXME or
> something to say rate conversion is unavailable.
> 3. A bunch of patches implementing new rate conversion, one logical step at
> a time. The only requirement is that you want to be able to build wine
> without it failing, and if possible even running directsound, even if the
> result is insane..

Thanks, now I have at least two reasonable advices how to proceed with
the split.
It looks like the actual split may be more difficult to make than the
patch itself :P

>
> Having mkfir in the way you put it there will probably not work, since some
> people will build wine out of tree. My guess is that you should put that in
> tools. Since the contents of the file won't change often it may just be
> enough to have the .c file there and have a note in the mkfir.h header that
> it was generated by tools/mkfir.c, but I'm not AJ so he would have to
> decide.

Yes, 'tools' seems a good place to put it. I think if someone is
really inclined to know where 'firtab.h' comes from it won't be a real
problem to find it.
I'm not sure what "out of tree" means but I think it does work out of
tree. Anyway, if you like the unwrapped version, just visit the
bugzilla and download the .zip pack.

http://bugs.winehq.org/show_bug.cgi?id=14717


>
> The reason for this kind of splitting is that even if the code is broken
> between the removal of the old code and the last patch, it's a lot easier to
> see bugs. Usually in a patch like this you will spot 2 or 3 bugs you
> wouldn't have otherwise spotted because you look at the code in logical
> parts. This also makes bisecting a lot easier. Otherwise you know what
> commit caused the regression, but you have no idea what part of the code is.

I expected it will be a problematic patch. It's quite big and the
original code is rather messy, especially mixer.c.
I really doubt the patch will be easy to read even when split as you say.

>
> Cheers,
> Maarten
>

CD handling on MacOS - the big picture?

[Joerg-Cyril.Hoehle]

Hi,

the last years have seen individual patches by K. Thomases and C. Davis
to Mac OSX' CD handling, but I don't see the big picture.

Mixed CDs occur in some games, but some audio CDs
contain "bonus content" as well.

On MacOS, mixed CDs are mounted as two volumes
 - the audio part,
 - the data/binary section
not unlike Gnome which also displays 2 disc icons on the desktop.

On Linux, Wine manages to map both to a single CD-ROM
drive letter like D:, such that
 - D:\data\foo.exe works as well as
 - MCICDA: open D: type cdaudio alias D; play D work (but see bug 20555),
which mimics native's behaviour.

On MacOS, we're not there yet. I've no idea how that can be made to work.
How would Wine on MacOS join the pieces?

Regards,
 Jörg Höhle

Resend: Who does c2man?

[Max TenEyck Woodbury]

I have just been going over tools/c2man and have a fair number of
questions about it.  I can probably dig some of the answers out myself,
but it would probably go faster and raise less fuss if I can talk to
the person (people) who have worked on it previously. Please send me
email with contact information, or indicate that you want this done on
some forum.

Max

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

[Maarten Lankhorst]

 Hi Krzysztof,

Op 11-02-11 12:16, Krzysztof Nikiel schreef:

2011/2/11 Dmitry Timoshkov:

Krzysztof Nikiel  wrote:


You can't send Makefile changes separately from added/removed
files, a patch should not add dead code.

Could you explain "dead code", all 13 parts need to be applied,
otherwise the code will be broken.

Wine should compile and be able to pass 'make test' after each separate patch.
You can't add for instance dlls/dsound/resample.c in one patch, and add it to
Makefile or use interfaces provided by it in some later patches. Every patch
should be finished and self-containing.

Well, previous version of this patch was rejected as "needs
splitting", it's basically too big to be send as a single patch. It
can be applied as several smaller chunks or rejected as a whole. I
don't think there is any other option.
Thanks for looking at the format conversion functions. The splitting can 
probably be done in 4 parts:
1. If you have any generic bugfixes, put them in the first few patches. 
Once those are in you can look at the other parts. Each bugfix should 
probably be its own separate patch.
2. Single patch to remove the old behavior. At this point you probably 
only want the mixing to work without requiring reconversion, and have a 
FIXME or something to say rate conversion is unavailable.
3. A bunch of patches implementing new rate conversion, one logical step 
at a time. The only requirement is that you want to be able to build 
wine without it failing, and if possible even running directsound, even 
if the result is insane..


Having mkfir in the way you put it there will probably not work, since 
some people will build wine out of tree. My guess is that you should put 
that in tools. Since the contents of the file won't change often it may 
just be enough to have the .c file there and have a note in the mkfir.h 
header that it was generated by tools/mkfir.c, but I'm not AJ so he 
would have to decide.


The reason for this kind of splitting is that even if the code is broken 
between the removal of the old code and the last patch, it's a lot 
easier to see bugs. Usually in a patch like this you will spot 2 or 3 
bugs you wouldn't have otherwise spotted because you look at the code in 
logical parts. This also makes bisecting a lot easier. Otherwise you 
know what commit caused the regression, but you have no idea what part 
of the code is.


Cheers,
Maarten

Re: [PATCH 01/13] dsound: New sample rate converter core functions. (resend)

[Krzysztof Nikiel]

2011/2/11 Vitaliy Margolen :
> On 02/11/2011 04:34 AM, Krzysztof Nikiel wrote:
>>
>> +typedef double sample_t;
>>
>> +static inline sample_t getsample(LPBYTE buf, INT bps)
>> +{
>> +        tmp = ((sample_t) (*((BYTE *) buf)) - 128.0);
>
> No need to type cast. "buf" already a pointer to the BYTE. You can use it
> directly as *buf or buf[0], which is even more readable.

Indeed, but I think it would be even better to change 'buf' type to
void* as the actual size/type is defined by 'bps'.

>
>> +static inline void putsample(LPBYTE buf, INT bps, sample_t smp)
>> +        CLIPSAMPLE(smp, (double) 0x7fff);
>
> Typecasts are bad, especially that the type of "smp" is not "double". Please
> use "32767.0" instead.

So maybe something like (sample_t)0x7fff would be better or better yet
move the typecast to the macro definition.

>
>> +    DOUBLE amp[3];
>
> Mixing types again. If you defined your own type then please use it. Or make
> everything the same type whichever it is.

I'm not quite sure what type it should be, 'sample_t' doesn't look
quite good to me but maybe you're right.

>
>
>> [PATCH 02/13] dsound: Resample filter table generator. (resend)
>
> Don't think compiler helpers should be going into dll directories. The more
> correct place is tools. But it's up to AJ.

Ah, I see.

>
>
> And as others noted, your patch series is not split correctly. Each patch
> will break Wine tree until the very last one. This is against the patch
> requirements that code tree should compile after every commit.
>
> You can put your compile helper with it's make file first. Then add your
> resampling code with a make file changes to compile it. But not use it yet
> (it does break another rule for adding dead code, but that's the only way
> you can split the entire series). After that make use of your new resampler,
> removing all conflicting code, so Wine will work. Last commit can be a
> cleanup for all remaining pieces that are no longer used.

Sounds reasonable, but not quite easy to do. It looks like wine will
use old code for some time until I try to do the correct split.
Thanks.

>
> Vitaliy.
>

Testmail

[Detlef Riekenberg]

Hi

Just a test, as my patches do not show up in the mail archive.

Detlef


___
WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit 
gratis Handy-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2

Re: [PATCH] dsound: More accurate volume calculation.

[Krzysztof Nikiel]

Sure, I'm working on it.

2011/2/11 Vitaliy Margolen :
> On 02/11/2011 02:38 AM, Krzysztof Nikiel wrote:
>>
>> I have changed this when creating the new resampler patch but it's not
>> really related to the main patchset.
>
> The patch is wrapped. Please send it as attachment. Also please no HTML when
> sending patches.
>
> Vitaliy
>

Re: [PATCH] dsound: More accurate volume calculation.

[Vitaliy Margolen]

On 02/11/2011 02:38 AM, Krzysztof Nikiel wrote:

I have changed this when creating the new resampler patch but it's not
really related to the main patchset.


The patch is wrapped. Please send it as attachment. Also please no HTML when 
sending patches.


Vitaliy

Re: [PATCH 01/13] dsound: New sample rate converter core functions. (resend)

[Vitaliy Margolen]

Nice job! If it will make Wine's sound better - it would be awesome.

Haven't read the entire patch series. But few nit picks so far.

On 02/11/2011 04:34 AM, Krzysztof Nikiel wrote:

+typedef double sample_t;

+static inline sample_t getsample(LPBYTE buf, INT bps)
+{
+tmp = ((sample_t) (*((BYTE *) buf)) - 128.0);
No need to type cast. "buf" already a pointer to the BYTE. You can use it 
directly as *buf or buf[0], which is even more readable.



+static inline void putsample(LPBYTE buf, INT bps, sample_t smp)
+CLIPSAMPLE(smp, (double) 0x7fff);
Typecasts are bad, especially that the type of "smp" is not "double". Please 
use "32767.0" instead.



+DOUBLE amp[3];
Mixing types again. If you defined your own type then please use it. Or make 
everything the same type whichever it is.




[PATCH 02/13] dsound: Resample filter table generator. (resend)


Don't think compiler helpers should be going into dll directories. The more 
correct place is tools. But it's up to AJ.



And as others noted, your patch series is not split correctly. Each patch 
will break Wine tree until the very last one. This is against the patch 
requirements that code tree should compile after every commit.


You can put your compile helper with it's make file first. Then add your 
resampling code with a make file changes to compile it. But not use it yet 
(it does break another rule for adding dead code, but that's the only way 
you can split the entire series). After that make use of your new resampler, 
removing all conflicting code, so Wine will work. Last commit can be a 
cleanup for all remaining pieces that are no longer used.


Vitaliy.

Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

[Nikolay Sivov]

On 2/11/2011 15:56, Jacek Caban wrote:

On 2/11/11 12:02 PM, Nikolay Sivov wrote:

On 2/11/2011 13:30, Alistair Leslie-Hughes wrote:

Hi,

--
From: "Nikolay Sivov" 
Sent: Friday, February 11, 2011 9:27 PM
To: "Alistair Leslie-Hughes" 
Cc: 
Subject: Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest


On 2/11/2011 12:25, Alistair Leslie-Hughes wrote:

Hi,

On 11/02/2011 8:12 PM, Nikolay Sivov wrote:

On 2/11/2011 10:51, Alistair Leslie-Hughes wrote:

Hi,


Changelog:
msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

What's a purpose of this?

To remove the FIXME from appearing in the logs.
What application is that? Does it appear running in browser 
scripting by any chance?
Yes, it was a website that uses XMLHTTPRequest to load files off the 
local

filesystem.
My point is that browser scripting engine shouldn't query for that 
interface in a first place probably, so it's interesting to figure 
out why it's queried instead of silence it. Is it possible to 
reproduce that with wine-gecko or I need IE?


P.S. cc-ing Jacek, as he knows probably why such dead queries happen.


It's queried by mshtml security manager and the query is right. It's 
just the way to check if created object (usually via ActiveXObject 
call in jscript) is a script engine. Once script engine owns an 
objects, it queries for a few more ifaces for which returning 
E_NOINTERFACE is perfectly valid and expected behavior. I think the 
right fix in this case is silencing the FIXME (downgrading to WARN or 
TRACE). FIXME in QueryInterface implementation is a good thing for 
objects that implement a lot different ifaces and it's likely that 
lack of some will cause app failure or objects that are unlikely to be 
queried for unimplemented ifaces. I think it's not the case here.
Ok, thanks for explanation. So it's fine to silence it in this case or 
course.


Cheers,
Jacek

Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

[Jacek Caban]

On 2/11/11 12:02 PM, Nikolay Sivov wrote:

On 2/11/2011 13:30, Alistair Leslie-Hughes wrote:

Hi,

--
From: "Nikolay Sivov" 
Sent: Friday, February 11, 2011 9:27 PM
To: "Alistair Leslie-Hughes" 
Cc: 
Subject: Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest


On 2/11/2011 12:25, Alistair Leslie-Hughes wrote:

Hi,

On 11/02/2011 8:12 PM, Nikolay Sivov wrote:

On 2/11/2011 10:51, Alistair Leslie-Hughes wrote:

Hi,


Changelog:
msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

What's a purpose of this?

To remove the FIXME from appearing in the logs.
What application is that? Does it appear running in browser 
scripting by any chance?
Yes, it was a website that uses XMLHTTPRequest to load files off the 
local

filesystem.
My point is that browser scripting engine shouldn't query for that 
interface in a first place probably, so it's interesting to figure out 
why it's queried instead of silence it. Is it possible to reproduce 
that with wine-gecko or I need IE?


P.S. cc-ing Jacek, as he knows probably why such dead queries happen.


It's queried by mshtml security manager and the query is right. It's 
just the way to check if created object (usually via ActiveXObject call 
in jscript) is a script engine. Once script engine owns an objects, it 
queries for a few more ifaces for which returning E_NOINTERFACE is 
perfectly valid and expected behavior. I think the right fix in this 
case is silencing the FIXME (downgrading to WARN or TRACE). FIXME in 
QueryInterface implementation is a good thing for objects that implement 
a lot different ifaces and it's likely that lack of some will cause app 
failure or objects that are unlikely to be queried for unimplemented 
ifaces. I think it's not the case here.


Cheers,
Jacek

Re: [PATCH 01/13] dsound: New sample rate converter core functions. (resend)

[Owen Rudge]

It looks like it may be too big to be accepted. Anyway, I will try to
resend it with 4 space indent for new files.
Hopefully these patches won't get wrapped this time.


Your patches still appear to be being wrapped by your mail client. Try 
sending them as an attachment instead of inline (i.e., use the --attach 
parameter to git format-patch).


--
Owen Rudge
http://www.owenrudge.net/

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

[Krzysztof Nikiel]

2011/2/11 Ricardo Filipe :
>
>
> 2011/2/11 Krzysztof Nikiel 
>>
>> 2011/2/11 Dmitry Timoshkov :
>> > Krzysztof Nikiel  wrote:
>> >
>> >> > You can't send Makefile changes separately from added/removed
>> >> > files, a patch should not add dead code.
>> >>
>> >> Could you explain "dead code", all 13 parts need to be applied,
>> >> otherwise the code will be broken.
>> >
>> > Wine should compile and be able to pass 'make test' after each separate
>> > patch.
>> > You can't add for instance dlls/dsound/resample.c in one patch, and add
>> > it to
>> > Makefile or use interfaces provided by it in some later patches. Every
>> > patch
>> > should be finished and self-containing.
>>
>> Well, previous version of this patch was rejected as "needs
>> splitting", it's basically too big to be send as a single patch. It
>> can be applied as several smaller chunks or rejected as a whole. I
>> don't think there is any other option.
>>
>>
>
> still, what dmitry told you still holds. wine needs to be able to compile
> and pass the tests after each patch is applied. at least the makefile
> changes should be merged with the previous patches that needs them (1 and
> 2). the rest seems like fine splitting, although i don't know the code.
> what i'm not sure is, if resampler is still not called after the first
> patches, if it is fine to send those first patches... i think you also need
> to call resampler for the patch to be accepted, even if it is just as a
> stub, incomplete version.

It's not that easy, I don't think it would be just incomplete, it
would be broken.
The original code is rather messy, especially mixer.c, no wonder no
one wanted to touch it to fix the really poor sample rate conversion.

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

[Ricardo Filipe]

2011/2/11 Krzysztof Nikiel 

> 2011/2/11 Dmitry Timoshkov :
> > Krzysztof Nikiel  wrote:
> >
> >> > You can't send Makefile changes separately from added/removed
> >> > files, a patch should not add dead code.
> >>
> >> Could you explain "dead code", all 13 parts need to be applied,
> >> otherwise the code will be broken.
> >
> > Wine should compile and be able to pass 'make test' after each separate
> patch.
> > You can't add for instance dlls/dsound/resample.c in one patch, and add
> it to
> > Makefile or use interfaces provided by it in some later patches. Every
> patch
> > should be finished and self-containing.
>
> Well, previous version of this patch was rejected as "needs
> splitting", it's basically too big to be send as a single patch. It
> can be applied as several smaller chunks or rejected as a whole. I
> don't think there is any other option.
>
>
>
still, what dmitry told you still holds. wine needs to be able to compile
and pass the tests after each patch is applied. at least the makefile
changes should be merged with the previous patches that needs them (1 and
2). the rest seems like fine splitting, although i don't know the code.
what i'm not sure is, if resampler is still not called after the first
patches, if it is fine to send those first patches... i think you also need
to call resampler for the patch to be accepted, even if it is just as a
stub, incomplete version.

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

[Krzysztof Nikiel]

2011/2/11 Dmitry Timoshkov :
> Krzysztof Nikiel  wrote:
>
>> > You can't send Makefile changes separately from added/removed
>> > files, a patch should not add dead code.
>>
>> Could you explain "dead code", all 13 parts need to be applied,
>> otherwise the code will be broken.
>
> Wine should compile and be able to pass 'make test' after each separate patch.
> You can't add for instance dlls/dsound/resample.c in one patch, and add it to
> Makefile or use interfaces provided by it in some later patches. Every patch
> should be finished and self-containing.

Well, previous version of this patch was rejected as "needs
splitting", it's basically too big to be send as a single patch. It
can be applied as several smaller chunks or rejected as a whole. I
don't think there is any other option.

Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

[Nikolay Sivov]

On 2/11/2011 13:30, Alistair Leslie-Hughes wrote:

Hi,

--
From: "Nikolay Sivov" 
Sent: Friday, February 11, 2011 9:27 PM
To: "Alistair Leslie-Hughes" 
Cc: 
Subject: Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest


On 2/11/2011 12:25, Alistair Leslie-Hughes wrote:

Hi,

On 11/02/2011 8:12 PM, Nikolay Sivov wrote:

On 2/11/2011 10:51, Alistair Leslie-Hughes wrote:

Hi,


Changelog:
msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

What's a purpose of this?

To remove the FIXME from appearing in the logs.
What application is that? Does it appear running in browser scripting 
by any chance?
Yes, it was a website that uses XMLHTTPRequest to load files off the 
local

filesystem.
My point is that browser scripting engine shouldn't query for that 
interface in a first place probably, so it's interesting to figure out 
why it's queried instead of silence it. Is it possible to reproduce that 
with wine-gecko or I need IE?


P.S. cc-ing Jacek, as he knows probably why such dead queries happen.



Best Regards
Alistair Leslie-Hughes

Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

[Alistair Leslie-Hughes]

Hi,

--
From: "Nikolay Sivov" 
Sent: Friday, February 11, 2011 9:27 PM
To: "Alistair Leslie-Hughes" 
Cc: 
Subject: Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest


On 2/11/2011 12:25, Alistair Leslie-Hughes wrote:

Hi,

On 11/02/2011 8:12 PM, Nikolay Sivov wrote:

On 2/11/2011 10:51, Alistair Leslie-Hughes wrote:

Hi,


Changelog:
msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

What's a purpose of this?

To remove the FIXME from appearing in the logs.
What application is that? Does it appear running in browser scripting by 
any chance?

Yes, it was a website that uses XMLHTTPRequest to load files off the local
filesystem.


Best Regards
Alistair Leslie-Hughes

Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

[Nikolay Sivov]

On 2/11/2011 12:25, Alistair Leslie-Hughes wrote:

Hi,

On 11/02/2011 8:12 PM, Nikolay Sivov wrote:

On 2/11/2011 10:51, Alistair Leslie-Hughes wrote:

Hi,


Changelog:
msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

What's a purpose of this?

To remove the FIXME from appearing in the logs.
What application is that? Does it appear running in browser scripting by 
any chance?


Best Regards
Alistair Leslie-Hughes

Re: [PATCH 01/13] dsound: New sample rate converter core functions.

[Dmitry Timoshkov]

Krzysztof Nikiel  wrote:

> High quality sample rate converter.
> New code seems simplier and faster despite the big sound quality
> improvement.
> 
> This patchset only makes sense when applying all 13 parts.

It looks like at least some patches got wrapped by your mailer.
You can't send Makefile changes separately from added/removed
files, a patch should not add dead code.
Could you use 4 space indetation for the new code please?

-- 
Dmitry.

[rfc] dsound: decrease sound latency

[Maarten Lankhorst]

 Hi all,

Please test this and let me know if it's causing any problems in sound 
playback, preferably with media applications and games, any feedback 
would be appreciated. The patch won't fix existing problems, it should 
just decrease the audio lag. As such I would prefer only to receive 
feedback on issues INTRODUCED or FIXED by this patch.


If it's causing issues, I want to know:
1. Whether pulseaudio is running, and pulseaudio --version
2. What distribution you're using
3. (If you know it) the version of alsa's libraries, packages libasound2 
and libasound2-plugins in debian/ubuntu


Cheers,
Maarten


dsound.patch
Description: application/mbox

winspool.drv : Implement AbortPrinter() function

[Loïc Maury]

---
 dlls/winspool.drv/info.c |   95 +-
 1 files changed, 93 insertions(+), 2 deletions(-)

diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c
index e4a464a..f16914a 100644
--- a/dlls/winspool.drv/info.c
+++ b/dlls/winspool.drv/info.c
@@ -5962,8 +5962,99 @@ DWORD WINAPI EnumPrinterDataExA(HANDLE hPrinter, LPCSTR 
pKeyName,
  */
 BOOL WINAPI AbortPrinter( HANDLE hPrinter )
 {
-FIXME("(%p), stub!\n", hPrinter);
-return TRUE;
+PRINTER_INFO_2W *pi2 = NULL;
+BOOL ret = FALSE;
+BOOL retFromGetPrinter = FALSE;
+opened_printer_t *printer;
+job_t *job, *next_job;
+DWORD jobDocId;
+DWORD needed;
+LPWSTR portname;
+
+TRACE("(%p)\n", hPrinter);
+
+EnterCriticalSection(&printer_handles_cs);
+
+printer = get_opened_printer(hPrinter);
+if(!printer)
+{
+ERR("The handle for the printer is invalid.\n");
+SetLastError(ERROR_INVALID_HANDLE);
+goto end;
+}
+
+if(printer->doc)
+{
+TRACE("Document inside for job id : %d\n", printer->doc->job_id);
+jobDocId = printer->doc->job_id;
+}
+else
+{
+ERR("No document.\n");
+SetLastError(ERROR_SPL_NO_STARTDOC);
+goto end;
+}
+
+/* For each jobs, see if we have a job document in the double linked list 
*/
+LIST_FOR_EACH_ENTRY_SAFE(job, next_job, &printer->queue->jobs, job_t, 
entry)
+{
+TRACE("(job id : %d, filename : %s, portname : %s, document title : 
%s, printer name %s)\n"
+, job->job_id, debugstr_w(job->filename), 
debugstr_w(job->portname)
+, debugstr_w(job->document_title), 
debugstr_w(job->printer_name));
+
+if(jobDocId == job->job_id)
+{
+TRACE("(hf : %p, job id : %d)\n", printer->doc->hf, 
printer->doc->job_id);
+
+/* Get portname. */
+if(!job->portname)
+{
+GetPrinterW(hPrinter, 2, NULL, 0, &needed);
+if(GetLastError() != ERROR_INSUFFICIENT_BUFFER)
+goto end;
+
+pi2 = HeapAlloc(GetProcessHeap(), 0, needed);
+if(!pi2)
+goto end;
+
+retFromGetPrinter = GetPrinterW(hPrinter, 2, (LPBYTE)pi2, 
needed, &needed);
+if(!retFromGetPrinter)
+goto end;
+
+portname = pi2->pPortName;
+}
+
+TRACE("portname : %s\n", debugstr_w(portname));
+
+/* Cups Port */
+if(!strncmpW(portname, CUPS_Port, strlenW(CUPS_Port)))
+{
+TRACE("Remove job from the list.\n");
+list_remove(&job->entry);
+CloseHandle(printer->doc->hf);
+DeleteFileW(job->filename);
+HeapFree(GetProcessHeap(), 0, job->document_title);
+HeapFree(GetProcessHeap(), 0, job->printer_name);
+HeapFree(GetProcessHeap(), 0, job->portname);
+HeapFree(GetProcessHeap(), 0, job->filename);
+HeapFree(GetProcessHeap(), 0, job->devmode);
+HeapFree(GetProcessHeap(), 0, job);
+
+/* The document for the printer is not useful anymore. */
+TRACE("Remove document for the printer : %s.\n", 
debugstr_w(printer->printername));
+HeapFree(GetProcessHeap(), 0, printer->doc);
+printer->doc = 0;
+ret = TRUE;
+goto end;
+}
+else
+FIXME("AbortPrinter() manage only CUPS for now.\n");
+}
+}
+end:
+HeapFree(GetProcessHeap(), 0, pi2);
+LeaveCriticalSection(&printer_handles_cs);
+return ret;
 }
 
 /**
-- 
1.7.3.2

Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

[Alistair Leslie-Hughes]

Hi,

On 11/02/2011 8:12 PM, Nikolay Sivov wrote:

On 2/11/2011 10:51, Alistair Leslie-Hughes wrote:

Hi,


Changelog:
msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

What's a purpose of this?

To remove the FIXME from appearing in the logs.

Best Regards
Alistair Leslie-Hughes

Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

[Nikolay Sivov]

On 2/11/2011 10:51, Alistair Leslie-Hughes wrote:

Hi,


Changelog:
msxml3: Ignore IActiveScript interface for IXMLHTTPRequest

What's a purpose of this?



Best Regards
 Alistair Leslie-Hughes