Hi,
From what I'm hearing, there is some code that is usefull and not part
of the Wine project.
Does it worth adding it to Wine so every one can use it to ease
debugging of apps under Windows?
Bye,
Christian
From Jonathan
This would be great but how do you do with COM objects. What did you
do f
Hi,
On Fri, Jul 09, 2004 at 04:14:31PM -0400, Andrei Barbu wrote:
> Point is.. it works, it's compliant letter for letter with the MSDN
> docs, and it doesn't break anything.
That's EXACTLY the problem - if it's compliant to MSDN letter for letter, then
you can bet your whole household that it is
This would be great but how do you do with COM objects. What did you do
for your direct3d hooking.
I remember someone on the ReactOS team gave me the hook related stuff. (I
cant remember who)
What I do is to modify the target to load the hook dll instead of the
normal dll. The hook dll then load
On Fri, 09 Jul 2004 17:08:05 -0400, Andrei Barbu wrote:
> Even if it does it a different way, this
> is a reliable way of testing to see if we can write to a pointer, so if
> it's valid.
Actually it's not - IsBadWritePtr isn't thread safe, as it only tells you
whether the pointer was valid at the
> This would be great but how do you do with COM objects. What did you do
> for your direct3d hooking.
Well, this is a pet project I had for a long time (and maybe will do the day
I will have a faster PC and QEMU runs any Windows version in a reasonnable
speed :-) ).
Basically, take the Wine Dir
Jonathan Wilson wrote:
This is the best things to do but the problem is not always obvious.
If REing does not give significant result, I would suggest to check
how the function behaves in windows
and implement the same behaviour with maybe a big comment about
ChessMaster 9000.
I suggest that some
Andrei Barbu <[EMAIL PROTECTED]> writes:
> I don't personally know enough about IsBadWritePtr to write a test case.
> Any suggestions? :P
> I'll check out the code later on, but for now it seems to be fine.
>
> What else could it use to validate that pointer?
The proper way is to use an exception
I don't personally know enough about IsBadWritePtr to write a test case.
Any suggestions? :P
I'll check out the code later on, but for now it seems to be fine.
What else could it use to validate that pointer?
Andrei
On Fri, 2004-07-09 at 15:02, Mike McCormack wrote:
> Andrei Barbu wrote:
>
> >
On Fri, 09 Jul 2004 16:14:31 -0400, Andrei Barbu wrote:
> Point is.. it works, it's compliant letter for letter with the MSDN
> docs, and it doesn't break anything.
The easiest way to advance this is to write a simple test case which gets
an instance of that object and then calls it with a bad poi
Don't be sorry,
We're both trying to help the wine project.
Wine itself never calls IDirect3DDevice8Impl_GetCreationParameters. I
greped through the sources for that. So it can't be a straightforward
call from inside wine that would be passing that bad pointer.
And MSDN says:
"
Return Value
Andrei Barbu wrote:
Point is.. it works, it's compliant letter for letter with the MSDN
docs, and it doesn't break anything.
Don't see why it would need more testing.
It needs more testing because at least three other developers believe
that you're not fixing a bug, you're masking another bug.
Yo
Point is.. it works, it's compliant letter for letter with the MSDN
docs, and it doesn't break anything.
Don't see why it would need more testing.
On Fri, 2004-07-09 at 13:41, Mike McCormack wrote:
> Andrei Barbu wrote:
>
> > So I'm guessing this is right now.
> >
> > I don't have a windows com
Andrei Barbu wrote:
So I'm guessing this is right now.
I don't have a windows computer to check this against, but it does
comply with the docs.
I have a feeling you'll need to be a bit more thorough than that to get
your patch applied.
Mike
MSDN says that if it's given an invalid pointer it should return
D3DERR_INVALIDCALL, so that's what it does now.
MSDN:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/graphics/reference/d3d/interfaces/idirect3ddevice9/GetCreationParameters.asp
So I'm guessing t
And this is the correct patch.
Sorry about that, ignore the above.
The above actually allocated the memory, this just returns that the op.
didn't succeed which is the correct thing to do. Chessmaster seems to be
happy too.
On Thu, 2004-07-08 at 15:38, Andrei Barbu wrote:
> Changelog:
>
> Fixes a
On Fri, Jul 09, 2004 at 11:06:54AM +0200, Christian Costa wrote:
> I think he means ChessMaster 9000.
So the patch has no chances at all to be included in Wine by Alexandre
knowing his stance on pointer checks in API functions...
> This is the best things to do but the problem is not always obvio
> Message du 09/07/04 10:46
> De : "Lionel Ulmer"
> A : "Andrei Barbu"
> Copie à : "Christian Costa" , "Marcus Meissner" , "Mike McCormack" , [EMAIL
> PROTECTED]
> Objet : Re: D3D8_GetCreationParameters fix
> On Thu, J
> Message du 09/07/04 00:57
> De : "Andrei Barbu"
> A : "Christian Costa"
> Copie à : "Marcus Meissner" , "Mike McCormack" , [EMAIL PROTECTED]
> Objet : Re: D3D8_GetCreationParameters fix
> Having given thought to the issue, you'
On Thu, Jul 08, 2004 at 08:45:16PM -0400, Andrei Barbu wrote:
> I agree on the docs, interestingly enough though,
> Chessmaster 9000 gives an invalid pointer (0x1)
> and there's a memory access error.
>
> Works on Windows though, so I'm assuming DX might be
> allocating the memory on it's own.
Wh
Having given thought to the issue, you're right.
That was a bad solution, sorry.
It should have failed with D3DERR_INVALIDCALL if it's a bad write
pointer.
Is this new patch ok?
On Thu, 2004-07-08 at 19:45, Christian Costa wrote:
> Andrei Barbu wrote:
>
> >It doesn't have to return that memory,
I agree on the docs, interestingly enough though,
Chessmaster 9000 gives an invalid pointer (0x1)
and there's a memory access error.
Works on Windows though, so I'm assuming DX might be
allocating the memory on it's own.
On Thu, 2004-07-08 at 19:45, Christian Costa wrote:
> Andrei Barbu wrote:
>
On Thu, 08 Jul 2004 18:58:57 -0400, Andrei Barbu wrote:
> It doesn't have to return that memory, DX functions work by taking
> parameters they modify. In essence, that's the point, modifying
> pParameters and returning D3D_OK
Right, what he means is that the parameter is basically a pointer to a
p
Andrei Barbu wrote:
It doesn't have to return that memory, DX functions work by taking
parameters they modify. In essence, that's the point, modifying
pParameters and returning D3D_OK
Marcus is right.
Morover, according to the doc, a pointer to a valid area must be passed
as parameter (the prototy
It doesn't have to return that memory, DX functions work by taking
parameters they modify. In essence, that's the point, modifying
pParameters and returning D3D_OK
Andrei
On Thu, 2004-07-08 at 15:50, Marcus Meissner wrote:
> On Fri, Jul 09, 2004 at 04:39:31AM +0900, Mike McCormack wrote:
> > You
On Fri, Jul 09, 2004 at 04:39:31AM +0900, Mike McCormack wrote:
> You probably want to use a Windows method to allocate memory here, such
> as HeapAlloc() or CoTaskMemAlloc, as the caller is not going to use
> free() to free the memory...
> Mike
>
> Andrei Barbu wrote:
> >Changelog:
> >
> >Fixe
Unfortunately I've never actually had to use those before.
I'll look them up. Which one would be best in this case?
On Thu, 2004-07-08 at 15:39, Mike McCormack wrote:
> You probably want to use a Windows method to allocate memory here, such
> as HeapAlloc() or CoTaskMemAlloc, as the caller is not
You probably want to use a Windows method to allocate memory here, such
as HeapAlloc() or CoTaskMemAlloc, as the caller is not going to use
free() to free the memory...
Mike
Andrei Barbu wrote:
Changelog:
Fixes a memory access fault inside of D3D8_GetCreationParameters.
...
HRESULT WINAPI IDi
27 matches
Mail list logo
