ReceiveTempSMS
/
Sweden-Number
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
documentation/ole.sgml
View File

@ -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>