[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GNU/Linux COM development and Wine/Samba

Am 10/12/11 00:07, schrieb Philip Ashmore:

On 09/12/11 17:43, Jelmer Vernooij wrote:

Am 09/12/11 04:18, schrieb Philip Ashmore:

I've got several projects in SourceForge, one of which is v3c-dcom

   http://sourceforge.net/projects/v3c-dcom/
I'm quickly coming to the realisation that I would need several headers/tools from Wine 

   http://www.winehq.org/

, the idea being to be able to develop COM components natively.
I'd rather not simply pick them out of Wine, and was hoping to start off something more productive.
debian-devel is probably not the best place for this discussion - you might want to talk to the relevant upstream project (Wine) instead.
I'm thinking of this as a packaging issue. There may be patches to fill in some gaps.
It seems to me that it just requires a lot of upstream work in Wine, possibly utilizing already existing other libraries - that don't require any significant changes. The only packaging changes required (other than updating to a new upstream with the COM support) would be limited to (at most) adding extra dependencies.
I think we should probably take this discussion off-list, or to the wine list, until there is something concrete related to Debian to talk about. 


I guess the topics for discussion are

1. What's the "Debian" way of doing this?
Wine development packages would be split into a shared, Wine, Samba and GNU/Linux-specific binary/dev packages.
There isn't anything Samba-related or GNU/Linux-specific in the Wine headers as far as I know. What would you like to split out? 
The initial list:
widl - to generate header files and type libraries.
oaidl.idl
objidl.idl
unknwn.idl
wtypes.idl
basetsd.h
guiddef.h
Then there's the code to parse type libraries and use them to implement IDispatch::Invoke. v3c-dcom's implementation is really small - too small even for multi-threading or Apartments, but once the kernel 
is there, others are free to build on it.
Those are all unrelated to Samba nor are they specific to GNU/Linux. They're just a part of COM and could happily live in Wine.
2. Does Debian officially approve of the idea of a native COM/DCOM implementation? Wine already does this, but the premise is that it's for Windows programs, which is a bit vague. As this seems to be approved by Microsoft by default, could this situation change with a native port? 
   Would this be rocking the apple cart?
I can see the use of wanting to support DCOM/COM for interoperability reasons, but is anybody actually interested in developing new applications using these technologies? Even Microsoft has been slowly phasing them out. Having worked on a DCOM implementation (in Samba 4) myself in the past, it would be the last RPC mechanism I would choose to use if I was starting a new project... 
I'll admit that DCOM isn't at the top of my list.
v3c-dcom's initial goal is a layer of components you can use for something as small as a boot loader. 
At the moment it's a really general purpose plug-in system.
Once it can do COM threading and marshalling, you could choose which ever RPC mechanism was convenient/available - 
more plug-ins.
COM wouldn't be my first choice for a component interface either, unless I was trying to get existing COM-based code to work... :-) 

Just out of interest, which RPC mechanism would you choose?
It depends on the circumstances, but even plain DCE/RPC is a lot more sensible than DCOM if you need a generic RPC mechanism. The DCOM protocol is complex, proprietary, badly documented, inefficient, and hard to implement. 




4. Samba/Wine integration
   Shared components mean less code to debug.
   Samba and Wine seem to be stuck here.
Maybe having a native implementation that they could both use would be the answer, 
   since Wine and Samba are native implementations already.
Samba is wire-level compatible with Windows, but apart from that it has a completely different architecture. Wine is API-level compatible, which seems more appropriate for implementing an interface technology like COM.
DCOM is a part of COM that allows using it over the network, on top of DCE/RPC. Before DCOM even comes into the picture though, you would have to implement COM in Wine, which is a *huge* undertaking all by itself. When you get to implementing DCOM, you could probably use some of the Samba libraries (in particular, our DCE/RPC client/server libraries). Those libraries are already there though, and usable. I don't see why it is necessary to add new components that have to be shared between Wine and Samba.
If I understand correctly, Wine already implements DirectX, which requires a COM implementation.
Wine indeed already implements some bits of COM, but I'm not sure how much. Either way, it seems like Wine is the best location for a COM implementation.
If all of them (Wine, Samba, + others), could reuse a common set of libraries to talk to each other over named pipes, fifos, tcp/ip or what ever OS mechanism was at hand then porting them to new platforms or architectures would be that 
much easier.
What would you have them talk to each other about, concretely? In this context, the only part of Samba that seems relevant is the DCE/RPC library (packaged as libdcerpc0 in Debian), which Wine could already link against if it wanted to. That said, Wine already has its own DCE/RPC library that is reasonably complete, and provides an API that is similar to the DCE/RPC API on Windows - but wildly different from that in Samba.
If necessary, it should be possible to run DCE/RPC interface servers for Samba, Wine or any third party DCE/RPC implementation on the same machine, by having Wine register its interfaces in Samba's endpoint mapper. This should already work, perhaps with a little bit of extra glue code in either Samba or Wine. 

Cheers,

Jelmer
Reply to: