Minor typo correction and term expansion changes.

This commit is contained in:
Bill Medland 2005-01-11 10:43:43 +00:00 committed by Alexandre Julliard
parent 8a46494ea9
commit ad72823eb7
1 changed files with 15 additions and 11 deletions

View File

@ -395,7 +395,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para> <para>
The answer is of course that COM doesn't assume that objects actually 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 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 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 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 ways to tell COM that your object is truly thread-safe (namely the
@ -439,7 +439,9 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para> <para>
Very basic marshalling is easy enough to understand. You take a method 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 send it to the remote computer. On the other end, the remote server
reads each parameter from the buffer, calls the method, writes the reads each parameter from the buffer, calls the method, writes the
result into another buffer and sends it back. result into another buffer and sends it back.
@ -464,7 +466,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para> <para>
RPC packets contain a buffer containing marshalled data in NDR format. 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 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 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 worked out during the 80s, meaning they are very powerful and can do
@ -473,12 +476,13 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
</para> </para>
<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 runtime, as while few programs use DCOM even fewer use
RPC directly so it was developed some time after RPC directly so it was developed some time after
OLE32/OLEAUT32 were. Eventually this will have to be fixed, OLE32/OLEAUT32 were. Eventually this will have to be fixed,
otherwise our DCOM will never be compatible with 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. however.
</para> </para>
</sect2> </sect2>
@ -512,8 +516,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para> <para>
Of course, in the RPC server process at the other end, you need some way 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 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 which are the inverse of the proxies; they accept an NDR buffer, extract
the parameters, call the real function then marshal the result back. 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 They are called stubs, and stand in for the real calling code in the
client process. client process.
</para> </para>
@ -522,7 +526,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
The sort of marshalling/unmarshalling code that MIDL spits out can be 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 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 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 the NDR marshallers (or picklers), invoke an NdrProxySendReceive and
then convert the out parameters and return code. There's a ton of goop 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 in there for dealing with buffer allocation, exceptions and so on - it's
@ -743,10 +747,10 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
<para> <para>
In fact, the reason for the PSFactoryBuffer layer of indirection is 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> Why not? Well, to understand <emphasis>that</emphasis>
you have to see that one of the 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 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 in the COM world, but things like writing IDL and compiling them with a
C compiler into DLLs wasn't easy enough. 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 In the case of InstallShield, it actually comes with typelibs for all
the interfaces it needs to marshal (fixme: is this right?), but they 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 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 the typelib marshaller - that's what the 1 || hack is for and what the
"Registering non-automation type library!" warning is about (I think). "Registering non-automation type library!" warning is about (I think).
</para> </para>