Photos from the camera application can be ‘caught’ the same way as before: they just appear in the filesystem (under \data\image instead of \Nokia\Images, but that’s a minor point). The new camera app seems to automatically put them in subdirectories based on the month (e.g., 200609), which is also the case on newer FP3 firmwares. The code that watches the directory has to switch to such a directory if it appears or exists. Doesn’t need any caps.
It seems that we can still draw on top of the phone application, at least with TrustedUI cap. That said, the normal idle screen has a different UID now and the topmost windowgroup belongs to the phone app only when actually making calls. I just have to find out the new UID. Whether we will be allowed to actually get the code signed is another matter, of course.
A normal program is not allowed to enumerate dlls under \sys\bin. I switched the dynamic dll loading to use a naming convention instead: the blackboard datatype dll with UID 0xdeadbeef now has to be named bbfdeadbeef.dll. Easy peasy, with no functionality sacrificed. (The ‘correct’ way would of course be to use the ECOM framework, but I don’t actually need it for this, since the UIDs are known beforehand in either code or in serialized object representations).
And BTW, and components that need capabilities do need to have UIDs from the V9 protected range. We had to switch all our old ‘legacy’ UIDs to the new ones, which ended up being much more hassle than I would have thought: although all our UIDs reside in one central header (which is not great for compilation times when it needs changing, I admit) and so only had to be changed once, to actually get the applications compiled right I had to delete the %EPOCROOT%\epoc32\BUILD directory – the appname.UID.cpp files were not being recreated even with abld reallyclean – abld build.
And another ‘BTW’ from Nokia/Symbian: 9.1 has stack unwinding! Which breaks auto_ptr … had to change auto_ptr so that it doesn’t use the cleanup stack anymore.