On 10/12/11 02:46, Jelmer Vernooij wrote:
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'm literally talking about Debian creating a "wine-vine"package that
contains
1. widl
2. some pared down idl's, leaving out anything to do with window
handles/GUIs
3. adding some stuff from v3c-dcom to create sandboxes and instances,
like it's mini-ATL (c++).
Then there's a "wine-script" package that would use vine-vine but
provide, in addition
3. type library bits and bobs
It would be for developers who wanted a plug-in system with scripting
capability, say to write
their own scripting language.
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.
But I'm talking about Debian packages, wine-vine with vastly pared down
bits Wine, and wine-talk
for a layer above that.
These allow for COM development in GNU/Linux forGNU/Linux, but in code
reuse terms Wine and Samba
plus others would benefit from additional transport mechanisms as well
as what a common code base
gets you
- additional testing
- extra capabilities
- simplifying porting
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... :-)
So what would be your first choice, then?
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.
But you can't develop "native" COM components/plug-ins like you can now
with v3c-dcom.
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.
Not just DCE/RPC, but any way available to the OS.
Cheers,
Jelmer
I'm not convinced these packages would be relevant to Wine or Samba
right now.
Sure, once they're available and settled, Wine, Samba and others could
maybe look into (re)using them.
Regards,
Philip
--
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/4ee2d501.1040...@philipashmore.com
