Skip to content
Snippets Groups Projects
Commit ee069f7c authored by Gregory M. Turner's avatar Gregory M. Turner Committed by Alexandre Julliard
Browse files

Updated the "TODO" comments.

parent 5dbf835b
No related branches found
No related tags found
No related merge requests found
......@@ -19,15 +19,19 @@
*
* WINE RPC TODO's (and a few TODONT's)
*
* - widl is like MIDL for wine. For wine to be a useful RPC platform, quite
* a bit of work needs to be done here. widl currently doesn't generate stubs
* for RPC invocation -- it will need to; this is tricky because the MIDL compiler
* does some really weird stuff. Then again, we don't necessarily have to
* make widl work like MIDL, so it could be worse. Lately Ove has been working on
* some widl enhancements.
* - Ove's decreasingly incomplete widl is an IDL compiler for wine. For widl
* to be wine's only IDL compiler, a fair bit of work remains to be done.
* until then we have used some midl-generated stuff. (What?)
* widl currently doesn't generate stub/proxy files required by wine's (O)RPC
* capabilities -- nor does it make those lovely format strings :(
* The MS MIDL compiler does some really esoteric stuff. Of course Ove has
* started with the less esoteric stuff. There are also lots of nice
* comments in there if you want to flex your bison and help build this monster.
*
* - RPC has a quite featureful error handling mechanism; basically none of this is
* implemented right now.
* implemented right now. We also have deficiencies on the compiler side, where
* wine's __TRY / __EXCEPT / __FINALLY macros are not even used for RpcTryExcept & co,
* due to syntactic differences! (we can fix it with widl by using __TRY)
*
* - There are several different memory allocation schemes for MSRPC.
* I don't even understand what they all are yet, much less have them
......@@ -37,45 +41,30 @@
*
* - MSRPC provides impersonation capabilities which currently are not possible
* to implement in wine. At the very least we should implement the authorization
* API's & gracefully ignore the irrelevant stuff (to a small extent we already do).
* API's & gracefully ignore the irrelevant stuff (to an extent we already do).
*
* - Some transports are not yet implemented. The existing transport implementations
* are incomplete and many seem to be buggy
* are incomplete and may be bug-infested.
*
* - The various transports that we do support ought to be supported in a more
* object-oriented manner, like in DCE's RPC implementation, instead of cluttering
* object-oriented manner, as in DCE's RPC implementation, instead of cluttering
* up the code with conditionals like we do now.
*
* - Data marshalling: So far, only the very beginnings of an implementation
* - Data marshalling: So far, only the beginnings of a full implementation
* exist in wine. NDR protocol itself is documented, but the MS API's to
* convert data-types in memory into NDR are not. This is a bit of a challenge,
* but it is at the top of Greg's queue and should be improving soon.
* convert data-types in memory into NDR are not. This is challenging work,
* and has supposedly been "at the top of Greg's queue" for several months now.
*
* - ORPC is RPC for OLE; once we have a working RPC framework, we can
* use it to implement out-of-process OLE client/server communications.
* ATM there is a 100% disconnect between the marshalling in the OLE DLL's
* and the marshalling going on here. This is a good thing, since marshalling
* doesn't work yet. But once it does, obviously there will be the opportunity
* to implement out-of-process OLE using wine's rpcrt4 or some derivative.
* This may require some collaboration between the RPC workers and the OLE
* workers, of course.
* ATM there is maybe a disconnect between the marshalling in the OLE DLL's
* and the marshalling going on here [TODO: well, is there or not?]
*
* - In-source API Documentation, at least for those functions which we have
* implemented, but preferably for everything we can document, would be nice.
* Some stuff is undocumented by Microsoft and we are guessing how to implement
* (in these cases we should document the behavior we implemented, or, if there
* is no implementation, at least hazard some kind of guess, and put a few
* question marks after it ;) ).
* implemented, but preferably for everything we can document, would be nice,
* since some of this stuff is quite obscure.
*
* - Stubs. Lots of stuff is defined in Microsoft's headers, including undocumented
* stuff. So let's make a stub-farm and populate it with as many rpcrt4 api's as
* we can stand, so people don't get unimplemented function exceptions.
*
* - Name services: this part hasn't even been started.
*
* - Concurrency: right now I have not tested more than one request at a time;
* we are supposed to be able to do this, and to queue requests which exceed the
* concurrency limit.
* - Name services... [TODO: what about them]
*
* - Protocol Towers: Totally unimplemented.... I think.
*
......@@ -85,12 +74,19 @@
*
* - Statistics: we are supposed to be keeping various counters. we aren't.
*
* - Connectionless RPC: unimplemented (DNE in win9x so not a top priority)
* - Async RPC: Unimplemented.
*
* - XML RPC: Dunno if microsoft does it... but we'd might as well just for kicks.
*
* - ...? More stuff I haven't thought of. If you think of more RPC todo's drop me
* an e-mail <gmturner007@ameritech.net> or send a patch to wine-patches.
* - XML/http RPC: Somewhere there's an XML fiend that wants to do this! Betcha
* we could use these as a transport for RPC's across computers without a
* permissions and/or licensing crisis.
*
* - The NT "ports" API, aka LPC. Greg claims this is on his radar. Might (or
* might not) enable users to get some kind of meaningful result out of
* NT-based native rpcrt4's. Commonly-used transport for self-to-self RPC's.
*
* - ...? More stuff I haven't thought of. If you think of more RPC todo's
* drop me an e-mail <gmturner007@ameritech.net> or send a patch to the
* wine-patches mailing list.
*/
#include "config.h"
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment