As I mentioned in my previous post, the first attempt of porting the fstream component of STLport to Symbian OS using plain stdio functions (provided by OpenC) didn't produce good results. Performance was far from being acceptable, and the library had serious stability issues.
I've now implemented the fstream core in terms of native Symbian OS calls (RFs, RFile and the like) and the overall performance has sensibly improved. I don't get panics or strange behaviours anymore. Of course I can't guarantee it's 100% safe, as dealing with STLport code is not an easy task, and I'm a novice Symbian developer. Anyway, my implementation has passed all STLport regression tests, so I'm pretty optimistic.
The good news is, now all 385 unit tests pass on both the emulator and the device!
Today I've spent a lot of time trying to compile a simple "hello world" program based on STLport from the Carbide.c++ 1.1 Express IDE, with no luck. Although the app compiled and linked just fine from the command line (ABLD), the Carbide build process resulted in compiler failures (presumably caused by incorrect order of include paths) and mysterious linker errors. Fortunately the new Carbide.c++ 1.2 is now available for download (if only I had discovered it yesterday!). I'm pleased to say that this new version is much more robust and reliable than the previous one. More important, my STL-based "hello world" application builds and runs perfectly with Carbide.c++ 1.2.
So, I'm now in the final stages: recompile everything, double-check everything, write some README.blah.blah files and make the release. This is going to happen next week, however, as I'm taking a short holiday on Labour day.
Friday, 27 April 2007
Wednesday, 25 April 2007
Update on STLport for Symbian OS
This is an update for those of you who are following the development of STLport for Symbian OS in this blog. As I announced in my previous post the library is almost complete, but I've found that I/O through fstream is pretty unstable, especially in the emulator. After fixing a small bug in STLport I got the stdio-based implementation of fstream work, although with poor performance, on my N80 phone and on a few other devices through Remote Device Access. However, performance on the emulator is so horrible that I couldn't make fstream unit tests complete in a reasonable amount of time. Also, the emulator occasionally crashes or terminates the application with a panic when certain combinations of read/write operations are done.
I think the I/O routines in OpenC are quite buggy (as seems to be the family of printf functions, see here) because even simple code can occasionally fail or even crash. In particular, I'm observing a behavior similar to that described in this post at Forum Nokia, but it's not easily reproducible as it doesn't happen always (and not always under the same conditions).
As a result of two days wasted trying to make buggy things work, I've decided to try a better way: provide a custom implementation of fstream based on native Symbian OS calls rather than on OpenC calls. This shouldn't be too hard, but if I see that it's going to take too long then I'll just keep things as they are and I'll defer the fix until the next release.
Current status of unit tests is pretty encouraging though: only 3 tests out of 385 are still failing! I'm confident that I'll be able to make a release before next week.
I think the I/O routines in OpenC are quite buggy (as seems to be the family of printf functions, see here) because even simple code can occasionally fail or even crash. In particular, I'm observing a behavior similar to that described in this post at Forum Nokia, but it's not easily reproducible as it doesn't happen always (and not always under the same conditions).
As a result of two days wasted trying to make buggy things work, I've decided to try a better way: provide a custom implementation of fstream based on native Symbian OS calls rather than on OpenC calls. This shouldn't be too hard, but if I see that it's going to take too long then I'll just keep things as they are and I'll defer the fix until the next release.
Current status of unit tests is pretty encouraging though: only 3 tests out of 385 are still failing! I'm confident that I'll be able to make a release before next week.
Saturday, 21 April 2007
Porting the C++ STL to Symbian OS 9.1
Over the last three days I've been working on adapting STLport, an open-source implementation of the C++ Standard Template Library (http://stlport.sourceforge.net), to the Symbian OS. My goal is to port all features of the library, including those parts that were deliberately ignored in previous porting attempts due to limitations of older Symbian systems, such as iostream, fstream and locale.
The standard C library that comes with the new OpenC plugin for S60 is the perfect ground for building STLport, which doesn't require any dependencies other than a decent compiler (both WINSCW and GCCE work perfectly) and a standard-compliant C library. Please note that I'm developing with S60 SDKs only, I don't know whether other kits (such as UIQ) come with a suitable C library or whether OpenC would work on such SDKs. So, for now, the port will be limited to S60 3rd edition.
I'm happy to say that the porting process is close to completion. I managed to build almost everything of STLport on both WINSCW and GCCE platforms and I'm now running unit tests and fixing things as I get errors. I think I've even found a bug in STLport that prevents fstream from working correctly (details here: http://sourceforge.net/tracker/index.php?func=detail&aid=1704843&group_id=146814&atid=766244). The only big part still missing is the support for locales, as it requires a customized implementation. Once I get the library up & running I'll dedicate some time to implement it, in the meanwhile a "dummy" locale implementation is present in order to avoid breaking existing code.
So, what are the motivations behind my decision to port the STL to Symbian? Well, the most obvious one is portability. I've written a lot of C++ applications in the past, especially non-GUI engines and OpenGL-based 3D apps, and all of them are based on the STL. Porting them to a new system/platform can be either a breeze, if the new development environment supports the STL, or a pain, if it doesn't. Moreover, sharing a single code base between different platforms can cut maintenance costs down to about half, which is good.
The second reason is that programming for Symbian is difficult. Antony Pranata once wrote an interesting post on this topic, see http://mobile.antonypranata.com/2005/12/19/why-is-symbian-os-development-very-difficult/. The STL, on the contrary, uses widely-recognized programming paradigms and, even better, it enforces good paradigms by exploiting the C++ language itself. Symbian libraries don't enforce the programming style they require, and I think this is the main reason (beyond the horrible, IMHO, coding style) that keeps novice Symbian developers away from the field. Such programmers are given too much responsibility (i.e. manage the cleanup stack manually) and they need to take care of too many aspects that don't have anything to do with the useful code they want to write. When they try and fail too many times, there is a good chance they will give up and never get back to Symbian again unless they have to.
I'm not going to start a flame about the quality of Symbian code. I'm pretty sure there are many experienced developers out there that don't find it difficult to write Symbian programs, but I also think that it's perhaps even more important to "open the doors" to new developers by making things easier and more standard-compliant. I do recognize the reasons behind Symbian architects' choices: when the OS was designed, the C++ language wasn't even standardized and lacked several features like exception handling, so they had to invent their own mechanisms (leave/trap, cleanup and so on). But come on guys, that was 20 years ago...
Anyway, back on topic. I think I'll be able to publish the final port of STLport for S60 3rd edition in few days. I'm going to release both source code and binaries for WINSCW (the emulator) and GCCE (the real phone). Using STLport will be of course possible from any development environment, including command-line (ABLD) and the Carbide.c++ family of products. Initially I'll compile STLport in the form of a static library, because the resulting binary is very large (8 MB) and making it a DLL would be overkill.
More news soon!
The standard C library that comes with the new OpenC plugin for S60 is the perfect ground for building STLport, which doesn't require any dependencies other than a decent compiler (both WINSCW and GCCE work perfectly) and a standard-compliant C library. Please note that I'm developing with S60 SDKs only, I don't know whether other kits (such as UIQ) come with a suitable C library or whether OpenC would work on such SDKs. So, for now, the port will be limited to S60 3rd edition.
I'm happy to say that the porting process is close to completion. I managed to build almost everything of STLport on both WINSCW and GCCE platforms and I'm now running unit tests and fixing things as I get errors. I think I've even found a bug in STLport that prevents fstream from working correctly (details here: http://sourceforge.net/tracker/index.php?func=detail&aid=1704843&group_id=146814&atid=766244). The only big part still missing is the support for locales, as it requires a customized implementation. Once I get the library up & running I'll dedicate some time to implement it, in the meanwhile a "dummy" locale implementation is present in order to avoid breaking existing code.
So, what are the motivations behind my decision to port the STL to Symbian? Well, the most obvious one is portability. I've written a lot of C++ applications in the past, especially non-GUI engines and OpenGL-based 3D apps, and all of them are based on the STL. Porting them to a new system/platform can be either a breeze, if the new development environment supports the STL, or a pain, if it doesn't. Moreover, sharing a single code base between different platforms can cut maintenance costs down to about half, which is good.
The second reason is that programming for Symbian is difficult. Antony Pranata once wrote an interesting post on this topic, see http://mobile.antonypranata.com/2005/12/19/why-is-symbian-os-development-very-difficult/. The STL, on the contrary, uses widely-recognized programming paradigms and, even better, it enforces good paradigms by exploiting the C++ language itself. Symbian libraries don't enforce the programming style they require, and I think this is the main reason (beyond the horrible, IMHO, coding style) that keeps novice Symbian developers away from the field. Such programmers are given too much responsibility (i.e. manage the cleanup stack manually) and they need to take care of too many aspects that don't have anything to do with the useful code they want to write. When they try and fail too many times, there is a good chance they will give up and never get back to Symbian again unless they have to.
I'm not going to start a flame about the quality of Symbian code. I'm pretty sure there are many experienced developers out there that don't find it difficult to write Symbian programs, but I also think that it's perhaps even more important to "open the doors" to new developers by making things easier and more standard-compliant. I do recognize the reasons behind Symbian architects' choices: when the OS was designed, the C++ language wasn't even standardized and lacked several features like exception handling, so they had to invent their own mechanisms (leave/trap, cleanup and so on). But come on guys, that was 20 years ago...
Anyway, back on topic. I think I'll be able to publish the final port of STLport for S60 3rd edition in few days. I'm going to release both source code and binaries for WINSCW (the emulator) and GCCE (the real phone). Using STLport will be of course possible from any development environment, including command-line (ABLD) and the Carbide.c++ family of products. Initially I'll compile STLport in the form of a static library, because the resulting binary is very large (8 MB) and making it a DLL would be overkill.
More news soon!
Saturday, 14 April 2007
Shortcut icons for hidden applications in S60 devices
Some Nokia smartphones based on the Symbian/S60 platform come with a set of preinstalled applications dedicated to the acquisition and management of GPS data. In most of these devices, however, such applications are "hidden", that is they don't have an associated menu item. This is especially true for N-series devices like the N80, while Nokia's business-line phones (E-series) do include shortcut icons in their menu.
This is a well-known fact that has been discussed many times in the past months. The usual procedure for running one of the hidden applications involves using a task manager application to first find the right executable within the list of installed applications and then execute it. This is quite tedious if you need to do that often, so I've put together a tiny installable package that adds the missing shortcut icons to your phone's Tools menu, as you can see in the following picture taken from my N80 (sorry it is in Italian):
This is a well-known fact that has been discussed many times in the past months. The usual procedure for running one of the hidden applications involves using a task manager application to first find the right executable within the list of installed applications and then execute it. This is quite tedious if you need to do that often, so I've put together a tiny installable package that adds the missing shortcut icons to your phone's Tools menu, as you can see in the following picture taken from my N80 (sorry it is in Italian):
The icons added by this package are, in order:
- Landmarks
A database of geographic locations that is shared among applications; - Positioning methods
System-wide configuration of positioning methods that are provided to applications; - Navigator
A tool that displays GPS data such as latitude, longitude, altitude and speed; it also provides basic navigation features that may be useful for maritime or sports use.
Please note that not all phones have these three applications installed. For example, the N73 only has Landmarks, while the N93 doesn't have any of them. Only icons for those applications that can be found on your device will be added to the menu. I've succesfully tested the package on these phones:
- Nokia 3250 (Landmarks only)
- Nokia 5500 Sport
- N73 (Landmarks only)
- N80
Icon labels are localized in two languages: Italian and English.
You can download the file here, it's a self-signed SIS package: http://www.webalice.it/marco.jez/files/navlauncher.sis
Enjoy!
Welcome!
Dear reader,
welcome to my blog! If you're interested in computer programming then you've come to the right place. In these pages you will find news, tips & tricks, code snippets and other features about the exciting world of software development. Most of this blog's posts will focus on the C++ language and related topics, but that's not a strict requirement. If you're not a developer but you are a technology enthusiast you may still want to land here from time to time as I occasionally write for a broader audience too. In this blog you will also find announcements about software applications that I write in my spare time and that I decide to release to the public, so stay tuned!
Now a few words about myself. My name is Marco, I live in Italy where I work as a C++ programmer for a small company that produces custom software and content for real-time 3D visualization systems. For the most part my job is about writing interactive 3D applications using OpenGL (http://www.opengl.org) and higher-level libraries like OpenSceneGraph (http://www.openscenegraph.org), but as a hobby I like to explore other fields too, such as web applications and mobile devices.
Why a blog, you may ask? Well, in the past years I've been actively following several mailing lists and discussion forums where I used to share my everyday work experience with other mates. Unfortunately this is a time-intensive activity that requires a relevant amount of free time. As my work commitment grew over the years I found myself having less and less spare time, so I've now decided to concentrate all my collaborative efforts into a single place. Such place is this blog, my own "experience container".
I hope you will find these pages useful for you. If you have comments, questions or suggestions, please let me know. Feedback is vital!
welcome to my blog! If you're interested in computer programming then you've come to the right place. In these pages you will find news, tips & tricks, code snippets and other features about the exciting world of software development. Most of this blog's posts will focus on the C++ language and related topics, but that's not a strict requirement. If you're not a developer but you are a technology enthusiast you may still want to land here from time to time as I occasionally write for a broader audience too. In this blog you will also find announcements about software applications that I write in my spare time and that I decide to release to the public, so stay tuned!
Now a few words about myself. My name is Marco, I live in Italy where I work as a C++ programmer for a small company that produces custom software and content for real-time 3D visualization systems. For the most part my job is about writing interactive 3D applications using OpenGL (http://www.opengl.org) and higher-level libraries like OpenSceneGraph (http://www.openscenegraph.org), but as a hobby I like to explore other fields too, such as web applications and mobile devices.
Why a blog, you may ask? Well, in the past years I've been actively following several mailing lists and discussion forums where I used to share my everyday work experience with other mates. Unfortunately this is a time-intensive activity that requires a relevant amount of free time. As my work commitment grew over the years I found myself having less and less spare time, so I've now decided to concentrate all my collaborative efforts into a single place. Such place is this blog, my own "experience container".
I hope you will find these pages useful for you. If you have comments, questions or suggestions, please let me know. Feedback is vital!
Subscribe to:
Posts (Atom)