On 28 August 2010 02:44, Misha Koshelev wrote:
> I am looking again at d3d9, but feel like I am running in circles a
> little bit trying to chase down where convFVF and convertedDecls is
> coming from.
>
> If you have any hints/advice, much appreciated. If there is a better
> place to look as well
Dear All:
Thanks a lot Henri for your wonderful D3DXDeclaratorFromFVF patches.
It is wonderful to be exposed to the "right" way to implement this
function.
I am starting to look at D3DXDeclaratorFromFVF, as this would be the
next step before implementing ID3DXMesh.
I am looking again at d3d9, b
On Fri, 2010-08-27 at 08:25 -0500, Rosanne DiMesio wrote:
> Can someone with forum admin rights please ban user Eden1023? I've had to
> delete multiple spam posts by this user every day for the past few days.
>
It would also be a good idea to purge those spams from the archive: the
goal of them b
On Fri, Aug 27, 2010 at 7:36 PM, wrote:
> Octavian Voicu wrote:
>>> so binary compatibility in RC files is required
>>We don't have this right now. Native winmm.dll uses integer resource
>>ids (id 200 for core commands, [...])
>>Wine currently uses string ids
> Could you please elaborate on that?
Hi,
Octavian Voicu wrote:
>> so binary compatibility in RC files is required
>We don't have this right now. Native winmm.dll uses integer resource
>ids (id 200 for core commands, [...])
>Wine currently uses string ids
Could you please elaborate on that? I wasn't aware of an incompatibility.
>> I
On Fri, Aug 27, 2010 at 4:25 PM, Eric Pouech wrote:
> 2010/8/27 Octavian Voicu octavian.vo...@gmail.com
>> I didn't think it was necessary to test on native systems. The command
>> parsing looks like internal winmm stuff, which makes no difference to
>> the exported interfaces, as long as the comm
Done.
On 08/27/2010 08:25 AM, Rosanne DiMesio wrote:
Can someone with forum admin rights please ban user Eden1023? I've had to
delete multiple spam posts by this user every day for the past few days.
On 27 August 2010 15:14, wrote:
> All apps are working perfectly! Could i kindly ask you for sending
> to patches today? It looks like i will have spare time for testing,
> so it will help me to not to mess with revering.
>
It's probably not quite correct. In particular, before 6120d7cc145
it's l
GOUJON Alexandre writes:
> On 08/27/2010 03:22 PM, Alexandre Julliard wrote:
>> I don't think it makes sense to declare minor spelling differences as
>> broken, or to change the kernel resources for this
>
> I did not write these broken. I just removed the todo_wine and fix the nls.
> I think the
On 08/27/2010 03:22 PM, Alexandre Julliard wrote:
I don't think it makes sense to declare minor spelling differences as
broken, or to change the kernel resources for this
I did not write these broken. I just removed the todo_wine and fix the nls.
I think they have been added to match what wine
Octavian,
>I just looked in mmddk.h and they have this:
>#define MCI_INTEGER64 13
It's good you found out about MCI_INTEGER64. Yet it's completely crazy because
googling it yields 6 hits in total, all about Wine bug 22146.
Bing shows nothing at all. How can such a name be that invisible?
>So, d
Can someone with forum admin rights please ban user Eden1023? I've had to
delete multiple spam posts by this user every day for the past few days.
--
Rosanne DiMesio
Alexandre Goujon writes:
> @@ -431,7 +431,7 @@ static void test_setlocale(void)
> ret = setlocale(LC_ALL, "non");
> ok(ret != NULL || broken (ret == NULL), "ret == NULL\n");
> if(ret)
> -todo_wine ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252"))
> +ok((!strcmp( r
On 27.08.2010 18:47, Henri Verbeet wrote:
6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 actually does, does the
attached patch make any difference for you?
Thanks, patch solved the problem.
> Actually, looking a bit at what
> 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 actually
> does, does the attached patch make any difference for you?
Yes! :-D
For crashing tested on: Warcarft 3, 3DMark 2001 SE, Harbinger
For HEAP corruption tested on: Demoscene debris
All apps are working perfect
Octavian Voicu writes:
> The reason for which I opted for a BYTE* is so that I can use sizeof()
> to increment the pointer correctly. DWORD_PTR has a different size of
> 32- and 64-bit systems, so using DWORD* would make it more complicated
> to increment with sizeof(DWORD_PTR). Another reason is
On 27 August 2010 11:05, paulo lesgaz wrote:
> I modified my patch to follow Henri's and Stefan's requests and hints. Do
> you have more observations to do with this one?
>
Not exactly a new one, but you still have whitespace errors.
On 27 August 2010 14:33, Henri Verbeet wrote:
> clearly outside that range. At first sight I'd say there's an error in
> the calculation for "mixdev[mixnum].chans" somewhere, that's what
> ultimately determines the size of the block that's allocated above,
> and should correspond to the number of
On 27 August 2010 14:04, wrote:
>
> Also from log previously attached, following string is written to
> address out of this word, isn't? Look like some return address than
> HEAP, right?
>
> 0009:Call KERNEL32.MultiByteToWideChar(fdf2,,0021cac8
> "HDA NVidia",,7dfc9ee4,002
Also from log previously attached, following string is written to
address out of this word, isn't? Look like some return address than
HEAP, right?
0009:Call KERNEL32.MultiByteToWideChar(fdf2,,0021cac8
"HDA NVidia",,7dfc9ee4,0020) ret=7dfb2ae4
0009:Ret KERNEL32.MultiByteTo
>
> There have been a few bug reports...
> http://bugs.winehq.org/show_bug.cgi?id=23902 and
> http://bugs.winehq.org/show_bug.cgi?id=24131 .
>
> It seems that in some relatively rare sound
> setups, an inappropriate sound element gets fed in to
> filllines_no_master which leads to a crash on aud
Same here.
-- Forwarded message --
From: Octavian Voicu
Date: Thu, Aug 26, 2010 at 3:12 PM
Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
To: joerg-cyril.hoe...@t-systems.com
On Thu, Aug 26, 2010 at 2:15 PM, Octavian Voicu
wrote:
> I just looked in
For some reason I forgot to hit reply to all.
-- Forwarded message --
From: Octavian Voicu
Date: Thu, Aug 26, 2010 at 2:15 PM
Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.
To: joerg-cyril.hoe...@t-systems.com
On Thu, Aug 26, 2010 at 1:11 PM, wrot
On 08/27/2010 09:53 AM, GOUJON Alexandre wrote:
Hi,
No one have replied for my ["Spanish - Modern Sort_Spain.1252" locale
on wine] mail.
So I'm asking again if someone has an idea.
If solved, msvcrt:locale test on wine will pass without any error.
The situation is the following :
setlocale(LC
Hello,
I modified my patch to follow Henri's and Stefan's requests and hints. Do you
have more observations to do with this one?
As previously, all the tests go on passing.
A+
David
From afee76a160437728ea7f8a83d927dbf8f877fd90 Mon Sep 17 00:00:00 2001
From: David Adam
Date: Thu, 26
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=4818
Your paranoid android.
Dan Kegel wrote:
> This gets Pando-based installers further, see
> http://bugs.winehq.org/show_bug.cgi?id=24019
>
> There's obviously more to do here, but this little bit is useful.
Please simultaneously add it to all other language files.
--
Dmitry.
If this patch isn't accepted then the winemenubuilder ones shouldn't be
either. PNG is typically used to compress the largest icon in the ICO file,
and the largest icon is the one winemenubuilder will extracts to be used
during the +/- 1 minute delay in Gnome before a menu item starts having the
be
Hi,
No one have replied for my ["Spanish - Modern Sort_Spain.1252" locale on
wine] mail.
So I'm asking again if someone has an idea.
If solved, msvcrt:locale test on wine will pass without any error.
The situation is the following :
setlocale(LC_ALL, "esn");
> ok(!strcmp(ret, "Spanish_Spain.12
--- On Thu, 26/8/10, Vincent Povirk wrote:
> > Also, half of the
> > cross-compiling dependencies are available (and more
> up to date) on fedora
> > under the ming32-* packages.
>
> I don't use fedora, but you're welcome to add that
> information for the
> benefit of fedora users. (Or even a re
30 matches
Mail list logo
