Minor typo correction and term expansion changes.

documentation/ole.sgml

@@ -395,7 +395,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
         <para>
           The answer is of course that COM doesn't assume that objects actually
           are thread-safe. Most real-world objects aren't, in fact, for various
-          reasons. What these reasons are isn't too important here, though, it's
+          reasons. What these reasons are isn't too important here, though; it's
           just important to realize that the problem of thread-unsafe objects is
           what COM tries hard to solve with its apartment model. There are also
           ways to tell COM that your object is truly thread-safe (namely the
@@ -439,7 +439,9 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
 
         <para>
           Very basic marshalling is easy enough to understand. You take a method
-          on a remote interface, copy each of its parameters into a buffer, and
+          on a remote interface (that is a COM interface that is
+          implemented on the remote computer), copy each of its
+          parameters into a buffer, and
           send it to the remote computer. On the other end, the remote server
           reads each parameter from the buffer, calls the method, writes the
           result into another buffer and sends it back.
@@ -464,7 +466,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
 
         <para>
           RPC packets contain a buffer containing marshalled data in NDR format.
-          NDR is short for "Network Data Representation" and is similar the XDR
+          NDR is short for "Network Data Representation" and is similar
+          to the XDR
           format used in SunRPC (the closest native equivalent on Linux to DCE
           RPC). NDR/XDR are all based on the idea of graph serialization and were
           worked out during the 80s, meaning they are very powerful and can do
@@ -473,12 +476,13 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
         </para>
 
         <para>
-          In Wine, our DCOM implementation is <emphasis>not</emphasis> based on the
+          In Wine, our DCOM implementation is <emphasis>not</emphasis>
+          currently based on the
           RPC runtime, as while few programs use DCOM even fewer use
           RPC directly so it was developed some time after
           OLE32/OLEAUT32 were. Eventually this will have to be fixed,
           otherwise our DCOM will never be compatible with
-          Microsofts. Bear this in mind as you read through the code
+          Microsoft's. Bear this in mind as you read through the code
           however.
         </para>
       </sect2>
@@ -512,8 +516,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
         <para>
           Of course, in the RPC server process at the other end, you need some way
           to unmarshal the RPCs, so you have functions also generated by MIDL
-          which are the inverse of the proxies: they accept an NDR buffer, extract
-          the parameters, call the real function then marshal the result back.
+          which are the inverse of the proxies; they accept an NDR buffer, extract
+          the parameters, call the real function and then marshal the result back.
           They are called stubs, and stand in for the real calling code in the
           client process.
         </para>
@@ -522,7 +526,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
           The sort of marshalling/unmarshalling code that MIDL spits out can be
           seen in dlls/oleaut32/oaidl_p.c - it's not exactly what it would look
           like as that file contains DCOM proxies/stubs which are different, but
-          you get the idea. Proxy functions take the arguments and feel them to
+          you get the idea. Proxy functions take the arguments and feed them to
           the NDR marshallers (or picklers), invoke an NdrProxySendReceive and
           then convert the out parameters and return code. There's a ton of goop
           in there for dealing with buffer allocation, exceptions and so on - it's
@@ -743,10 +747,10 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
 
         <para>
           In fact, the reason for the PSFactoryBuffer layer of indirection is
-          because you not all interfaces are marshalled using MIDL generated code.
+          because not all interfaces are marshalled using MIDL generated code.
           Why not? Well, to understand <emphasis>that</emphasis>
           you have to see that one of the
-          driving forces behind OLE and by extension DCOM was the development
+          driving forces behind OLE and by extension DCOM was the development of
           Visual Basic. Microsoft wanted VB developers to be first class citizens
           in the COM world, but things like writing IDL and compiling them with a
           C compiler into DLLs wasn't easy enough.
@@ -779,7 +783,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
           In the case of InstallShield, it actually comes with typelibs for all
           the interfaces it needs to marshal (fixme: is this right?), but they
           actually use a mix of MIDL and typelib marshalling. In order to cover up
-          for the fact that we don't really use RPC they're all force to go via
+          for the fact that we don't really use RPC they're all forced to go via
           the typelib marshaller - that's what the 1 || hack is for and what the
           "Registering non-automation type library!" warning is about (I think).
         </para>