Re: GNU/Linux COM development and Wine/Samba
Am 09/12/11 04:18, schrieb Philip Ashmore:
debian-devel is probably not the best place for this discussion - you
might want to talk to the relevant upstream project (Wine) instead.
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.
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?
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.
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...
2. Does Debian officially approve of the idea of a native COM/DCOM
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?
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.
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.
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