main index This is "page 2"! Did you already read ''P900 and Linux'' page 1?

My Sony Ericsson P900 pages begin here!

Sending and receiving files from Linux

You can send a "contact" (vCard) or any file (mp4, audio, etc) from P900 to Linux using the "Send as..." option of the main menu in lots of P900 programs (the P900 PacketVideo program, P900 Contacts, while showing a jpeg image not in fullscreen mode, etc: the "Send as" menu option is almost everywhere).

Using "Send as infrared" required 261 seconds of transfer time for an MP4 video of one megabyte (67 seconds of audio+video recording): not that fast, but decent. I just had to install the openobex packages (library and applications) and use the irobex_palm3 of the Obex apps (without parameters, waits for a file to be received; with one parameter, sends the specified filename to the P900 via infrared port; see also my obex_p900 program in the downloads page). The screen output on the PC waiting for the P900 file sending is something like:

> irobex_palm3
Send and receive files to Palm3
Waiting for files
..................................HEADER_LENGTH = 1024633
put_done() Skipped header 42
put_done() Skipped header 44
Filename = miao-miao.mp4
Wrote /tmp/miao-miao.mp4 (1024633 bytes)

Same mode for sending from PC to P900 (one file at a time):

> irobex_palm3 AliscafoNelSole.jpg
Send and receive files to Palm3

name=AliscafoNelSole.jpg, size=179886

PUT successful

During transfer, even in flip-closed mode, on the P900 you will see a status window with a progress bar (note: you can send files via obex even if the infrared port is "busy" for an internet connection; I transfered megs of MP3 files while downloading at full speed: the GPRS packets and OBEX packets share the same infrared channel; this makes me think that the P900 sent/received GPRS data packets get priority on beamed files. This is a very good thing!!). When transfer has finished (you just have to wait; the transfer consumes very little CPU time on the PC), the P900 asks "ok/show/erase".

The Vesuvius rotated by 90 degrees for the P900 screen The JPEG file of 179k was trasferred via infrared port in 109 seconds (the initial synchronization requires about six seconds, and I played around, moving a little up and down the P900). All files are saved in "Incoming mail (transmitted)" folder, not in the standard directories (this means that you will find them in the Messaging section).

Good news: irobex_palm3 works with P900's infrared port configured as either "PC connect" or "modem" mode. Also, check my customized P900 version obex_p900 in the P900 download page.

But the great thing is the networked file system mount. Get the p3nfs 5.15 package, send to the P900 the featured nfsapp-2.6-UIQ.sis file, install it (ignore commercial warnings: the p3nfs and nfsapp softwares are GPL-licensed, not commercial software approved by Sony Ericsson), activate the infrared port of the P900 in "PC Connect" mode (because in "Modem" mode the p3nfs will fail to open it) and execute from the Launcher the nfsapp program.

The nfsapp uses the entire screen but don't worry: if you close and open again the P900 flip then you will get to the applications menu (this is one of the many good reasons to keep the flip; if you remove the flip, you will need to press the jog-dial button, thus exiting nfsapp): the above "white band" window stripe is nfsapp's one instead of the menu icons one, so you can get again to nfsapp by tapping on it.

Note: the nfsapp application does not like that you enable the P900 infrared port before beginning: nfsapp will enable infrared port by itself. I had some reports of needing to enable the infrared port before starting nfsapp, but this seems to be an exception.

By default nfsapp will start opening Infrared (IrCOMM) connection (it will print out some help, using the entire screen for debugging, and it can be terminated by pressing the jog-dial; if you rotate the jog-dial down, it will try to connect via Bluetooth or -asking to confirm to connect- via GPRS/Internet connection; rotating the jog-dial up changes the debug level; i prefer the debug-level 1, the default one, which prints out a letter "w", "r", "d" for every packet wrote, read, directory, etc).

