Harry Li's Forum Nokia Blog

Harry Li's Forum Nokia Blog http://blogs.forum.nokia.com/blog/harry-lis-forum-nokia-blog A Forum Nokia Blog kcomex 2009-11-23T13:16:27Z Retrieve STDERR in Open C http://blogs.forum.nokia.com/blog/harry-lis-forum-nokia-blog/2008/06/21/retrieve-stderr-in-open-c During the debugging and unit test cases running phase, open source projects usually write error string or other information to STDERR file. Quite unluckily, we can not retrieve lines from STDERR in Symbian with Open C. The stdioserver program comes with Open C SDK only redirects STDOUT to a file located on disk, but left STDERR no where to check out. So in my Mozilla porting days, I have to make a workaround for retrieving information written to STDERR because most of unit test cases write error information to STDERR. There are two workarounds which could be used according to different situation. If you have only one or not so many .c source files to fix, then I would like to recommend the first way. That is to modify the source code, add these lines as the top most statement: FILE* stderr_redirect = freopen("C:\\data\\stderr.log", "w", stderr); // Top most line /* Begin of original code lines */ ... ... ... /* End of original code lines */ fclose(stderr_redirect); // Bottom most line The other case is that you have many (maybe up to several hundreds) independent .c source files,  so it's almost impossible to adopt  the first way, like <a href="http://lxr.mozilla.org/nspr/source/nsprpub/pr/tests/" target="_blank">NSPR test cases</a>. We have to figure out another solution. Here I did a small trick, that is modify the stdio.h in <EPOCROOT>\Epoc32\include\stdapis in Open C SDK. The stdio.h in looks like this: ... ... #ifndef __SYMBIAN32__ #define    stdin    __stdinp #define    stdout    __stdoutp #define    stderr    __stderrp #else __BEGIN_DECLS IMPORT_C FILE *__stdin  (void); IMPORT_C FILE *__stdout (void); IMPORT_C FILE *__stderr (void); IMPORT_C char * tmpdirname(void); __END_DECLS #define stdin       (__stdin()) #define stdout  (__stdout()) #ifdef STDERR_TO_STDOUT #define stderr  (__stdout()) #else #define stderr  (__stderr()) #endif #endif ... ... These lines are located around line 265 - 283 if you are using <a href="http://www.forum.nokia.com/info/sw.nokia.com/id/91d89929-fb8c-4d66-bea0-227e42df9053/Open_C_SDK_Plug-In.html" target="_blank">Open C SDK v1.3</a>. With the lines shown as light yellow marked, you could know I just let the compiler treats STDERR as STDOUT, sothat information written to STDERR are all redirected to STDOUT. Of course we have to define MACRO STDERR_TO_STDOUT in that .MMP file. And because we don't want this trick infect other projects which don't have their STDERR touched, so we use this macro to mark the  fence. Once STDERR is redirected to STDOUT, then you could use the original stdioserver program comes with the Open C SDK to check out original STDERR information in STDOUT file. All two ways are easy to understand and use, although I felt the latter one is not so perfect because this requires changing a SDK file. Hope this tip will be helpful in your daily work, and just give me any comments when you get any idea about this. <img src="http://blogs.forum.nokia.com/js/tinymce/plugins/emotions/images/smiley-wink.gif" border="0" alt="Wink" title="Wink" /> Open C Symbian C++ 2008-06-21T14:38:34Z kcomex Limitation on Open C which matters HUGE project like Mozilla http://blogs.forum.nokia.com/blog/harry-lis-forum-nokia-blog/2008/06/03/limitation-on-open-c-which-matters-huge-project-like-mozilla Open C is a quite powerful tool when porting open source projects to Symbian OS platform. But a mobile kitty is not a desktop monster, it doesn't have a so powerful kernel, especially you encountered some design limitations. For small projects which don't utilize lower or system level functions, you will wield Open C without any pain. However, projects as large as Mozilla will meet the limitations and avoid using incomplete or absent functions. So marking those limitations with good documentation and practical experiences is very important. Here I will try to tell you some of my experiences.First of all, you need to read Open C documents carefully, Nokia and Symbian try to explain every limitation they know as clear as possible. So you don't need go discussion board and ask questions before check the documents. *BUT ACTUALLY*, the problem is not all about checking Open C documents, there are possibilities the problem is not caused by Open C but your code. In this case, the situation is not easy. You need practical experiences from others, by talking with colleagues or searching discussion board.Here comes the body. The most incomplete group is libc Signal Handling, but what's lucky is we can find absence of these functions, you don't need to determine where the problem comes from, your code or Open C. The second hard one to over come is using posix_spawn() instead of fork() and exec(). Here I would give you a suggestion, read the complete <a href="http://www.scit.wlv.ac.uk/cgi-bin/mansec?2+fork" target="_blank">fork() manual</a> and compare the difference between <a href="http://www.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html" target="_blank">posix_spawn()</a>. Then check the context of your code, see if these differences applied. This technique is not so easy, even there are further hidden side effect, for example "In the child process created with popen3/popen/system/posix_spawn, operations on the inherited file may cause a panic." in <a href="http://developer.symbian.com/wiki/download/attachments/1411/pips_readme_1_3.pdf?version=1" target="_blank">P.I.P.S. V1.3 Release Notes</a>. Bear in mind those side effects from practice, then the job would be less tough. With two big stop showers ahead, I think the most important is not getting those limitations one by one, but a skill to find if the bug comes from _my_ code or Open C. Once the debug tricks are at hand, there won't be anything "won't fix" <img src="http://blogs.forum.nokia.com/js/tinymce/plugins/emotions/images/smiley-wink.gif" border="0" alt="Wink" title="Wink" />  Open C Symbian C++ Testing Mozilla 2008-06-03T16:53:38Z kcomex Development Depends on Dependency http://blogs.forum.nokia.com/blog/harry-lis-forum-nokia-blog/2008/05/18/development-depends-on-dependency It's quite a while since my last post. Although I'm not there, just because of the terrible <a href="http://en.wikipedia.org/wiki/2008_Sichuan_earthquake" target="_blank" title="earth quake">earth quake</a> happened in SiChuan China, I can't sleep well and concentrate on my codes while people there are suffering. God bless them, hope they could recover with time passes. Actually this has been done two weeks ago. After evaluate the amount of porting works, we could go on with the dependency check of a specific project. For Mozilla, I had shown a <a href="http://weblogs.mozillazine.org/schrep/archives/2007/05/mozilla_platform.html" target="_blank">framework picture</a>: <img src="http://blogs.forum.nokia.com//data/blogs/resources/300055/previews-med/theMozillaPlatform.png" width="520" height="392" align="middle" /> From this picture we know the components in the lowest level are "NSPR" and Cairo". Because "Cairo" is only a graphics base, so we will start from <a href="http://www.mozilla.org/projects/nspr/" target="_blank" title="NSPR">NSPR</a> first.  For other open source projects without such a components diagram, then how we could know its internal components dependency? I would sugguest taking a look at the build(configure && make) output, from this log everything is exposed even with any third party library used by that project. Anyway, large projects like Mozilla will take us more time to get everything clear. Also the more time we put on dependency check, the more clear we could get for a structural view, and the more easy for add or modify codes.   Open C Symbian C++ Mozilla 2008-05-18T16:00:55Z kcomex Evaluate the project before porting http://blogs.forum.nokia.com/blog/harry-lis-forum-nokia-blog/2008/05/08/evaluate-the-project-before-porting Porting an open source project is quite different from developing a new application for mobile phones. During past days without <a href="http://wiki.forum.nokia.com/index.php/Category:Open_C" target="_blank">Open C</a>, we have to rewrite lots of code to satisfy both Symbian OS rules/limitation and difference between mobile devices and desktop computers. Touching so much code will cost more development time, but what's worse is that making changes too much will drive you thinking "Should I start a new project rather than using only a little from this existing project?". So porting an existing application onto Symbian OS makes you keep concerning how much modification will you make, if too much consider starting a new one or just share the name or brand. As far as I know, <a href="https://helixcommunity.org/" target="_blank">HelixCommunity</a> is the first big and famous open source project ported to Symbian OS, and it supports as early as v6.1. I checked out its source in 2004 (means their code nowadays might be different a lot), this is one example of making too much changes so you can tell few difference between porting like this or making a new project. Since S60 3rd Edition, there is Open C we can utilize, the job is easier. But still we can not ignore this consideration because of the nature of mobile phones. In one word, first step of porting an existing project is evaluate how much changes will be made approximately. <a href="http://www.forum.nokia.com/main/resources/technologies/open_c/tips_for_selecting_open_source_code.html" target="_blank">This document</a> in Forum Nokia web site is very helpful, and generally speaking smaller projects are always easier to make decision if it could be ported than bigger ones. Smaller ones are always based on some existing framework, if the framework exists or can be ported on Symbian OS then the project itself will be fine in most cases. Huge project like Mozilla or Helix will give us an impression that it is likely impossible to port cause it has so many dependencies and self owned framework. However, we want eveidence to support our decision. Let's get back to Mozilla, after searching its website, there is an "<a href="http://developer.mozilla.org/en/docs/C%2B%2B_Portability_Guide" target="_blank">C/C++ Portability Guide</a>" which shows us an amazing likeness of Symbian OS programming limitations. From this article, we could learn Mozilla code will probably contain very little exceptions, RTTI and others that Symbian OS C++ does not support. Then with the help of Open C, we could have better confidence about porting without changing too much code. Next we have to  make  deeper  research on the inner  structure  of Mozilla platform, cause you can not start portting any piece of code without knowing which level it lies in and what it does actually. Stay tuned, I will bring more as the work goes on <img src="http://blogs.forum.nokia.com/js/tinymce/plugins/emotions/images/smiley-smile.gif" border="0" alt="Smile" title="Smile" />   Open C S60 Symbian C++ Mozilla 2008-05-08T09:16:10Z kcomex