rpc_L_00
Gregory M. Turner
gmturner007 at ameritech.net
Wed Sep 10 18:07:25 CDT 2003
License: bugroff
Changelog:
- dlls/rpcrt4: rpcrt4_main.c
Greg Turner <gmturner007 at ameritech.net>
* Updated the "TODO" comments for rpcrt4.
--
Index: dlls/rpcrt4/rpcrt4_main.c
===================================================================
RCS file: /home/wine/wine/dlls/rpcrt4/rpcrt4_main.c,v
retrieving revision 1.45
diff -u -r1.45 rpcrt4_main.c
--- dlls/rpcrt4/rpcrt4_main.c 5 Sep 2003 23:08:32 -0000 1.45
+++ dlls/rpcrt4/rpcrt4_main.c 10 Sep 2003 22:57:15 -0000
@@ -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 ;) ).
- *
- * - 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.
+ * implemented, but preferably for everything we can document, would be nice,
+ * since some of this stuff is quite obscure.
+ *
+ * - 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 at 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 at ameritech.net> or send a patch to the
+ * wine-patches mailing list.
*/
#include "config.h"
--
-gmt
More information about the wine-patches
mailing list