Then start the Linux p3nfsd daemon (it doesn't need to run with root privileges) and "mount" the P900 using the command:
p3nfsd -UIQ -tty /dev/ircomm0 -dir /mnt

After this command is executed (about five seconds to get in sync and mount: then the p3nfsd becomes a background process), you will get the entire P900 filesystem mounted to the /mnt directory, like a networked disk (you can mount almost everywhere, but my personal taste is /mnt). You will see there in /mnt four subdirectories (A:, C:, D:, Z:) that are the internal "drives" of the P900 (A: and Z: are "read-only" and not useful for us; the C: drive is the internal memory "disk" of the P900, while the D: drive is the external memorystick-duo "drive").

The Z: read-only drive is actually the first part of the 16 Mb flash bank drive, of which the first four megabytes are "reserved" (Sony Ericsson says "it is essentially an extension of the ROM area"), and the rest (about 12.7Mb) is the drive C: (on the Chinese versions, because of input/output methods, the C: drive is only about 8Mb).

The p3nfs error reporting is not always exact (if you try to write on the drive A: you will get a "file name too long" or similar error, but the problem is not on file name lenght: the A: drive is an internal convention for some read-only files!) Also, sometimes, on files in system areas, you can get apparent I/O errors on files that P900 uses "live" and does not allow to share, like .r01/.r05 application specific language files), but you can read and write, at a decent speed (see above; generally not more than 8.4-8.6 kbytes/sec). Due to the infrared packet exchange speed, accessing a P900 file or directory requires normally some seconds (the first time you issue a "cd /mnt/C:/system" command, you will have to wait up to five seconds!). Well, don't cry too much: Linux kernel will do some caching of accesses and reads...!

Here I have to add some debugging notes, experienced from a number of different Linux kernels and irattach versions.

