rpcrt4 and rpcss with WINE and ReactOS

[Steven Edwards]

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

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

[Casper Hornstrup]

> -----Oprindelig meddelelse-----
> Fra: [e-mail] 
> [mailto:[e-mail]] På vegne af Steven Edwards
> Sendt: 8. december 2003 23:05
> Til: [e-mail]
> 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.

Casper

[Gregory M. Turner]

On Monday 08 December 2003 04:44 pm, Casper Hornstrup wrote:
> > -----Oprindelig meddelelse-----
> > Fra: [e-mail]
> > [mailto:[e-mail]] På vegne af Steven Edwards
> > Sendt: 8. december 2003 23:05
> > Til: [e-mail]
> > 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......",

[Steven Edwards]

Hey Greg,
--- "Gregory M. Turner"  wrote:
> 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 :)

http://cvs.reactos.com/cvsweb.cgi/reactos/ntoskrnl/lpc/
> 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.

Yes there are a few but maybe Casper and I can get these cleaned before
we branch.
> 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

We really dont want to diverge at all. I have tested hacked binarys
under ReactOS and its seemed to work fine but that his been running
only simple apps that depended on rpcrt4 and ole32.

Thanks for your help. It doesnt sound like we will have a problem at
all.

Thanks
Steven

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

[Gregory M. Turner]

On Monday 08 December 2003 06:21 pm, Steven Edwards wrote:
> http://cvs.reactos.com/cvsweb.cgi/reactos/ntoskrnl/lpc/

Neat.  Does it work well enough in ROS to support NT's native rpcrt4?

[Steven Edwards]

-- "Gregory M. Turner"  wrote:
> On Monday 08 December 2003 06:21 pm, Steven Edwards wrote:
> > http://cvs.reactos.com/cvsweb.cgi/reactos/ntoskrnl/lpc/
>
> Neat.  Does it work well enough in ROS to support NT's native rpcrt4?

I havent tried but I doubt it. We need some major regression testing.
It might have worked and then broken 1000 over by now.

Thanks
Steven

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/