--- a/Symbian3/SDK/Source/GUID-380A8C4F-3EB6-5E1C-BCFB-ED5B866136D9.dita	Fri Jul 16 17:23:46 2010 +0100
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,157 +0,0 @@
-<?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-380A8C4F-3EB6-5E1C-BCFB-ED5B866136D9" xml:lang="en"><title>How
-to use UIDs</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>A UID is a globally unique identifier consisting of a 32-bit number. </p>
-<p>In Symbian platform, objects are identified by a compound identifier, known
-as the <keyword>UID type</keyword>, which is constructed from three 32 bit
-identifiers. The individual UIDs making up the UID type are referred to as <keyword>UID1</keyword>, <keyword>UID2</keyword> and <keyword>UID3</keyword>. </p>
-<p>Symbian platform makes widespread use of UIDs: </p>
-<ul>
-<li id="GUID-CD464385-25EF-5953-AA1F-31F99A12B7F1"><p>UIDs are used to identify
-the types of objects at runtime and loadtime, for example identifying executables,
-DLLs, filestores. </p> </li>
-<li id="GUID-E57A5374-9526-5BEA-BC18-14852DD30423"><p>UIDs are used to verify
-that objects present compatible and expected interfaces at runtime and loadtime,
-for example verifying that DLLs or filestores are of the expected type. </p> </li>
-<li id="GUID-5A2B51EC-DA36-5CC3-A2FA-0F318B80E983"><p>UIDs are fundamental
-to the association of applications with documents. For example, associating
-a document with an application allows the system to launch the application
-when the document is opened. </p> </li>
-</ul>
-<p>A file's three UIDs are stored in the first 12 bytes of the file. </p>
-<p>To program successfully, Symbian developers need to understand why and
-how to use UIDs in their programs. </p>
-<section><title>What UIDs are for</title> <p>From a user's point of view,
-conventional file names are preferable to UIDs for file identification. Symbian
-platform therefore supports a flexible, long filename, file naming scheme. </p> <p>However
-from a system point of view, guaranteed unique, 32-bit numbers provide for
-much safer, systematic, and more lightweight identification. </p> <p>UID1,
-UID2 and UID3 have the following general characteristics: </p> <ul>
-<li id="GUID-251CC75C-E12F-5602-AC72-D61769536325"><p> <keyword>UID1</keyword> indicates
-the structure of the file, for example, whether it is an executable, a DLL
-or a file store. </p> </li>
-<li id="GUID-04F9AE5C-CE1C-5A78-A58E-843CAA821975"><p>The meaning of <keyword>UID2</keyword> depends
-on the type of object it applies to. For polymorphic interface (plug-in framework)
-DLLs, UID2 identifies the interface that the DLL implements. For static interface
-(shared library) DLLs that others link to, the UID2 value is always the same.
-For executables the UID value has to be set to <codeph>KUidApp</codeph> or <codeph>NULL</codeph>. </p> </li>
-<li id="GUID-0C52BBE3-8971-5D13-92D9-1958BD053C90"><p> <keyword>UID3</keyword> distinguishes
-between objects with the same UID2 and can be thought of as a project identifier.
-For example, for an application, the same UID3 is shared by the executable,
-registration file (which defines the application's icon, caption, and some
-capability information), and all documents. </p> <p>The <xref href="GUID-A98F7AA2-A908-527E-9AEC-54DDD10A49C1.dita">SECUREID</xref> need
-not be explicitly specified in the .mmp file, but if it is omitted, then the
-value of the UID3, specified elsewhere in the .mmp file, is used. If the UID3
-is not specified, then the secureid will take the value <codeph>KNullUID</codeph>.
-This has several consequences, including lack of privacy for data used by
-that application. </p> </li>
-</ul> <p>The UID type is a <codeph>TUidType</codeph> object and is constructed
-from a combination of all or some of the three possible UIDs. The UID type
-can be queried to return its component <keyword>UID1</keyword>, <keyword>UID2</keyword> and <keyword>UID3</keyword> values. </p> <p>If
-no UIDs are attached to an object, then all three component UIDs are returned
-as <codeph>KUidNull</codeph>. </p> </section>
-<section><title>UID1, UID2, UID3, and the no UIDs case</title> <p>An object
-in Symbian platform and more particularly files in Symbian platform may have
-all, some, or none of the three possible UIDs defined. </p> <p>Symbian platform
-predefines all possible UID1 values and the UID2 values used for GUI applications
-and static interface DLLs at system level. Symbian developers refer to them
-by their constant names, although in project (<filepath>.mmp</filepath>) files,
-hexadecimal numbers are used. </p> <ul>
-<li id="GUID-95B7B621-CE04-53DE-A708-FCBD4DB5A36D"><p>UID1: examples include <codeph>KExecutableImageUid</codeph>, <codeph>KDynamicLibraryUid</codeph> and <codeph>KDirectFileStoreLayoutUid</codeph>  </p> </li>
-<li id="GUID-8956CAD8-C680-5BD6-9C3F-86821A268C1B"><p>UID2: examples include <codeph>KSharedLibraryUid</codeph> (0x1000008d)
-for a static interface DLL and <codeph>KUidApp</codeph> (0x100039CE) or NULL
-for a GUI application. <b>Note:</b> Both <codeph>KUidApp</codeph> and NULL
-are acceptable values for UID2 when the application is an EXE, although at
-the present time these values are ignored. At a later stage UID2 may be used
-for other purposes, so setting UID2 to values outside of these values is not
-recommended. </p> </li>
-<li id="GUID-BECDDD3F-58E9-5414-ACC7-25BE2217D81A"><p>Symbian developers are
-responsible for ensuring that where UID3 values are required, they are properly
-allocated. See the <xref href="https://www.symbiansigned.com" scope="external">Symbian
-Signed</xref> web site for information on how to allocate UIDs (free registration
-is required to see the FAQ). </p> </li>
-</ul> <p>Note that in project (<filepath>.mmp</filepath>) files, UID2 and
-UID3 values can be specified, but UID1 values cannot; the UID1 value is implied
-by the project's target type. </p> </section>
-<section><title>EXE targets and UIDs</title> <p>All executable targets have
-a UID1 of <codeph>KExecutableImageUid</codeph>. This is defined by Symbian
-platform and is automatically built into any executable target based on the <codeph>exe</codeph> target
-type declared in the project file. </p> <p>A UID2 value should be specified
-by GUI applications (.EXE) and the application architecture expects this to
-be <codeph>KUidApp</codeph> (0x100039CE) or NULL. Console applications (also
-.EXE), which are often used for testing and as example code, do not need to
-specify a UID2, and if they do, it is ignored. </p> </section>
-<section><title>DLLs and UIDs</title> <p>All DLLs, whether they have static
-or polymorphic interfaces, have a UID1 of <codeph>KDynamicLibraryUid</codeph>.
-This is defined by Symbian platform and is automatically built into any DLL
-target based on the <filepath>dll</filepath> target type declared in the project
-file. </p> <p>For static interface DLLs, the UID2 is <codeph>KSharedLibraryUid.</codeph> The
-UID3, which is used to identify the interface to the library, must be allocated
-by Symbian Signed. </p> <p>For polymorphic DLLs (for instance ECom plugins,
-device drivers and front end processors), UID2 identifies the interface that
-the DLL implements. UID3 (which, if required, must be allocated by Symbian
-Signed) may be used to identify a specific implementation of that interface. </p> </section>
-<section><title>Documents and UIDs</title> <p>In Symbian platform, documents
-are really file-stores: stores which can be closed and re-opened. There are
-two different kinds of file store, <keyword>direct file stores</keyword> which
-are write-once-read-many, and <keyword>permanent file stores</keyword> which
-are write-many-read-many. </p> <p>A document's UID1 will therefore be one
-of <codeph>KDirectFileStoreLayoutUid</codeph> or <codeph>KPermanentFileStoreLayoutUid</codeph>.
-The UID2 and/or UID3 will be application dependent. </p> <p>Every native document
-must have an appropriate UID1 which should be set by the application which
-creates the document. Typically documents may have a UID2 of <codeph>KUidAppDllDoc</codeph> and
-a UID3 shared with the creating application. More precisely, a document’s
-UID3 should match that of the application which will open it. </p> <p>Only
-the UID1 is required, but in most cases Symbian developers will want to specify
-second and third UIDs for the documents their applications create and use.
-These UIDs are used by the application architecture framework to manage associations
-between applications and their documents. This allows an application to be
-found and launched when a file is opened, and it also allows an application
-icon to be associated with documents in system shell displays. Conversely,
-it allows an application, when opening files, to select only applicable files. </p> <p>Symbian
-platform also allows default file associations with the implication that in
-some cases users may want to select a different application to open a file.
-Applications which support this must therefore be able to open documents whose
-third UID differs from their own. </p> <p>Applications may also want to open
-non-native documents which have no UIDs, and may wish to be specified as default
-applications for these documents. </p> </section>
-<section><title>UIDs in package files</title> <p>Package (.PKG) files are
-used in Symbian platform to provide the information required to create Symbian
-installation (.SIS) files. Each SIS file contains a UID, which is defined
-in the package file's <xref href="GUID-D9D20EE0-AC86-512A-91C0-EA0ACF3912A7.dita">package
-header</xref>. This UID should be allocated in the same way
-as other UIDs, through Symbian Signed. </p> </section>
-<section id="GUID-8D9B0F56-4CD1-506C-A8DF-A310DC5F58CE"><title>Uniqueness
-and allocation</title> <p>Because UIDs are fundamental to Symbian platform,
-it is important that they are used correctly when developing programs. To
-ensure uniqueness, it is essential that UIDs are properly allocated. </p> <p>Uniqueness
-is guaranteed by managing allocation centrally from a single database. All
-UIDs must therefore be assigned to users by a central allocating authority. </p> <p>UIDs
-are also split into protected and unprotected ranges. Any UID values falling
-below 0x7FFFFFFF are classed as "protected" and are only intended for use
-with signed applications (or those pre-installed in ROM). The software installer
-will refuse to install an unsigned application if it uses a package UID in
-the protected range. </p> <p>Symbian developers can request UIDs through <xref href="https://www.symbiansigned.com" scope="external">https://www.symbiansigned.com</xref>.
-For more information, see the Symbian Signed FAQ (free registration required).
-Note that from version 9 of Symbian platform, UIDs are no longer requested
-from uid@symbiandevnet.com. </p></section>
-<section><title>Reserved UID range for development only</title><p>During development,
-or for test code, temporary UIDs may be chosen from the unprotected test range
-0xExxxxxxx. These UIDs can be used during development for unsigned applications
-but must not be used in released software. Note that such applications may
-not be installable via a SIS file. See the Symbian Signed website for more
-information. </p> <p>Care must still be taken to avoid clashes within development
-teams and between multiple projects, including old projects which may still
-be installed on a Symbian emulator or native platforms. UID clashes may stop
-a program from loading correctly, typically leading to <systemoutput>Not Found</systemoutput> errors. </p> </section>
-</conbody></concept>
\ No newline at end of file