Minor typo correction and term expansion changes.
This commit is contained in:
parent
8a46494ea9
commit
ad72823eb7
|
@ -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>
|
||||||
|
|
Loading…
Reference in New Issue