Re: GNU/Linux COM development and Wine/Samba
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.
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.
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.
Just out of interest, which RPC mechanism would you choose?
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.
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.
Cheers,
Jelmer
Regards,
Philip
Reply to: