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
---
GOUJON Alexandre ale.gou...@gmail.com 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,
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.
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
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
Francois Gouget fgou...@free.fr 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?
On 31 August 2010 00:46, Roderick Colenbrander thunderbir...@gmail.com 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
GOUJON Alexandre ale.gou...@gmail.com 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
On 30 August 2010 23:07, Misha Koshelev misha...@gmail.com 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
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
On Tue, 31 Aug 2010, Alexandre Julliard wrote:
Francois Gouget fgou...@free.fr 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
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
On Tue, Aug 31, 2010 at 02:40, Dan Kegel d...@kegel.com 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
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
2010/8/31 Francois Gouget fgou...@free.fr
On Tue, 31 Aug 2010, Alexandre Julliard wrote:
Francois Gouget fgou...@free.fr 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).
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[41m
Jacek Caban ja...@codeweavers.com 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
On 26 July 2010 23:05, Owen Rudge o...@owenrudge.net 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
On 8/31/10 2:03 PM, Alexandre Julliard wrote:
Jacek Cabanja...@codeweavers.com 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
Henri Verbeet wrote:
On 30 August 2010 23:07, Misha Koshelev misha...@gmail.com 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
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);
On 31 August 2010 14:47, misha680 misha...@gmail.com 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
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, quality
On 30 August 2010 18:37, Mikko Rasa t...@tdb.fi 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 */
Mike Kaplinskiy mike.kaplins...@gmail.com 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
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
On Tue, Aug 31, 2010 at 7:58 AM, Henri Verbeet hverb...@gmail.com wrote:
On 31 August 2010 14:47, misha680 misha...@gmail.com 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
On 31 August 2010 18:16, Misha Koshelev misha...@gmail.com 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
Henri Verbeet wrote:
On 31 August 2010 18:16, Misha Koshelev misha...@gmail.com 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.
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
On 31 August 2010 18:48, misha680 misha...@gmail.com 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,
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 ale.gou...@gmail.com wrote:
Is the attached patch well formed ?
Can
On 31.08.2010 16:16, Henri Verbeet wrote:
On 30 August 2010 18:37, Mikko Rasat...@tdb.fi 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
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
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{}.
35 matches
Mail list logo
