×

Discussion Board

Results 1 to 6 of 6
  1. #1
    Regular Contributor
    Join Date
    Jan 2005
    Location
    Malmö, Sweden
    Posts
    157

    Handling DLL capabilities

    Bashing my head against capabilities.
    Mostly been developing for pre-production devices and rom-included applications so far, so havn't really had to deal with them.

    This is my usecase:

    Lets say I have a DLL with a few utility functions in that does not need any capabilites.

    I want to use this DLL in several projects, and I want to distribute it in binary form to others, to use in their project(s).

    Platsec force me to assign any capability to my DLL that the process that want to load it will use.

    BUT. I can't possibly predict what capabilities they will need for their apps, and I can't just pre-emptively assign all capabilities I could imagine they would need to use. Or is this what I have to do?
    This has serious implications on signing needed for the dll...

    What capabilites would I need? All -TCB?

    I assume that would be quite heavy, and lock anyone from using my dll with a self-signed application...
    But if I just limit myself to the self-signable caps, then I lock out anyone wanting to use it in something that need more..

    Do you have any tips of approaches here, or pointers to any documents I should read I might have missed?

    What would you say is the minimal set of caps I should use for my dll?

    Or should I just stop wasting my time trying to optimize rom waste and memory usage and make it a static library?

  2. #2
    Nokia Developer Moderator
    Join Date
    Feb 2006
    Location
    Oslo, Norway
    Posts
    28,683

    Re: Handling DLL capabilities

    The correct SymbianSigned-way would be distributing your API (.dll) in a separate, signed installation file, with All -Tcb capabilities.

  3. #3
    Regular Contributor
    Join Date
    Jan 2005
    Location
    Malmö, Sweden
    Posts
    157

    Re: Handling DLL capabilities

    Yeah, I'm beginning to realize something like this is how you have to do it...

    Though, I'm not so sure about the "All -TCB".

    I've been reading through "The Complete Guide to Symbian Signed" a few times, which unfortunately isn't so complete, since I still have questions

    They mainly focus on the simple case of distributing an application, and don't touch the issue of shared API dll:s at all.

    "All -TCB" would need both publisher ID and Device Manufacturer approval.

    device manufacturer approval seems a bit silly for an utility api, and I don't even know what manufacturers phones it will be installed on...

    "All -TCB -DRM -AllFiles" (can I write it like that?) should get rid of the DM approval need, but it could potentially limit where it can be used... but it might be an acceptable way... but would bar me from everything but "Certified Signed" signing, which includes "testing"...

    Which raises the next question: How is testing performed for API dll:s? (doc only mention things relevant for apps, and this is still just this silly little utility dll with a few classes in it)

    Next step is "Express Signing", then I can't use CommDD, DiskAdmin, NetworkControl or MultimediaDD either...

    What is the best place for a complete list on the intended use of capabilities so I can make some kind of educated guess on what the future impact will be on leaving those out?

  4. #4
    Regular Contributor
    Join Date
    Mar 2006
    Posts
    280

    Re: Handling DLL capabilities

    Hi;
    Yes, I went through this a little while ago. It all seems a bit mad and inconvenient at first. After a while, you can see the reason behind it and then it just becomes inconvenient.

    This all springs from the fact that platsec gives you a secure environment. If it were possible to load an untrusted DLL into a process that had All-TCB capabilities, you would have a security leak. The code in the DLL would be able to run with capabilities not assigned to it. This is a problem if you are worried about security.

    So, one solution is to have your utility code run in its own exe and call it via IPC. You can wrap the IPC calls in some .ini files for the sake of the calling process.
    You could also release your utility code as a static lib, though you don’t get the space savings of a DLL. This might not be a problem depending on how many clients you are expecting on each handset.

    Like I said, inconvenient. A while after I did this I saw a Symbian doc called “Plug-in_Patterns.pdf” which suggested pretty much the same thing.

    Regards

  5. #5
    Regular Contributor
    Join Date
    Jan 2005
    Location
    Malmö, Sweden
    Posts
    157

    Re: Handling DLL capabilities

    Hi, thanks for the reply.

    I do realize the why:s, but I'm still struggling with the how:s

    Right now it feels like the .lib route is the best way for this little utility class... but this is just warmup, I have bigger dll:s later to worry about where things like rom and ram use begin to really matter...

    I think I will have to have a general version that is Express Signed, and we will have to handle the cases where we need those extra caps separately, and hope it wont be too many of them. (probably wont)
    We can always deliver special versions with exactly the needed caps to be included with the app... I think... Just realized there will be versioning problems then, if some other app exist on the phone that uses the dll...
    Will have to rename it and give it a special uid too... Well not too bad, just mmp file change

    I still wonder though:
    What is the requirements to pass testing for "Certified Sign":ing a sis with nothing but an API DLL in it?
    Is it just the install/uninstall test?

  6. #6
    Regular Contributor
    Join Date
    Mar 2006
    Posts
    280

    Re: Handling DLL capabilities

    You would have to give them an app to run it in. This is a bit pointless because obviously, they have no guarantee you are using the DLL in your app.

Similar Threads

  1. GoogleIt
    By deepika.mangla in forum Symbian
    Replies: 5
    Last Post: 2011-05-28, 11:04
  2. S60 2nd to 3rd/ PlatformSecurity / Capabilities
    By jarkoos in forum Symbian Signed Support, Application Packaging and Distribution and Security
    Replies: 4
    Last Post: 2007-04-14, 14:08
  3. DLL locading problems (capabilities)
    By olympio in forum Symbian Signed Support, Application Packaging and Distribution and Security
    Replies: 1
    Last Post: 2007-03-29, 08:11
  4. dll capabilities in Symbian 9.1
    By SamoylovBoris in forum Symbian
    Replies: 10
    Last Post: 2006-10-11, 07:28
  5. what happens to TLS when DLL is unloaded?
    By rtillitt in forum Symbian
    Replies: 1
    Last Post: 2002-11-27, 12:11

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×