rpcrt4 and rpcss with WINE and ReactOS

Gregory M. Turner gmturner007 at ameritech.net
Mon Dec 8 17:52:23 CST 2003


On Monday 08 December 2003 04:44 pm, Casper Hornstrup wrote:
> > -----Oprindelig meddelelse-----
> > Fra: wine-devel-admin at winehq.org
> > [mailto:wine-devel-admin at winehq.org] På vegne af Steven Edwards
> > Sendt: 8. december 2003 23:05
> > Til: wine-devel at winehq.com
> > Emne: rpcrt4 and rpcss with WINE and ReactOS
> >
> >
> > Hello,
> > Ok I know this going to start YALD (Yet Another Long
> > Discussion) that wont go anywhere right away but......
> >
> > ReactOS is getting ready to do a major import of the WINE
> > dlls as you guys know due to my repeated cross-postings to
> > Wine-devel and ros-kernel. When we compile rpcrt and ole32
> > from WINE with some hacks we can make it work under ReactOS
> > but I would like to develop a implementation that works
> > properly without dirty hacking. I dont know much about WINEs
> > rpcss other than whats in the comments of the code and for
> > that matter I dont know much about Windows rpcss. Can we
> > share these componates? How are we going to break
> > compatiblity by doing this?
> >
> > Thanks
> > Steven
>
> ReactOS can use the relatively fast LPC facility for
> cross-process communication in rpcrt4. I'm not sure if WINE implements
> this, but if both WINE and ReactOS implements it in the same
> way, then I see no reason not to share implementations of this
> component.

Wine doesn't have LPC per se.  If ReactOS does, I'd love to see their 
implementation and talk to you all about stealing it :)

Rpcss (in wine) is really a nasty kludge at this time.  It only performs a 
single function: mapping of endpoints.  Eventually, this is where the Running 
Object Table, the OXID Resolver, and maybe some other things should go.  
Furthermore, the endpoint mapping is done in completely the wrong way: it 
uses an arbitrary protocol over named pipes.  It is supposed to be using RPC 
according to a standard interface (maybe there are two standards, though, the 
MS ORPC one and the ONC RPC one, which are supposed to coexist).  That's not 
particularly important, however, until the wire protocol is fixed.

At the RPC API level, wine appears to support lpc -- but in fact it's using 
named pipes.  The actual LPC API's (NT "Ports") are just do-nothing stubs.  
Implementing them might be easy; implementing them /well/ would probably 
require shared memory and be kinda scary.  I have designs to do this myself 
(starting with the poor, easy implementation), but lately I'm not finding the 
time I want to dedicate to wine development.

Uhh... so in answer to your question, rpcrt4 and rpcss are designed to work 
together, and shouldn't have too many ugly dependencies (except that rpcrt4 
has some ole32 deps for its ndr implementation).  For the most part, they 
only use high-level Windows-y stuff found in kernel32; there may be a few 
unixisms/wineisms, of course, but compared to other dlls these should be 
trivial.

My advice: just run the code and see what happens.  So long as ROS has working 
named-pipes, and a few other kernel essentials like critical sections, string 
atoms, etc, it ought to "just work", deficiencies and all.  Just test with 
"/Oi" midl-generated code, and stick to the supported transports (lpc, 
ironically, or named pipes), or you will get no love.  AFAIK, the only snag 
you may encounter is if your ole diverges from that of wine.. if that 
happens, just break the ndr types which require ole32 until you get your 
ole32 up to speed.  Furthermore, you only need rpcss for dynamic endpoints!!!  
Fixed endpoints will work fine without rpcss.  In real-world situations, due 
to the deficiencies of wine's RPC, there is almost never any reason to invoke 
rpcss, and it rarely runs.

Sorry to fulfill the prophecy about "YALD (Yet Another Long
Discussion) that wont go anywhere right away but......",

-- 
gmt

"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves.  The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39





More information about the wine-devel mailing list