Thanks for srivivek for asking me to post this Tutorial.
UID1-First UID (Type)
UID1-Indicates whether this is an executable file or data file.
| UID value | Numeric value (Hex) | Meaning |
| KExecutableImageUid | 0x1000007A | Indicates this an .exe executable file |
| KDaynamicLibraryUid | 0x10000079 | Indicates this a DLL(executable) There are various types, with different extension(.dll, .app, .ldd, .pdd) |
| KDirectFileStoreLayoutUid | 0x10000037 | Indicates this is a direct file store (data, not executable)Bracketed values from header files |
| KPermanentFileStoreLayoutUid | 0x10000050 | Indicates this is a permanent file store(data, not executable) |
UID2-Second UID (Subtype)
UID2-The meaning of this Uid depends on the value of UID1.
- If UID1 was KExecutableImageUid, UID2 isn’t used.
- If UID1 was KDaynamicLibraryUid, UID2 will be
| UID value | Numeric value (Hex) | Meaning |
| KSharedLibraryUid | 0x1000008D | Indicates this is a static interface DLL (.dll) |
| KUidApp | 0x100039CE | Indicates an application conforming to APPARC(includes all Qikon apps, .app) |
| KLogicalDeviceDriverUid | 0x100000AF | Indicates his is a logical decive driver (.ldd) |
| KPhysicalDeviceDriverUid | 0x100039D0 | Indicates this is a physical device driver(.pdd) |
- If UID1 was KDirectFileStoreLayoutUid or KPermanentFileStoreLayoutUid, then UID2 can be:
| UID value | Numeric value (Hex) | Meaning |
| KUidAppDllDoc | 0x10003A12 | Indicates this is a file store created by an .app to store user data (i.e, a document) |
| KUidAppInfoFile | 0x10003A38 | Indicates this is an AIF file (a type of file store) |
[/]
Secure ID – UID3-Third UID (sub-subType) (Subtype)
UID3-This UID has a unique value for each individual application program and is also used as the Secure ID. For UIKON applications it is used to associate data files with programs
- For .dll and .exe’s , it identifies the particular binary.
- For .apps (UIKON applications) it identifies the particular application program.
- For file stores that were created by .apps, it identifies the application program associated with this file.
- For other file stores, It’s not typically used (but you could use it for anything you want).
The SecureID for a binary is not specified explicitly, instead it is taken to be the same as the third UID. If an application has a secureID of zero, this mean ‘undefined’ , and has several consequences, including lack of privacy for data used by application.
Funnily enough, you can statically link to a DLL without any UID specified in its MMP file. Please note that this does not apply to polymorphic DLL and other (e.g. ECOM) plug-ins.
how do you statically link to a dll?
static libraries of course do not need any uid, since they are no a file of their own on the phone, but part of the executable they are linked to.
I meant mentioning the corresponding LIB file in the EXE's MMP file. That is static linkage. As opposed to dynamic linking, where you use RLibrary to locate and load (and unload) the DLL at any given time during the life-cycle.
I think you are confused.
If you build a dll, you specify TARGETTYPE dll and you you get a lib and dll pair.
You have to specify a UID.
You can then either specify the lib in the mmp or your exe, or use RLibrary.
BOTH ways are dynamic linking, in the first case though, it is done automatically for you when executing your exe, but it still is dynamic linking (using a dynamically loadable library).
Then there is also "static linking" but this is quite different, then you specify "TARGETTYPE lib" in your mmp file, and you end up with only a lib file, containing all code. You don't have to specify a UID.
Then you have to specify the lib file in the mmp of your exe, and it will be linked into your exe at compile time.
The main difference isn't that you can load and unload code, that is more into the "plugin" domain, the point is that the code is not statically included in the binary, but can be shared between several executables.
I think I'm not confused at all, however, admit that might have been not too accurate.
First of all, I confirm that TARGETTYPE LIB does exist and even more it is called static linkage. I was wrong and you were right, alh.
The other way, called dynamic linking, offers two ways for loading a DLL:
Finally, please note that you don't have to specify a UID in your DLL's MMP file if you import its LIB file. We have tried it out and it worked well without any UIDs. I can't locate the section in SDK help, where it was described that UIDs are really necessary for polymorphic DLLs only. At that time (when I read it years ago) ECOM plug-ins did not exist at all, so I now presume that it applies to polymorphic DLLs + ECOM plug-ins.
Thanks for the clarification, I didn't know it was possible to omit the uid3 when automatically loading your dlls.
So it sounded very confused/confusing when you called the automatic loading for static linking, when static linking is something different entirely and that doesn't need any uid at all. (I assume you still need uid1 and uid2 for your dll:s you autoload)
But I guess it makes sense... Its not strictly needed in this scenario, and doesn't provide any extra identification from the name of the file now when all dll:s have to be in /sys/bin
BTW, a good example of how excessive dll-usage can slow down the start of your application, take a look at the N-Gage first-access pack... it has 165(!) dlls that all are likely loaded on startup.
Please note that there is no UID statement in the MMP file of my DLL at all. I assume that based on the targettype the system assigns default UIDs (1 and 2) to it automagically, but not a UID3.
And gosh, how slowly N-Gage starts!!!
SecureID is not always same as UID3. You can explicitly specify SecureID in your mmp file.
And if it is not specified in your mmp then UID3 is taken as the SecureID.
And if both of them are not specified then SecureID will take the value KNullUID.
I'm not sure I would call this piece of information a "tutorial". It looks more like a short reference material, a short compilation made of reference material. I do not (and, of course, can not) object to this material being published here but then I do not feel like I've been actually 'taught' to do something after reading this. So they have all these varieties of UIDs, big deal. In practice, isn't it the opposite: you've been told to implement such and such exe (dll, device driver or whatever) you have a hell of headache with your implementation but it's difficult to imagine that you've chosen a wrong UID or have a lot of headache with UIDs at all. Teach me something applicable to my job, please. Oh, and actually the only might-be-interesting place - about SecureId - wasn't explained correctly as was noticed before. Oh, and shouldn't there have been very briefly explained UID ranges and very briefly outlined a process of acquiring an UID from Symbian (as opposed to using a development UID).- this is an important thing indeed. And who is srivivek anyway.