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
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 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.
Cheers,
Jelmer
Reply to: