Wine and industrial communication like OPC

[Juan Lang]

--- Mike Hearn <m.hearn at signal.QinetiQ.com> wrote:
> It'd be a tragedy to reimplement all that of that
> code because of GPL vs 
> LGPL concerns.

I agree.  Andrew Bartlett did too in an email he sent
me.  The reason I've backed off from this is that it's
hard to do correctly, and anything less than
completely correct isn't going to be accepted by A.J. 
Ideal for us would be a file descriptor that we can do
atomic operations on; that'd be duplicable like the
rest of our handles.  Not sure how we'd get that from
smbd (see below for a different idea), and Samba3's
public API is too high-level to be of much use to
Wine.  (Samba4 might be better.)

> Given the ports problem, maybe the solution is just
> to have smbd expose 
> an interface that lets you manage named pipe
> connections through it. Not 
> thought about this problem much though.

The ports issue prevents us from receiving
connections, i.e. acting as a DCOM server.  This is
probably less important than being able to act as a
client, at least for a while.

I asked Steve French (Linux CIFS module) whether he'd
consider exposing named pipes in the Linux filesystem.
 He said he would, then asked me whether I'd given any
thought to naming convention.  I hadn't and I haven't
had as much time to experiment with this of late, so I
haven't responded.  This method would allow us to act
as a CIFS (TCP port 445) client.  Acting as an SMB
(TCP port 139) client isn't handled by the CIFS
module, it's done by the SMBFS module.  Not sure what
Steve's plans are here.

Anyway, any of you guys interested in seeing RPC work
under Wine (Greg, you still lurking around here?)
might want to play around with this if you have time. 
I might myself once I land somewhere for a while, but
no promises.

--Juan


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail