NewLC - About Symbian UIDs - Comments

Re: About Symbian UIDs

tote — Tue, 22 Apr 2008 12:02:58 +0200

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

Re: About Symbian UIDs

alh — Tue, 22 Apr 2008 11:56:55 +0200

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.

Re: About Symbian UIDs

tote — Tue, 22 Apr 2008 11:21:35 +0200

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:

Importing a LIB file in your MMP file indicates that the DLL will always be loaded into the context of your executable (OR the executable in which your component is running), during executable start-up. All required information is known build-time that allows 1: the loader to load your DLL, 2: the code to use your DLL. Please note that I did not mention how demand-paging might affect DLL loading on purpose.
You don't have to import the LIB file in the MMP file, but you can locate and load it run-time as well (using RLibrary class). In practice, it means that as long as you don't load the DLL in question, it won't be loaded in the process context (unless another component has already loaded it), thus the process will load faster (don't have to load your DLL) and require less memory throughout the whole life-cycle.

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.

Re: About Symbian UIDs

alh — Tue, 22 Apr 2008 10:29:45 +0200

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.

Re: About Symbian UIDs

tote — Tue, 22 Apr 2008 10:20:17 +0200

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.

Re: About Symbian UIDs

alh — Tue, 22 Apr 2008 09:37:27 +0200

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.

Re: About Symbian UIDs

Genesis P — Tue, 22 Apr 2008 09:07:31 +0200

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.

Re: About Symbian UIDs

dennis_george — Tue, 22 Apr 2008 07:15:04 +0200

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.

Re: About Symbian UIDs

tote — Mon, 21 Apr 2008 22:23:02 +0200

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.

About Symbian UIDs

er.khalid — Mon, 21 Apr 2008 07:52:04 +0200

A short introduction to Symbian UIDs