Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
wine
Manage
Activity
Members
Labels
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Container Registry
Model registry
Operate
Terraform modules
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Johnny Cai
wine
Commits
ee069f7c
Commit
ee069f7c
authored
21 years ago
by
Gregory M. Turner
Committed by
Alexandre Julliard
21 years ago
Browse files
Options
Downloads
Patches
Plain Diff
Updated the "TODO" comments.
parent
5dbf835b
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
dlls/rpcrt4/rpcrt4_main.c
+34
-38
34 additions, 38 deletions
dlls/rpcrt4/rpcrt4_main.c
with
34 additions
and
38 deletions
dlls/rpcrt4/rpcrt4_main.c
+
34
−
38
View file @
ee069f7c
...
...
@@ -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 a
n
extent we already do).
*
* - Some transports are not yet implemented. The existing transport implementations
* are incomplete and ma
n
y
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 a
n
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:
u
nimplemented
(DNE in win9x so not a top priority)
* -
Async
RPC:
U
nimplemented
.
*
* - 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"
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment