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

Re: GNU/Linux COM development and Wine/Samba

Am 09/12/11 04:18, schrieb Philip Ashmore:
I've got several projects in SourceForge, one of which is v3c-dcom


I'm quickly coming to the realisation that I would need several headers/tools from Wine


, 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 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?

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...

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.



Reply to: