--- a/Symbian3/SDK/Source/GUID-E651C7A7-D6EB-533E-A97A-360D089DE7A5.dita Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-E651C7A7-D6EB-533E-A97A-360D089DE7A5.dita Fri Jun 11 12:39:03 2010 +0100
@@ -1,56 +1,56 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License
-"Eclipse Public License v1.0" which accompanies this distribution,
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
- Nokia Corporation - initial contribution.
-Contributors:
--->
-<!DOCTYPE concept
- PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-E651C7A7-D6EB-533E-A97A-360D089DE7A5" xml:lang="en"><title>Inter-thread
-data transfer</title><shortdesc>Describes how data is transferred between threads.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>The client-server message protocol supports the passing of a 32-bit request
-code and four 32-bit parameters from client to server and returning a 32-bit
-result from the server to the client. The parameters may be interpreted as
-plain integers or pointers; pointer types may be untyped (<codeph>TAny*</codeph>)
-or descriptor types (<codeph>TDesC8*</codeph> and <codeph>TDesC16*</codeph>)
-that the server can use to access the client’s address space. The request
-code, parameters, and the parameter types are packaged into a <xref href="GUID-4AD02F14-1142-372F-9D11-224595932034.dita"><apiname>TIpcArgs</apiname></xref> object.
-The parameter types are stored in the kernel side message object so that the
-kernel can check that subsequent operations requested by the server using
-the message are: </p>
-<ul>
-<li id="GUID-1F925301-81D0-5F84-ABEE-BB4DB576DBC1"><p>correct; for example,
-checking that the source and target descriptors are either both 8-bit or both
-16-bit descriptors </p> </li>
-<li id="GUID-EE7CCC5F-0013-55EA-B473-763785F5CD90"><p>permitted by the client;
-for example, checking that when the server tries to write to a client descriptor,
-that the client descriptor is <xref href="GUID-49D4E917-57EA-39AE-8941-144AA8AC2584.dita"><apiname>TDes</apiname></xref> -derived (modifiable),
-rather than <xref href="GUID-52D07F46-2162-380C-A775-C3BB335C42F5.dita"><apiname>TDesC</apiname></xref> -derived (non-modifiable) </p> </li>
-</ul>
-<p><note>NOTE:</note> although you can pass untyped pointers, it is not possible
-to directly access memory in another thread’s address space using an arbitrary
-pointer as this is inherently insecure. The ability to pass a pointer between
-a client and server is therefore only of value when the client and server
-are within the same process. In this case, the use of a pointer is obviously
-not limited to pointing to a descriptor, but may also be used to point to
-an arbitrary data structure containing information to be shared between the
-client and server. </p>
-<p>It is important to note that a server may not run until some arbitrary
-time after a client issues a request. Any descriptor containing data to be
-passed to the server must be guaranteed to exist until the request completes.
-For this reason, any such descriptor must <i>not</i> live on the program stack.
-Typically, such a descriptor would be a component of an object which is allocated
-on the heap. </p>
-<p>The following diagram illustrates the general idea. In this case, there
-are three parameters, one of which is an integer, and the other two being
-pointers to descriptors. </p>
-<fig id="GUID-C3369B01-2A0D-5AB2-973B-386FDBBB6B86">
-<image href="GUID-2105B5F0-2D00-5ECA-8859-A8A432423327_d0e241065_href.png" placement="inline"/>
-<p>Inter-thread data transfer</p>
-</fig>
-<section id="GUID-EE636E39-A171-484D-AAF4-7996D04C8EEC"><title>See also</title> <p> <xref href="GUID-79BAF19D-F003-5468-9C01-6E918B06C36D.dita">Descriptor
-concepts</xref>. </p> </section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-E651C7A7-D6EB-533E-A97A-360D089DE7A5" xml:lang="en"><title>Inter-thread
+data transfer</title><shortdesc>Describes how data is transferred between threads.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The client-server message protocol supports the passing of a 32-bit request
+code and four 32-bit parameters from client to server and returning a 32-bit
+result from the server to the client. The parameters may be interpreted as
+plain integers or pointers; pointer types may be untyped (<codeph>TAny*</codeph>)
+or descriptor types (<codeph>TDesC8*</codeph> and <codeph>TDesC16*</codeph>)
+that the server can use to access the client’s address space. The request
+code, parameters, and the parameter types are packaged into a <xref href="GUID-4AD02F14-1142-372F-9D11-224595932034.dita"><apiname>TIpcArgs</apiname></xref> object.
+The parameter types are stored in the kernel side message object so that the
+kernel can check that subsequent operations requested by the server using
+the message are: </p>
+<ul>
+<li id="GUID-1F925301-81D0-5F84-ABEE-BB4DB576DBC1"><p>correct; for example,
+checking that the source and target descriptors are either both 8-bit or both
+16-bit descriptors </p> </li>
+<li id="GUID-EE7CCC5F-0013-55EA-B473-763785F5CD90"><p>permitted by the client;
+for example, checking that when the server tries to write to a client descriptor,
+that the client descriptor is <xref href="GUID-49D4E917-57EA-39AE-8941-144AA8AC2584.dita"><apiname>TDes</apiname></xref> -derived (modifiable),
+rather than <xref href="GUID-52D07F46-2162-380C-A775-C3BB335C42F5.dita"><apiname>TDesC</apiname></xref> -derived (non-modifiable) </p> </li>
+</ul>
+<p><note>NOTE:</note> although you can pass untyped pointers, it is not possible
+to directly access memory in another thread’s address space using an arbitrary
+pointer as this is inherently insecure. The ability to pass a pointer between
+a client and server is therefore only of value when the client and server
+are within the same process. In this case, the use of a pointer is obviously
+not limited to pointing to a descriptor, but may also be used to point to
+an arbitrary data structure containing information to be shared between the
+client and server. </p>
+<p>It is important to note that a server may not run until some arbitrary
+time after a client issues a request. Any descriptor containing data to be
+passed to the server must be guaranteed to exist until the request completes.
+For this reason, any such descriptor must <i>not</i> live on the program stack.
+Typically, such a descriptor would be a component of an object which is allocated
+on the heap. </p>
+<p>The following diagram illustrates the general idea. In this case, there
+are three parameters, one of which is an integer, and the other two being
+pointers to descriptors. </p>
+<fig id="GUID-C3369B01-2A0D-5AB2-973B-386FDBBB6B86">
+<image href="GUID-2105B5F0-2D00-5ECA-8859-A8A432423327_d0e237328_href.png" placement="inline"/>
+<p>Inter-thread data transfer</p>
+</fig>
+<section id="GUID-EE636E39-A171-484D-AAF4-7996D04C8EEC"><title>See also</title> <p> <xref href="GUID-79BAF19D-F003-5468-9C01-6E918B06C36D.dita">Descriptor
+concepts</xref>. </p> </section>
</conbody></concept>
\ No newline at end of file