From: Bill Medland Date: Tue, 11 Jan 2005 10:43:43 +0000 (+0000) Subject: Minor typo correction and term expansion changes. X-Git-Tag: wine-20050111~19 X-Git-Url: http://git.etersoft.ru/projects/?a=commitdiff_plain;h=ad72823eb74c471a8269180aa592bbf2272d4edd;p=wine%2Feterwine.git Minor typo correction and term expansion changes. --- diff --git a/documentation/ole.sgml b/documentation/ole.sgml index 2fe3ec4047..829b5ecab3 100644 --- a/documentation/ole.sgml +++ b/documentation/ole.sgml @@ -395,7 +395,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = { 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 = { 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 = { 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 = { - In Wine, our DCOM implementation is not based on the + In Wine, our DCOM implementation is not + 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. @@ -512,8 +516,8 @@ static ICOM_VTABLE(IDirect3D) d3dvt = { 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. @@ -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 = { 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 that 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).