Age | Commit message (Collapse) | Author | Files | Lines |
|
functions we don't implement yet so that we don't put uninitialised
result data on the wire (found with valgrind)
(This used to be commit 2712e26a5d08afd9bf8c6957f75be522966b5062)
|
|
servers. Previously the server pipe code needed to return the RPC
level status (nearly always "OK") and separately set the function call
return using r->out.result. All the programmers writing servers
(metze, jelmer and me) were often getting this wrong, by doing things
like "return NT_STATUS_NO_MEMORY" which was really quite meaningless
as there is no code like that at the dcerpc level.
I have now modified pidl to generate the necessary boilerplate so that
just returning the status you want from the function will work. So for
a NTSTATUS function you return NT_STATUS_XXX and from a WERROR
function you return WERR_XXX. If you really want to generate a DCERPC
level fault rather than just a return value in your function then you
should use the DCESRV_FAULT() macro which will correctly generate a
fault for you.
As a side effect, this also adds automatic type checking of all of our
server side rpc functions, which was impossible with the old API. When
I changed the API I found and fixed quite a few functions with the
wrong type information, so this is definately useful.
I have also changed the server side template generation to generate a
DCERPC "operation range error" by default when you have not yet filled
in a server side function. This allows us to correctly implement
functions in any order in our rpc pipe servers and give the client the
right information about the fault.
(This used to be commit a4df5c7cf88891a78d82c8d6d7f058d8485e73f0)
|
|
add some more WERR_NOT_SUPPORTED stubs to pass our torture tests
(wkssvc and srvsvc)
metze
(This used to be commit f8605b39ab58f8db22358122eafccc8a1cc60004)
|
|
- we know can browse the server via the Windows Explorer
- some little fixes to the winreg server pipe
metze
(This used to be commit 6f213a3494d3b5ab629944394b20a84075a04438)
|