First, the p3nfsd sometimes seems to fail initializing without reason: did you start the nfsapp application while the P900 infrared port was disabled (or, in some rare cases, enabled in "PC connect" mode)? Second, the connection to the infrared port uses kernel rpc I/O daemon and lock daemon services (which don't require root privileges), so you shouldn't stop a p3nfsd process during its initialization phase. Third, the irattach sometimes hangs itself (you won't notice any difference in your Linux system, except a "mute" irdadump log: just kill and restart the irattach daemon, generally done by the /etc/rc.d/irda start command). Fourth: soon after p3nfsd places itself in background, issue a df command, to see if the P900 filesystem has been actually mounted (this sometimes may require some seconds; remember that when copying large files, you may have to wait even an entire minute before all buffers get flushed and df completes!).

The -v switch (repeatable more than once on the p3nfsd command line) won't be a great help. It was good for me to understand that the "PC connect mode" is a ppp style connection! The PC-side connection program (p3nfsd, the standard PC suite, etc) just establishes something like a fake ppp connection to use it to exchange/rename/delete/etc P900 own files! =:-)

To unmount the P900 "networked filesystem", you just have to do a fake access to an "exit" file (that is, issue an ls /mnt/exit command); some other operations could disconnect it (i.e.: taking "out of sight" for some seconds the P900 infrared port), but the p3nfs exits only when all "remote" files are closed (if you walk in a P900 directory, even with a cd /mnt/C: command, it will result as an "open" file...!).

By using the df command I found that the entire memory of my P900 seems to be 72184k (that is, about 40Mb internal and 32Mb memorystickduo: 43Mb total used, and 28Mb total free... this free space is mainly memorystickduo's space; I put there almost all files: I don't want to consume internal P900 memory if not urgently needed).

The C: folder contains two directories, system and documents, the first containing the installed P900 software and configuration files, the second containing the documents (images, contacts, etc). Also on the D: drive there is a system folder (to install programs) and other folders (media files, etc). But remember...
you can "brick" (that is: make UNUSABLE) your P900 if you fiddle out too much with system files or documents!

Why do you need to use p3nfs/nfsapp solution? Some reasons why I suggest it to you:

The p3nfs software can be wisely used to do a full backup of the P900 data (at a speed of at least eighteen megabytes per hour - often you can get up to almost thirty megabytes per hour - if using the infrared port), moving/copying/erasing a bunch of files in one batch command, filling the memorystickduo with a bunch of MP3 files, etc, but this may be not as straightforward as one could expect. Anyone willing to write a decent Linux backupping application? (the SyncML stuff is harder to get connected to Linux without going out on the internet). A good thing would be having in the P900 the last files/entries, while accumulating on the huge hard disk space of the PC/notebook your entire data "history" (media files, jotter documents, etc)...!

Er... Sebastian wrote me: "Buy a simple media reader and you can transfer all data to the memory card in a second :-) Works for me. Saves time. Don't have to fiddle with the infrared of your notebook. No longer have to shout at my notbook any longer". YAY!

Viewing audio/video/image files captured/created by P900 under Linux

I am still experimenting; this is the current status:

Notes about the PC file formats the P900 can understand

In this page I already discussed about placing HTML/DOC/etc files on the P900 for later viewing. Now I give out some details for other file types:

Using vCards to fill the Contacts database

The Contacts database is stored in a proprietary format in the file C:\SYSTEM\DATA\CONTACTS.CDB but you do not actually need to deal with it.

If you want to fill quickly your Contacts database, just write down a program that creates a CR/LF-terminated text file Contact.vcf containing a bunch of "vCards" in their common format (if you examine a P900-made .vcf vcard file, you will find out how to fill fields, how to use UTF-8 encoding for accented letters, etc). This way, you can then get rid of those "(w)" and "(h)" tags around (they are just text labels added by current release of P900 Contacts software): the P900 will import without complaining, using the field order you specified. The only unexported field is the ringtone file name (alas!)

I do not know issues on adding a base-64 encoded jpeg image; I am currently beaming via infrared a rather large .vcf file (more than 200 names) without adding photos to contacts. While the P900 exports vCard 2.1 files, it can regularly import vCard 3.0 generated by KDE's KAddressBook (even the entire file .kde/share/apps/kabc/std.vcf which is already in vCard 3 format!).

The vCard 3.0 format is a number of text lines (maximum 72 characters each), each followed by CR/LF terminator. In the beginning of the line there is the field name and then the field contents (separated by the «;» character if multi-line). Since a vCard begins with "BEGIN:VCARD" and "END:VCARD" lines, a text file can contain many vCards. The P900 easily parses this file (but to import 200+ contacts I had to wait a number of seconds), skipping unknown fields.

Below, an example of vCard (fully accepted by P900) with some data encoded into:
NOTE:This is a note field. Notice that it's some lines long, and then yo
 u have to separate it at column 72 (using a blank space on the next lin
 e, like this).
ORG:Main Control Center
ADR;TYPE=work:;;6, Main Street;Portmeirion;The Village;000006;Unknown

Commenting the above vCard:

Description of some P900 application file formats

Sigh! Almost all P900 applications use a binary data file format instead of the common text format. The Jotter application uses a single file database in which are stored all text and graphic pages. If I was a Symbian/UIQ Sony Ericsson programmer, I would have -at least- used a textfile for every text page, and a common bitmap format (PNG, for example) for every drawing, allowing any user to enter/modify "jots" from the PC and sending back again to the P900. Sadly, it's not our case. P900's Jotter, to save a minimum space (actually a few bytes!) creates its archive in one single file. Sigh! (at least, this is good when doing a full backup: you just need to care about one single file)

The simplest mode to access data stored in the binary files is writing a C++ program which uses the standard library calls to read data, and then save it in a "readable" format (the mbox format for e-mails, etc). The primary objective is to have a backup on my PC to use after a "master reset" of the P900.

Anyways, I will discuss here the format of some P900 files. I cannot do a detailed analysis of P900 file formats, but a number of files can be easily created/modified outside the P900 (and then downloaded into the P900 using the above described Linux mount solution).

Reducing an image to P900 screen size

The P900 screen size is 208×320 ("portrait"), with a ratio of 16:10.4 (the width is 65% of the height); in flip-closed mode, the size is 208×208 (1:1, perfectly squared).

For flip-closed mode images, you just have to select a squared area of an image and resize it to 208×208 pixels. By trial-and-error you will know how much area will be covered by the phone network name (the upper stripe of 25-35 pixels) and the area covered by date/time and "unlock" text below.

Almost all digital cameras (like my Kodak DC210+) come with a 4:3 ratio (that is 16:12). Reducing their images while keeping the screen ratio would lead to 320×240 pixels or 277×208; you have to cut about 13% of the shorter side of the image before resizing. Too difficult? Here is a quick table explaining some resolutions:

That is: if your digital camera image is 1152×864, then cut it to 1152×749, and then reduce the final image to 320×208 (suitable for P900). If you want to extract an exact stripe of the images, say 900 pixels large, you will have to shorten size the vertical side accordingly (900*208/320=584.9, that is 900×585 pixels) before reducing to 320×208.

My comments about P900 technical characteristics

Note: most of information commented here comes from the P900 White Paper available on Sony Ericsson official site (after a free registration procedure).

First of all, a comment about P900 memory map. It claims "16 Mb user space". The first 64Mb memory segment is used by Symbian 7+UIQ 2.1 operating system (operating environment, applications, etc), except the last 16Mb which are the internal "C:" drive, containing configurations and other stuff (1.3Mb for the Red theme, 1.5Mb for the local language, configuration files, etc). This is why I can get only up to 10Mb free available memory in daily usage (well, it mainly depends on how much space your mail/sms/mms message use; erasing the Italian language and using the P900 in English mode, I saved about 1.3Mb; also, one could achieve some little extra space by fine-tuning every file, for example cleaning often the browser cache and history)... and it's also the main reason to use always external storage for (at least) videos, audio files, installation of extra software.

The P900 applications use data in exact directories ("document", "image", etc). If you transfer in the P900 some MP3 audio files to listen with the P900 MP3 player, you need to place them in the "unfiled" subdirectory of the "audio" directory. Sometimes I "lost" my files because I placed them in wrong directories (I found them again with the File browser) or because I gave them incorrect extension (".m4a" instead of ".mp4").

Other things:

How to install UIQ 2.1 SDK under Linux using gnupoc.

The official UIQ 2.1 SDK (set of tools and libraries to create C++ and Java software for the P900) runs in a Windows environment. If you want to use it under Linux, you need the gnupoc solution, described and commented below. But if you like a clean makefile-based solution, I strongly suggest to have a look at my "P900 UIQ SDK for Linux".

PLEASE don't ask me anymore help about gnupoc because I prefer my own P900 UIQ SDK for Linux approach; I don't think I will update the notes below. (Anyways, you may also want to read my P900 programming page)

The gnupoc replicates in a Linux environment the UIQ 2.1 SDK. Here I show how to install it, up to building a .SIS installation file of the HelloWorld example source found in the UIQ SDK, trying to be as simple as possible.

  1. You need some tools: Notice: you cannot install the UIQ 2.1 SDK under Wine; the installer will apparently do something, but will never correctly complete. You have to install it on a Windows system (ouch!!). By the way, if you even should happen in future to get success installing it under Wine, the only useful programs are all text-mode utilities (the "UIQ Emulator" doesn't run, etc).

  2. Uncompress the gcc/arm compiler in the root directory: it will create the directory tree at /usr/local/er6 with compiler, linker and tools. They are needed to compile C++ code for Arm/Thumb environments. You can leave them there on the hard disk and even add /usr/local/er6/bin to the PATH, because their filenames ("arm-epoc-pe-gcc") do not conflict with any common Linux gcc installation.

  3. Install on a Windows system the UIQ 2.1 SDK, using all defaults, selecting only "C++ SDK", "C++ Documentation", "C++ Examples" (the Java, MIDP, emulator, etc, aren't useful for our installation: remember, I am targeting to get the C++ stuff only).

  4. Copy the entire C:\SYMBIAN directory tree from the Windows installation to your Linux home directory (e.g.: to /home/alfmar/Symbian). You can now uninstall the SDK from the Windows partition (I had not only to uninstall in the control panel, but also erasing manually the C:\SYMBIAN directory was needed, because the Windoze uninstaller failed). The installer complains if executed under WinXP (but continues installing up to the end), but we don't care because we won't use it under WinXP.

  5. Enter the Symbian/UIQ_21 directory, then give these commands (I assume you use the bash shell, as in almost every Linux distribution):
    export EPOCROOT=`pwd` epoc32 epoc32_clean

    (the is in the gnupoc-utils package: uncompress it somewhere and just use it while you are in the Symbian/UIQ_21 directory). This will create an epoc32_clean directory containing all files with lowercase filenames and text line terminators corrected. Erase the epoc32 directory and rename the new epoc32_clean to epoc32 and enter this directory.

  6. Uncompress here (in the epoc32 directory) the gnupoc-uiq-patch package and run:
    make apply
    (this will complete almost immediately; if you get any error or warning, then you cannot continue...!).
Now the gnupoc has been installed. Let's test it compiling the "Hello World" example program.

First, if your installed UIQ SDK is not on a VFAT filesystem, then edit the HelloWorld.h file and change the line 38 from:
#include <helloworld.rsg>
#include <HelloWorld.rsg>
(this is needed because the HelloWorld.rsg file will be created with the same name of the resource file HelloWorld.rsc only changing its extension; Linux filesystems are case-sensitive, and the biggest part of the gnupoc work is to "lowercase" all filenames).

Then enter these commands:
cd Symbian/UIQ_21
export EPOCROOT=`pwd`
export PATH=$PATH:/usr/local/er6/bin:$EPOCROOT/epoc32/tools
cd UIQExamples/HelloWorld
mv Bld.inf bld.inf
mv HelloWorld.hrh helloworld.hrh
cp $EPOCROOT/epoc32/tools/uidcrc.exe .
bldmake bldfiles
abld build armi urel

...and the gets compiled. Don't be scared of the copy of uidcrc.exe - it must be on the rcomp.exe path or Wine path or local directory, and the quickest and dirtiest solution I found was copying it in the current directory. If not present, you will see an "*RCOMP failed" (failed to write UIDs) error.
The bldmake script (found in the $EPOCROOT/epoc32/tools directory) does not give output messages, and prepares a bunch of "makefiles" for building the application. The abld script (also in that tools directory) starts the building of intermediate and final application files, and shows these messages:
make: Nothing to be done for `EXPORT'.
perl -S -D
/home/alfmar/Symbian/UIQ_21/UIQExamples/HelloWorld/HelloWorld ARMI
make: Nothing to be done for `FINAL'.

Some commands to keep in mind:

The HelloWorld application consists of two files: the main executable (actually it's a dinamically linkable library, because this is what the operating system expects) is (4964 bytes), and is found here:

Don't blame me, but blame Symbian guys: it's quite strange that executables and compiled files are placed all around in fixed directories instead of the current directory. There are lots of design "ideas" like this. For example, the HelloWorld.rsg file (a generated resource definition header file) and other temporary files get compiled in a work directory that is: $EPOCROOT/epoc32/build/$EPOCROOT/UIQExamples/HelloWorld/HelloWorld/armi/
(yes, you've correctly read it! a directory containing two times the $EPOCROOT environment variable content names); the .rsg file gets then copied to $EPOCROOT/epoc32/include directory (YES, it gets copied in the standard UIQ SDK include directory; Symbian guys don't think that installed software and #include directories should be read-only as for almost every existing compiler tool in the world...!).

The second file is the HelloWorld.rsc file (compiled binary resource file: menus, strings, etc), that is 278 bytes and is found here:

We cannot directly execute the .app file above on a P900 because the Symbian operating system will refuse to start any .app file which wasn't correctly installed and registered with the standard .SIS packaging method.

These two files (application and resource) have now to be enclosed in a .SIS file (compressed installation package file for Epoc/Symbian operating systems). Copy and HelloWorld.rsc from their original location to the current directory.

We have to use the makesis.exe utility (also found in the tools directory), which requires an infamous detailed package description list file. Create a text file named helloworld.pkg and containing these four lines (double-check the syntax!):
#{"Our Hello World app!!"},(0x100039ce),1,15,0

This means: package "our hello world app" has unique identifier 0x100039ce (the assigned UID for this application) and version "1.15.0"; it's installable on P800/P900 machines (the 0x101f80be hexadecimal identifier at the beginning of the second line); the package contains the and the HelloWorld.rsc file found in current directory, who will be installed in \system\apps\HelloWorld of the user-chosen P900 "drive" (its core memory or memorystickduo storage, that is C: or D: drive).

Take extreme care about unique identifiers (UIDs) which, by Symbian people, "differentiate file types much better than file extension of other operating systems". See in the documentation files of the UIQ SDK the subsection "UIQ SDK / Java / Java Developer's Guide for UIQ / Running and Deploying / How to obtain UIDs" for more information (don't care about "Java" in the HTML link path).

The HelloWorld UIDs were already assigned (in the HelloWorld.mmp file the user must specify the application type UID - and this is set to 0x101f6163 meaning "world unique UID for this HelloWorld application" - and the platform specification UID - and this is set to 0x100039ce, meaning UIQ 2.x platform on Symbian 7.x operating system), so we don't worry about them in the HelloWorld program. For your personal development (not to be released), you can use any UID from 0x01000000 to 0x0fffffff (development UIDs) as "application specific UID"; Symbian centralized the UID assignment and UIDs can be freely requested from them; I did request ten UIDs and in a few days I got them by email, which I will use as "application specific UIDs" when I will release my next ten P900 softwares. Again, read UIQ SDK documentation for more information.
I do not like this "centralization", but this is the rule they set. They are right when they say that a file should not be identified only by its extension, but their UID solution seems a bit annoying to me.

The makesis.exe is a MS-DOS/Windoze executable which can be executed using the Wine emulator; it takes a .pkg description file in input, parses it, and creates a .sis file. Start it with:
wine -- $EPOCROOT/epoc32/tools/makesis.exe helloworld.pkg

Please note that in recent versions of Wine you don't need anymore the "--" parameter separator (for example in the Wine included in the SuSE 10.0 Linux). You may need to change the rules file accordingly.

You can now beam the resulting helloworld.SIS file to the P900 (for example, using the obex_p900 utility) and install it and enjoy it running.

If the P900 refuses to install it, then probably you forgot to write (or made a typo) on the "SonyEricssonP900PlatformProductID" line. If the P900 installs the .sis file but the executable doesn't appear in the Application Launcher list between other installed programs, then you fiddled too much with destination file names and directory names (in this case you may get an "Application not registered" error if you try to start it with some external program; to appear on the Launcher, a GUI application has to be located in the \system\apps\Name\ directory in which a and a Name.rsc must be present).

I tried to compile other UIQ example programs, but I got lots of errors because of uppercase/lowercase naming and the stupid complexity of their directory tree. Anyways, since I was able to compile and install the gnupoc and use the UIQ 2.1 SDK for compiling a simple program, then I will start experimenting around this working HelloWorld. More information about HelloWorld program is found in the UIQ 2.1 SDK documentation HTML pages, in the subsection "UIQ SDK / C++ / Getting Started / Hello World" and similar pages.

The UIQ 2.1 SDK documentation is a (rather large) manual in HTML format, starting at:
(one can create a short soft link to it) while a quick reference of UIQ include files and .lib libraries starts at:

You can browse them off-line with any HTML browser. So far, I have read only some pages, but found it quite rich and interesting; I hope you will read it (as I will do) and I hope also you will not ask to me for things described there...!

Let's compile now the BasicApp example. First, you have to edit its CQBasicAppUi.cpp source file and, in the first lines, change:
#include <basicapp.rsg>

#include <BasicApp.rsg>

(again, file naming is a mess because the Symbian guys assumed a case-insensitive filesystem like the DOS/VFAT).
Then type in these commands:
cd $EPOCROOT/UIQExamples/BasicApp
ln -s BasicApp.hrh basicapp.hrh
cp $EPOCROOT/epoc32/tools/uidcrc.exe .
bldmake bldfiles
abld build armi urel
cp $EPOCROOT/epoc32/release/armi/urel/ .
cp $EPOCROOT/epoc32/data/z/system/apps/BasicApp/BasicApp.rsc .

Again, don't be scared by uidcrc.exe and the bunch of output messages. The application is 14552 bytes, and the compiled resource file BasicApp.rsc is 438 bytes. Create a text file license.txt containing some text like "Hey!! You are trying the BasicApp! Are you sure you want to install it?". Then create a BasicApp_P900.pkg file containing these five lines (double-check the syntax!):
#{"Let's try the BasicApp!"},(0x101f6164),2,10,0

That is: "BasicApp" version 2.10 for UIQ 2.1 platform, using only these two files (the .app and the .rsc). The license text file will be displayed at installation time (the FT tag) but not installed (it doesn't have a destination); after displaying, the installer will ask yes/no (the TA tag) and installation will be aborted if the user answers "no".

Now we can create the .SIS file as usual. Notice that here (and in the BasicApp.mmp) the UID3 unique identifier is set to 0x101f6164 (while the HelloWorld had 0x101f6163). Execute the command:
wine -- $EPOCROOT/epoc32/tools/makesis.exe BasicApp_P900.pkg
(note: the "--" is needed only in old Wine versions).

The resulting compressed installation file BasicApp_P900.SIS is less than 7k (depending on the size of the license.txt file you created before). Beam it in the P900 as usual and enjoy it!

Other useful resources:

The Open-QUB code generator

The QUB is a graphical tool developed by a number of students which aims to let an UIQ developer to design an user interface; the QUB itself will generate the C++ code and the directory structure for a standard project. The QUB is developed in Java and now is freely available with sources; while they claim they have tested it only under Windows, I am now reporting success for the Linux environment.

Download from the Open-QUB site the ZIP compiled archive ( and, having Sun's Java2 installed (the one required also to install P900's J2ME development kit), start it with
java -jar qub.jar

(the qub.jar is found in the locally created bin directory).

I found a number of minor bugs but it correctly created source code in the common directory structure (group, inc and src).

I created a "Test" application with a number of dialogs, buttons, etc (well, I drafted them only to see what qub can do). After designing the application views, menu, buttons, etc, I was able to generate the C++ code and then compile it and see it running on my P900... But I had to do some little hacking.

First, edit the generated .MMP file and lowercase those stooopid filenames/directorynames (as required by gnupoc, which I expect you have already installed); check out at least these five lines:
TARGETPATH \system\apps\Test
SYSTEMINCLUDE \epoc32\include

(YES!!! you have also to modify TARGETPATH, or it will create another weird directory $EPOCROOT/epoc32/data/z/SYSTEM/APPS/... and you will stay there some minutes wondering where the compiled resource was placed!)

Then I had to lowercase all #include filenames referring to the system include directory (the gnupoc created "qikappui.h", NOT "QikAppUi.h"; Linux filesystems are all "case-sensitive"! except for the generated source files, there is no reason to use uppercase characters!)

I had to do it by hand because I had no time to create a script which understands that an "#include <Qik...>" has to be lowercased, while an "#include <TestAppUi.h>" does not... and I do not want to work out all Java source filenames (at least for now; let's wait first for their possible updates).

After all this editing, I copied the uidcrc.exe in the "group" generated source directory as usual, and launched from there the commands:
bldmake bldfiles
abld build armi urel

...and it correctly compiled all. Obviously I had to create the .SIS file by hand, extracting and Test.rsc from the remote obscure caverns of the Symbian UIQ SDK directory structure, and create a .PKG file... with that I was able to create a .SIS file and install it on my stunning Sony Ericsson P900. I launched it and noticed that the main menu didn't appear; the buttons and combobox were drawn but were disabled, but at least they were there, on the main view of the program (I suppose I will have to add some code to enable and handle them; I didn't investigate this yet, I am already happy for this success and it's a bit late night now...).

Despite the "1.00" version number, this Open-QUB:

Well, we cannot use it for ordinary project development, but at least we have now a decent software that will be (I hope) updated and debugged (Java source is already available).

I will forward the above notes to someone of the developers team, but "version 1.00" makes me think they already passed the exam (meaning "we have to find out some other Java guru" :-) ...Well, who knows? I hope they will get paid to update and maintain this project (because it is actually well done!). I wonder why Symbian & UIQ Technology guys, while "very happy" with this project, didn't release it before... if you plan to sell your operating system, you will increase greatly your sales if a robust, free, reliable series of development tools is out!!

Developing Java (J2ME, MIDP-2.0) applications for the Sony Ericsson P900

While the UIQ 2.1 SDK comes with Java facilities (which do not make me too happy because they run only in Windoze environments), I prefer using native Linux programs (note: I don't like Java; I wrote these notes only because I happened to do some tests; I don't think I will write any extra news about it). This suggested solution features also a graphical J2ME phone emulator with debugging facilities in a Linux window because it uses official Sun packages (Java 2 and J2ME Wireless Toolkit).

First, install the Sun Java 2 package; I found it in the SuSE 9, it's the java2 version 1.4.2.

Then, fetch from the Sun site their free J2ME package, containing J2ME libraries and other stuff; you have to download an 8Mb file self-extracting file and install it. This is quite easy: once downloaded, you will get a file named something like j2me_wireless_toolkit-1_0_4_01-bin-linuxi386.bin

Make it executable and start it:
chmod 755 j2me*

Answer "yes" to the license agreement, and be sure to specify the Java path (maybe the default one is not correct). I had to specify /usr/lib/SunJava2-1.4.2/bin/ (which is the path set up by SuSE Java 2 package installation).

I chose to install the J2ME stuff in my home directory (/home/alfmar/.j2me). Once completed, I started the J2ME wireless toolkit bar (which I found in /home/alfmar/.j2me/bin/ktoolbar), then loaded one of the example projects ("Games") and then press the "Run" button. Great: the J2ME emulator runs correctly in a Linux window! (you can select some different phone templates for the emulated j2me phone: gray, color, minimum, etc).

Now I beamed the games.jar J2ME package to the P900 (actually it's a zip extractable archive, but the .jar extension makes the P900 understand it's a Java Archive); I used obex_p900 to beam it:
obex_p900 /home/alfmar/.j2me/apps/games/bin/games.jar

It was correctly installed on the P900 (remember that the P900 is J2ME-enabled and MIDP-2.0 compliant, not only MIDP-1.0): in the Application Launcher I found three new items (PushPuzzle, TilePuzzle, WormGame). Clicking on WormGame I saw for a short time the "JavaPowered" banner, then the game started. The "console" below is not that nice, so I chose to hide it.

To uninstall these three games, simply uninstall the "SunSamples Games" package from the P900.

I found the sources of the WormGame (.java files) in the /home/alfmar/.j2me/apps/games/src/example/wormgame directory.

I would not prefer the Java to develop P900 programs because it's an interpreted language (thus much slower than a C++ equivalent). I don't care about "portability", because only the P800 and a few other UIQ-based devices have a decently-sized color screen, and I do not want to write applications which must care of different screen sizes and features. J2ME, in my opinion, is good only for a few "lightweight" applications, and its support on P900 is only for commercial reasons.

Links to P900 related sites

There are out lots of P800 related sites, but up to now nothing specific for P900 (except my page, as far as I know) has been created. I don't think that the P900 is a "little enhanced P800", so I will add here only sites actually related to P900.

I strongly encourage anyone to set up his/her P900-related site pages! Let all know that P900/Linux users are a huge community! (you don't need to set up a super-specialized mega-contents page! even a simple description of what you did to get it connected to Linux is good).

Updates of these P900 pages

My P900 pages (click here for the full index) are currently updated almost monthly.

If you find anything incorrect, obsoleted, etc, please tell me by clicking the email address at the bottom of every page. If you create a P900-related site, or link this page to your site, or copy some parts of it on your site, please let me know: I will add a link to your site in the above list.

After you have already read everything of this page (and the P900 "bugs" page) then you are ready to subscribe the P900+Linux tech guys mailing-list!


Click here for main P900 and Linux page

Sony Ericsson P900 index - send e-mail - home page