NdrClientContext(Un)Marshall shuold add size of context handle to pStubMsg->Buffer and raise exceptions in some cases. NDRCContext(Un)marshall shouldn't, that's the difference. You can see this from my testcases (attached). And this was already implemented in my patch. I can't understand why are you trying to reimplement it.
Mike McCormack wrote:
dlls/rpcrt4/ndr_marshall.c | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-)
e834795f1d24b26411d76ba725975216867ae58e diff --git a/dlls/rpcrt4/ndr_marshall.c b/dlls/rpcrt4/ndr_marshall.c index 06ce04a..edd1eb2 100644 --- a/dlls/rpcrt4/ndr_marshall.c +++ b/dlls/rpcrt4/ndr_marshall.c @@ -4296,7 +4296,10 @@ void WINAPI NdrClientContextMarshall(PMI NDR_CCONTEXT ContextHandle, int fCheck) {
- FIXME("(%p, %p, %d): stub\n", pStubMsg, ContextHandle, fCheck);
- TRACE("(%p, %p, %d): stub\n", pStubMsg, ContextHandle, fCheck);
- /* FIXME: what does fCheck do? */
- return NDRCContextMarshall(ContextHandle,
pStubMsg->Buffer);}
/*********************************************************************** @@ -4306,7 +4309,11 @@ void WINAPI NdrClientContextUnmarshall(P NDR_CCONTEXT * pContextHandle, RPC_BINDING_HANDLE BindHandle) {
- FIXME("(%p, %p, %p): stub\n", pStubMsg, pContextHandle, BindHandle);
- TRACE("(%p, %p, %p): stub\n", pStubMsg, pContextHandle, BindHandle);
- return NDRCContextUnmarshall(pContextHandle,
BindHandle,pStubMsg->Buffer,pStubMsg->RpcMsg->DataRepresentation);}
void WINAPI NdrServerContextMarshall(PMIDL_STUB_MESSAGE pStubMsg,
Saveliy Tretiakov wrote:
this from my testcases (attached). And this was already implemented in my patch. I can't understand why are you trying to reimplement it.
Due to the methods and attitudes of some ReactOS developers, we believe that it would be better to avoid including ReactOS code in Wine.
Mike
Mike McCormack wrote:
Due to the methods and attitudes of some ReactOS developers, we believe that it would be better to avoid including ReactOS code in Wine.
My methods are absolutely clean. I used testcode to uncover undocumented functions behaviour. Thats how all wine developers do things.
My methods are absolutely clean. I used testcode to uncover undocumented functions behaviour. Thats how all wine developers do things. Well, you accepted Eric Kohl's widl patches from reactos, why don't you accept my?
Mike McCormack wrote:
Saveliy Tretiakov wrote:
this from my testcases (attached). And this was already implemented in my patch. I can't understand why are you trying to reimplement it.
Due to the methods and attitudes of some ReactOS developers, we believe that it would be better to avoid including ReactOS code in Wine.
Mike
.
Saveliy Tretiakov wrote:
My methods are absolutely clean. I used testcode to uncover undocumented functions behaviour. Thats how all wine developers do things. Well, you accepted Eric Kohl's widl patches from reactos, why don't you accept my?
Please show us your test code.
Mike
Saveliy Tretiakov wrote:
Archive attached to this email.
Your test cases look reasonable, and it would be good if they could be included in the Wine test suite.
As for your patch, I have not looked at it because others have lost confidence in code from ReactOS, and asked me to reimplement what you have already implemented.
If you wish to help Wine out, and you're using test cases to determine Windows behaviour, I'd suggest disassociating yourself from ReactOS and instead contributing patches directly to wine-patches.
Mike
-
Mike McCormack -
Saveliy Tretiakov