On 08/31/2010 04:58 AM, GOUJON Alexandre wrote:
Is the attached patch well formed ?
+if( $codepage == 1361 ) my $lb_ranges = ( 0x81, 0xd3, 0xd8, 0xde, 0xe0,
0xf9, 0x00, 0x00 );
+else my $lb_ranges = get_lb_ranges();
+
No, it's wrong. Perl requires curly braces for if(){}else{}.
Vitali
On 08/30/2010 03:06 PM, Dan Kegel wrote:
Bug 6971, the mouse problem affecting many FPS-style games (Alexandre
thinks it would take a month of his time?)
That all depends how far AJ wants to go with restructuring of input layer in
X11.drv / server.
If all you talking about is making dinput w
On 31.08.2010 16:16, Henri Verbeet wrote:
On 30 August 2010 18:37, Mikko Rasa wrote:
+ctx->trailer_bytes =
pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session));
...
-stream_sizes->cbHeader = 5;
-stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes
"my 3G Internet
> connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one
> cares)
>
"
HAHA!!!
Don't you have a starbucks near by??? They do free wifi now!
On Tue, Aug 31, 2010 at 3:58 AM, GOUJON Alexandre wrote:
> Is the attached patch well formed ?
> Can someone give it a
On 31 August 2010 18:48, misha680 wrote:
> D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per
> include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000
> it is last, I assume it would also come last?
>
The LASTBETA FVF flags don't add elements themselves, they modify the
On Tue, 31 Aug 2010, test...@testbot.winehq.org wrote:
[...]
> http://testbot.winehq.org/JobDetails.pl?Key=4872
[...]
> === W98SE (32 bit process) ===
> Failure running script in VM: Exceeded timeout limit of 315 sec
This is strange. Testbot says the process timed out yet the full log has
the exp
Henri Verbeet wrote:
>
> On 31 August 2010 18:16, Misha Koshelev wrote:
>>> Well yes, but I'd say that ordering should apply to *any* FVF element,
>>> not just colors and normals. E.g., point size before position or
>>> texture before color should be just as untranslatable.
>> Thank you. I was
On 31 August 2010 18:16, Misha Koshelev wrote:
>> Well yes, but I'd say that ordering should apply to *any* FVF element,
>> not just colors and normals. E.g., point size before position or
>> texture before color should be just as untranslatable.
> Thank you. I was not aware of these constraints.
On Tue, Aug 31, 2010 at 7:58 AM, Henri Verbeet wrote:
> On 31 August 2010 14:47, misha680 wrote:
>> As you can see by the tests added, colors and normals have an ordering that
>> is specifically constrained within the FVF.
>>
> Well yes, but I'd say that ordering should apply to *any* FVF element
Hi Henri,
Probably depends on the device supporting NPOT textures again.
The capabilities are checked in the D3DXCheckTextureRequirements
function, and the values adjusted if necessary.
(Yeah, this is a mostly unchanged copy of my earlier comments.)
My apologies, I somehow missed the pre
Mike Kaplinskiy writes:
> /***
> + * WS2_async_recv_accept(INTERNAL)
> + *
> + * This function is used to finish the read part of an accept request. It is
> + * needed to place the completion on the corr
On 30 August 2010 18:37, Mikko Rasa wrote:
> +ctx->trailer_bytes =
> pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session));
...
> - stream_sizes->cbHeader = 5;
> - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes
> padding + 1 for padding size */
> +
On Mon, 2010-08-30 at 23:57 +0300, Mikko Rasa wrote:
> +SIZE_T expected_size;
> ssize_t received = 0;
> ssize_t ret;
> int idx;
> -char *buf_ptr;
> +unsigned char *buf_ptr;
> unsigned int offset;
>
> TRACE("context_handle %p, message %p, message_seq_no %d, qu
On 31 August 2010 14:47, misha680 wrote:
> As you can see by the tests added, colors and normals have an ordering that
> is specifically constrained within the FVF.
>
Well yes, but I'd say that ordering should apply to *any* FVF element,
not just colors and normals. E.g., point size before positio
On Mon, 2010-08-30 at 19:37 +0300, Mikko Rasa wrote:
> -memcpy(buffer->pvBuffer, data, received);
> -buffer->cbBuffer = received;
> +buf_ptr = (char *)buffer->pvBuffer;
You don't need this cast.
> +offset = ctx->header_bytes;
> +memcpy(buf_ptr + offset, data, received);
>
Henri Verbeet wrote:
>
> On 30 August 2010 23:07, Misha Koshelev wrote:
>> Looking forward to (constructive) comments.
>>
> Why are colors and normals special? What use is hasPosition? What
> happens when the source declaration has e.g. two color elements with
> usage index 0, or two position e
On 8/31/10 2:03 PM, Alexandre Julliard wrote:
Jacek Caban writes:
They are defined by default by midl.
__midl is supposed to be set to the midl compiler version, and I'm not
entirely convinced it's appropriate for us to define it.
My motivation was to make headers prepared for midl to work.
On 26 July 2010 23:05, Owen Rudge wrote:
> +if ((filter & 0x) > D3DX_FILTER_BOX && filter != D3DX_DEFAULT)
> +return D3DERR_INVALIDCALL;
> +
> +if ((mipfilter & 0x) > D3DX_FILTER_BOX && mipfilter != D3DX_DEFAULT)
> +return D3DERR_INVALIDCALL;
> +
> +if (!filter
Jacek Caban writes:
> They are defined by default by midl.
__midl is supposed to be set to the midl compiler version, and I'm not
entirely convinced it's appropriate for us to define it.
Also, _WIN64 can't depend on how widl was built, since it can generate
both 32-bit and 64-bit code. You'd ha
Does not work for me :crying: I voluntary added trailing space to my file.
Nothing appears in red. I obtain in white and black
testcooperativelevels_normal();ESC[m
ESC[32m+ESC[mESC[32mtestcooperativelevels_normal_other_ddraw();ESC[m
ESC[32m+ESC[mESC[41mESC[m
ESC[32m+ESC[mESC[41mESC
2010/8/31 Francois Gouget
> On Tue, 31 Aug 2010, Alexandre Julliard wrote:
>
> > Francois Gouget writes:
> >
> > > http://source.winehq.org/patches/data/65442
> > >
> > > According to http://source.winehq.org/patches/ this patch causes a
> build
> > > error (or maybe a new warning). However here
Is the attached patch well formed ?
Can someone give it a try ?
I don't want to run it, I fear it'll download all tables : my 3G
Internet connection is limited to 20 kB/s now (I downloaded more than 5
GB but no one cares)
diff --git a/libs/wine/cpmap.pl b/libs/wine/cpmap.pl
index 79f5fd5..d112f0
On Tue, Aug 31, 2010 at 02:40, Dan Kegel wrote:
> Are there any Chinese speakers on the list?
> Any interest in starting a Chinese translation of wiki.winehq.org?
>
> I bring this up because a Chinese user/developer is asking for help
> getting started with submitting translations to Wine. I thin
On 08/31/2010 12:23 PM, Dmitry Timoshkov wrote:
Wine's aim is to run Windows applications, not to implement everything
Windows has.
I disagree about that but it doesn't matter after all.
Spending time fixing
differencies nobody cares about is a time loss
You're probably right but what about if
On Tue, 31 Aug 2010, Alexandre Julliard wrote:
> Francois Gouget writes:
>
> > http://source.winehq.org/patches/data/65442
> >
> > According to http://source.winehq.org/patches/ this patch causes a build
> > error (or maybe a new warning). However here (gcc 4.4) I see no warning
> > at all.
[.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=4872
Your paranoid android.
On 30 August 2010 23:07, Misha Koshelev wrote:
> Looking forward to (constructive) comments.
>
Why are colors and normals special? What use is hasPosition? What
happens when the source declaration has e.g. two color elements with
usage index 0, or two position elements? Note that the booleans are
GOUJON Alexandre wrote:
> You've done great things on wine for a long time and fixed plenty of
> bugs (again, thanks) but ... how can you say that (the last sentence) ?
> I don't want to offense you, I'm no one, and I don't say that just to be
> mean .. but there won't be any problem until an a
On 31 August 2010 00:46, Roderick Colenbrander wrote:
> In the previous version of this patch, no version info was returned
> for Windows versions which were not in the table. I verified on
> Vista/Win7 what version numbers, gpu names and driver strings are
> returned to applications running in 9x
Francois Gouget writes:
> http://source.winehq.org/patches/data/65442
>
> According to http://source.winehq.org/patches/ this patch causes a build
> error (or maybe a new warning). However here (gcc 4.4) I see no warning
> at all.
>
> Does this patch cause warnings / errors for anyone?
> (it wo
On 08/31/2010 11:20 AM, Dmitry Timoshkov wrote:
Windows uses an older Unicode specification, that's pretty normal that
unicode.org and Windows data differ in some places. There is no need
to change the mapping unless there is an application that depends on it
Thanks for your answer.
You've done
http://source.winehq.org/patches/data/65442
According to http://source.winehq.org/patches/ this patch causes a build
error (or maybe a new warning). However here (gcc 4.4) I see no warning
at all.
Does this patch cause warnings / errors for anyone?
(it would be nice if the patches website coul
I think you want these to show up in your editor while writing the
code, not after the fact. "set list listchars=tab:»·,trail:·" for vim,
but I'm sure any other half-decent editor will have equivalent
functionality.
GOUJON Alexandre wrote:
> > --- a/libs/wine/c_1361.c
> > +++ b/libs/wine/c_1361.c
> > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 =
> > uni2cp_low,
> > uni2cp_high,
> > {
> > -0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00
> > +0x81, 0xd3, 0xd8, 0
On 08/28/2010 02:12 PM, Alexandre Goujon wrote:
I know that libs/wine/c_1361.c is generated ("DO NOT EDIT!!").
However (union cptable)cptable_1361.dbcs->lead_bytes needs to be modified
according tests
[...]
diff --git a/libs/wine/c_1361.c b/libs/wine/c_1361.c
index b424cb1..50d2c47 100644
---
35 matches
Mail list logo
