> Did you mean to test that block twice?
Good question, and yes. I wanted to test it with at least two
different keys/algorithms, to make sure the restrictions were not
particular to any algorithm.
--Juan
On Mon, Jul 28, 2008 at 9:58 PM, Juan Lang <[EMAIL PROTECTED]> wrote:
> Inspired by a patch by Karsten Elfenbein.
+/* What sizes salt can I set? */
+salt.pbData = pbData;
+for (i=0; i<24; i++)
+{
+salt.cbData = i;
+result = CryptSetKeyParam(h
"John Reiser" <[EMAIL PROTECTED]> wrote:
>> These changes are not compatible with PSDK.
>>
>
> Which "PSDK" is that, and what are the error messages?
I'm using Software Development Kit Update for Windows Vista.
> The numerical values are identical,
> and the new names are the ones used by the
Stefan Dösinger wrote:
>> Ok I have a machine at home that I think has a GeForce card in it
>> or
>> a Radeon (I cant remember) that I will run on. Would it be better to
>> write the test code or find something like 3D mark or the like?
> Look at dlls/d3d9/tests/*.c for how the Wine tests work
H. Verbeet wrote:
> This should prevent setting an incorrect draw buffer when an FBO is active.
>
This patch breaks Psychonauts and possibly other multi-threaded games with
OffscreenRendering=FBO on Nvidia hardware.
Vitaliy.
Aric Stewart wrote:
>
> It is mapped with the keyboard mapping to the resulting character. so
> the key 'A' is DIK_A nomatter what its scancode or vkey would be. This
> is relevent to Japanese keymapping where the '@' key is in the '['
> location the scancode for both is 0x22 but dinput generat
Austin English wrote:
> Splitting the testcase from the fix would be helpful.
Okay, thanks for the suggestion. I have sent such a
patch to wine-patches.
> I've changed things a bit and resubmitted patch. Now there will be less
> ifdefs.
> I'm not sure which "data types" are you talking about, since I'll need
> per-byte surface access in any case, and It doesn't look like it can be
> wrapped into endianness-independant datatype.
Maybe you could use
Stefan Dösinger wrote:
>> Ok I have a machine at home that I think has a GeForce card in it
>> or
>> a Radeon (I cant remember) that I will run on. Would it be better to
>> write the test code or find something like 3D mark or the like?
> Look at dlls/d3d9/tests/*.c for how the Wine tests work
> Ok I have a machine at home that I think has a GeForce card in it
> or
> a Radeon (I cant remember) that I will run on. Would it be better to
> write the test code or find something like 3D mark or the like?
Look at dlls/d3d9/tests/*.c for how the Wine tests work
Stefan Dösinger wrote:
>> Ok I will work on the test case when I get a chance... (I think I can
>> do
>> this in a vmware session if not it is going to have to wait till I get
>> to the house where I have a windows machine).
> Actually, you have to be careful with D3D and vmware. D3D is highly driv
> Ok I will work on the test case when I get a chance... (I think I can
> do
> this in a vmware session if not it is going to have to wait till I get
> to the house where I have a windows machine).
Actually, you have to be careful with D3D and vmware. D3D is highly driver
dependent, up to the point
Stefan Dösinger wrote:
> My performance concern is about the switch statement itself, less about the
> actual value checking. If you have something like
>
> switch(renderstate) {
> case WINED3DRS_A:
> case WINED3DRS_B:
> doSomething();
> break;
>
> default: break;
> }
On Mon, Jul 21, 2008 at 5:59 PM, Lei Zhang <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch does a better job of detecting integer overflow.
>
> The tests added reproduce the behavior in bug 14536, which this patch fixes.
>
Anything wrong with this patch?
On Monday 28 July 2008 19:09:03 you wrote:
> Victor <[EMAIL PROTECTED]> writes:
> > Well, the last attempt (with added big-endian support) was submitted
> > several days ago, and again - no feedback, and patch still isn't
> > accepted.
> >
> > What's wrong with patch now?
>
> The big endian support
Don't apply the patches yet, they break the d3d7 visual tests
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:wine-patches-
> [EMAIL PROTECTED] On Behalf Of Stefan Dösinger
> Sent: Monday, July 28, 2008 11:44 AM
> To: [EMAIL PROTECTED]
> Subject: [1/3] WineD3D: Use C bitfields to c
2008/7/28 David Adam <[EMAIL PROTECTED]>:
> + ortho = D3DXVec3Dot(praydirection, &normal[i]);
> + if ( ortho && D3DXVec3Subtract(&difference, &point, prayposition) )
> + {
> + t = D3DXVec3Dot(&difference, &normal[i]) / ortho;
While correct, due to the fact that the box is axis-alig
>Thank you for your first contribution, but first of all the subject
>isn't correct as the patch is to rpcrt4 instead of ole32.
Oups, sorry. My apologies for this mistake. But I'm currently working on ole32
and I forgot this file belongs to rpcrt4. I will pay attention next time.
>Second of
>all
Dmitry Timoshkov wrote:
>> -INT CDECL MSVCRT_wctomb( char *dst, MSVCRT_wchar_t ch )
>> +INT CDECL MSVCRT_wctomb(char *mbchar, MSVCRT_wchar_t wchar)
>
> What's the point of the above change?
While rewriting that function, I used the parameter names described on MSDN.
I don't see a point in inventin
2008/7/28 Aric Stewart <[EMAIL PROTECTED]>:
> I am unsure if you are thinking i should be concerned about the mirrored or
> flipped destinations as i will admit I have no idea what that entails.
>
I seem to remember that Blt allowed top > bottom and left > right in
the source and destination rectan
Ok, well i can easily address the bound checking issue by moving the
bound checks. i agree before doing the locks sounds correct.
I am unsure if you are thinking i should be concerned about the mirrored
or flipped destinations as i will admit I have no idea what that entails.
I will look more f
2008/7/28 Aric Stewart <[EMAIL PROTECTED]>:
> +if (Src != This)
> +{
> +xdst.top = 0;
> +xdst.bottom = DestRect->bottom - DestRect->top;
> +xdst.left = 0;
> +xdst.right = DestRect->right - DestRect->left;
> +}
This will still b
"John Reiser" <[EMAIL PROTECTED]> wrote:
> diff --git a/include/winnt.h b/include/winnt.h
> index e8a37f5..ad2f674 100644
> --- a/include/winnt.h
> +++ b/include/winnt.h
> @@ -812,9 +812,24 @@ typedef struct _CONTEXT86
>
> typedef CONTEXT86 CONTEXT;
>
> -#define EXCEPTION_READ_FAULT0
> -#def
Victor <[EMAIL PROTECTED]> writes:
> Well, the last attempt (with added big-endian support) was submitted several
> days ago, and again - no feedback, and patch still isn't accepted.
>
> What's wrong with patch now?
The big endian support makes things worse than before. You need to use
the prope
> Well, the last attempt (with added big-endian support) was submitted
several
> days ago, and again - no feedback, and patch still isn't accepted.
> What's wrong with patch now?
Sorry, I must have missed this on Wine-patches again :-(
It look ok to me. The endianess #ifdefs look strange, but I
Colin Finck wrote:
> Dmitry Timoshkov wrote:
>>> -INT CDECL MSVCRT_wctomb( char *dst, MSVCRT_wchar_t ch )
>>> +INT CDECL MSVCRT_wctomb(char *mbchar, MSVCRT_wchar_t wchar)
>> What's the point of the above change?
>
> While rewriting that function, I used the parameter names described on MSDN.
> I d
Colin Finck wrote:
> Vitaliy Margolen wrote:
>> You have to do that in the patch that fixes the test. Each patch have to
>> be
>> autonomous and have all tests pass before and after it.
>
> Well, I just found out that this test passes now by accident.
> And I also marked all my patches as one bun
My performance concern is about the switch statement itself, less about the
actual value checking. If you have something like
switch(renderstate) {
case WINED3DRS_A:
case WINED3DRS_B:
doSomething();
break;
default: break;
}
The binary code
> Afaik bit-fields are at least part of C89. I know for sure gcc and
> msvc support them, and would be surprised if icc didn't.
On the other hand, having the bits not in bitfields makes it easier to build
the hash value in the next patch
"Owen Rudge" <[EMAIL PROTECTED]> writes:
>> 3 files changed, 86 insertions(+), 0 deletions(-)
>
> I'm just wondering if there's a reason this patch wasn't committed with the
> other appwiz patches? The patch applies cleanly to the current git master.
> If there's anything obviously wrong with
> 3 files changed, 86 insertions(+), 0 deletions(-)
I'm just wondering if there's a reason this patch wasn't committed with the
other appwiz patches? The patch applies cleanly to the current git master.
If there's anything obviously wrong with it that I've not spotted, please do
let me know s
Hello, Alexandre,
Is there anything wrong with this couple of patches:
dsound: check error status of waveOutGetVolume() function before using
retrieved values (found by valgrind)
http://www.winehq.org/pipermail/wine-patches/2008-July/058124.html
and
cmd: Do not deceive CompareString() passing
2008/7/28 Chris Ahrendt <[EMAIL PROTECTED]>:
> Problem with this is if any of the above values change for whatever reason
> then it breaks the verification. I agree for the most part that testing
> the range makes sense but I think in this case it is safer to do it this
> way. But if the general
H. Verbeet wrote:
> Unrelated to the patch, but if you intend to work on Wine, I'd
> strongly recommend you setup git first.
Got git yesterday and the repository just wanted to make sure the add
was correct before I comitted and worked with git.
> You shouldn't use d3d8 or d3d9 definitions in w
On Sun, Jul 27, 2008 at 9:52 PM, Dustin Brody <[EMAIL PROTECTED]> wrote:
> I sent the patch at
> http://www.winehq.org/pipermail/wine-patches/2008-July/058460.html but
> got neither it applied nor any other comment. As far as I can tell, I
> complied with all the guidelines at
> http://www.winehq.o
På Mandag 28 juli 2008 , 12:14:44 skrev Alexandre Julliard:
> Alexander Nicolaysen Sørnes <[EMAIL PROTECTED]> writes:
> > +
> > static const IDirectPlay8PeerVtbl DirectPlay8Peer_Vtbl =
> > {
> > IDirectPlay8PeerImpl_QueryInterface,
> > IDirectPlay8PeerImpl_AddRef,
> > IDirectPlay8P
Dmitry Timoshkov wrote:
>> -INT CDECL MSVCRT_wctomb( char *dst, MSVCRT_wchar_t ch )
>> +INT CDECL MSVCRT_wctomb(char *mbchar, MSVCRT_wchar_t wchar)
>
> What's the point of the above change?
While rewriting that function, I used the parameter names described on MSDN.
I don't see a point in inventin
Vitaliy Margolen wrote:
> You have to do that in the patch that fixes the test. Each patch have to
> be
> autonomous and have all tests pass before and after it.
Well, I just found out that this test passes now by accident.
And I also marked all my patches as one bunch consisting of 5 patches lik
Alexander Nicolaysen Sørnes <[EMAIL PROTECTED]> writes:
> +
> static const IDirectPlay8PeerVtbl DirectPlay8Peer_Vtbl =
> {
> IDirectPlay8PeerImpl_QueryInterface,
> IDirectPlay8PeerImpl_AddRef,
> IDirectPlay8PeerImpl_Release,
> IDirectPlay8PeerImpl_Initialize,
> -IDirectPl
"Damjan Jovanovic" <[EMAIL PROTECTED]> writes:
> +#define IMPL(class, member, pointer) ((class*) (((char*) pointer) -
> offsetof(class, member)))
Please don't invent yet another macro for this. Use inline functions
instead.
> +typedef struct
> +{
> +IUnknown unknown;
> +IUniformResource
On Mon, 28 Jul 2008, Gerald Pfeifer wrote:
> Seems like I'm losing the argument on the GCC side, so we'll really
> need to address those six or so warnings in our codebase by adding
> return statements I guess.
Hopefully they won't add a check complaining that this is an unreachale
statement nex
2008/7/28 H. Verbeet <[EMAIL PROTECTED]>:
> 2008/7/27 David Adam <[EMAIL PROTECTED]>:
>> + ortho = D3DXVec3Dot(praydirection, &normal[i]);
>> + if ( ortho )
>> + {
>> + t = D3DXVec3Dot(praydirection, &normal[i]) / ortho;
> This doesn't make much sense, t will always be close to zer
2008/7/27 David Adam <[EMAIL PROTECTED]>:
> + ortho = D3DXVec3Dot(praydirection, &normal[i]);
> + if ( ortho )
> + {
> + t = D3DXVec3Dot(praydirection, &normal[i]) / ortho;
This doesn't make much sense, t will always be close to zero this way.
> +rayposition.x = -3.0f; rayposi
On Mon, 28 Jul 2008, H. Verbeet wrote:
> 2008/7/28 Stefan Dösinger <[EMAIL PROTECTED]>:
> > Mostly because I've written this code before you mentioned them to me. I
> > think it can't hurt to ask Alexandre if bitfields are ok to use in Wine.
> > How's the support among compilers(older gcc versions
2008/7/28 Chris Ahrendt <[EMAIL PROTECTED]>:
> Please comment on the attached patch and let me know what you think..
Almost all of my comments on the original patch still stand. In
addition, you're adding trailing spaces, and you've got an unnecessary
whitespace change in there.
45 matches
Mail list logo
