svn commit: lorikeet r431 - in trunk/white-papers/dcom: .

jelmer at jelmer at
Sat Aug 20 13:07:51 GMT 2005

Author: jelmer
Date: 2005-08-20 13:07:51 +0000 (Sat, 20 Aug 2005)
New Revision: 431


Some minor updates to the DCOM doc 



Property changes on: trunk/white-papers/dcom
Name: svn:ignore
   + *.log

Modified: trunk/white-papers/dcom/call-local.dia
(Binary files differ)

Modified: trunk/white-papers/dcom/call-remote.dia
(Binary files differ)

Modified: trunk/white-papers/dcom/dcom.bib
--- trunk/white-papers/dcom/dcom.bib	2005-08-20 07:19:31 UTC (rev 430)
+++ trunk/white-papers/dcom/dcom.bib	2005-08-20 13:07:51 UTC (rev 431)
@@ -1,6 +1,6 @@
 	title = {Distributed Component Object Model --- DCOM/1.0},
-	URL = {},
+	URL = {},
 	author = {Nat Brown, Charlie Kindel},
 	corpauthor = {Microsoft Corporation},
 	year = 1998,
@@ -107,3 +107,7 @@
 	URL = { }
+ at article{PythonWMI,
+	URL = { }

Modified: trunk/white-papers/dcom/dcom.tex
--- trunk/white-papers/dcom/dcom.tex	2005-08-20 07:19:31 UTC (rev 430)
+++ trunk/white-papers/dcom/dcom.tex	2005-08-20 13:07:51 UTC (rev 431)
@@ -29,14 +29,14 @@
-``Component Object Model'' (COM),  is one of the key 
+The ``Component Object Model'' (COM),  is one of the key 
 features of the Microsoft Windows platform. COM allows 
 developers to use and create interfaces that can have several 
 implementations and can be called by different programs, written in 
 different languages. The involved parties need only agree upon the interface.
 COM is most widely known as the core of other technologies such as OLE, 
-ActiveX and Automation. Even the .NET platform supports COM.
+ActiveX and Automation. Even the more recent .NET platform supports COM.
 DCOM is the distributed version of COM. It is implemented on top of 
 DCE/RPC and was documented in an Internet RFC. This document describes both
@@ -162,7 +162,7 @@
 In the Windows world, COM structures, interfaces and classes are specified in ODL (Object Definition Language). 
 ODL is basically DCE/RPC IDL with a few extensions. Originally, these ODL files were compiled by a tool called 
 $mktyplib$\cite{MkTypLib} but later support for ODL was merged into the $midl$\cite{MIDL} tool which is 
-used on Windows to compile DCE/RPC IDL files. During this process some ODL features were lost or changed\cite{MIDLMkTypLibDiff}.
+used on Windows to compile DCE/RPC IDL files. During this process some ODL features were lost or changed, details are available in \cite{MIDLMkTypLibDiff}.
 The main extensions ODL makes to IDL are:
@@ -173,9 +173,6 @@
 \item writing ``type library files'', i.e. binary files that contain a binary version of the interface definition (extension: $.tlb$
-%FIXME - gah! I am so very disappointed! I get here, expecting to learn what
-%        was lost between mktyplib and midl, but I still don't know. I am 
-%        very sad!
 \section{Distributed COM}
 Distributed COM is nothing more then a 'hack' to make standard COM work 
@@ -322,8 +319,9 @@
 \subsection{COM implementation}
-Since Samba is written in C, which is not object-oriented, object-oriented calls are 'emulated'. This works 
-in pretty much the same fashion the GTK+\footnote{} project's emulation.
+Since Samba is written in C, which is not object-oriented, COM calls in Samba 
+are made using function pointers in structs. This works 
+in pretty much in the same fashion as the GTK+\footnote{} project's GObject model.
 For example, the following Windows code:
 \begin{lstlisting}[caption=Simple COM example in Windows]
@@ -355,7 +353,7 @@
 As described earlier, objects are usually created by obtaining 
 a handle to their class object and then calling $CreateInstance$ on that. 
-In the Windows world, class objects are obtained by CoGetClassObject() 
+In the Windows world, class objects are obtained by $CoGetClassObject()$ 
 which internally loads them from a .DLL, a .EXE or the current process.
 Samba will allow for two methods to provide a class object. First, 
@@ -373,7 +371,7 @@
 \subsubsection{Pidl extensions}
-Samba 4 will support ODL files in it's regular IDL compiler rather then creating a seperate 
+Samba 4 supports ODL files in it's regular IDL compiler rather then creating a seperate 
 compiler for ODL files. This is possible because ODL files are not significantly different 
 from IDL files and the extensions necessary to support ODL fairly simple. These
 extension do not require large amounts of changes in 
@@ -387,8 +385,6 @@
 The additional pidl module, $$, generates C header files that contain 
 structs with function pointers for each object interface. They also generate wrapper macros for
 easier use of the interfaces. 
@@ -445,12 +441,10 @@
 	- Always set iid_is() for Interface names occurring in IDL
 	- Need different treatment in and
-	- For each object interface, define a 
-		ndr_{push,pull}_IUnknown() that just does a push/pop of an MInterfacePointer
 	- unknown interfaces are a different story, but always require a iid_is(), so always encode a MInterfacePointer when an iid_is() is set.
 	- in the proxy, do a conversion from "real interface pointer" <-> MInterfacePointer
 	 - when iid_is() was set
-	 - What when iid_is() not set?
+	 - what when iid_is() not set?
 	   - See if \$NAME is registered as an interface or as a struct. If it's
 	   not registered at all, use something like this:
@@ -481,6 +475,10 @@
 using the OpenPegasus \cite{OpenPegasus} backend might be an option, 
 though this would probably require a lot of integration work.
+An interesting option would be to create Python bindings for DCOM 
+on Linux so it can be used with WMI, with an API similar to that 
+of the Python-WMI\cite{PythonWMI} project.
 DCOM is currently mostly a legacy technology, with Microsoft 

Modified: trunk/white-papers/dcom/relations.dia
(Binary files differ)

More information about the samba-cvs mailing list