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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ee2c7ff.5010...@samba.org
