This is "page 2"!
Did you already read ''P900 and Linux'' page 1?
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 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:
Notice that text formatting (lists and bold characters) is always lost while converting: to save it, the binary .jot format should be interpreted (but this format is not documented by SonyEricsson or Symbian; anyways, there are some classes in the UIQ SDK to deal with it). When sending the image only, we get a clean GIF file of 208×227 pixels in 8-bit color mode which is readable everywhere.
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:
BEGIN:VCARD
EMAIL:my_first.email@yahoo.com
EMAIL:my.second_email@msn.com
URL:www.alfonsomartone.itb.it
URL:www.retepnet.it/alfmar
N:Surname;Name
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).
ADR;TYPE=home:;;street/place;city/town;region;postcode;state
ORG:Main Control Center
ADR;TYPE=work:;;6, Main Street;Portmeirion;The Village;000006;Unknown
TEL;FAX:1234567890
TEL;CELL:333444555
TEL;CELL;PREF:7777777777
TEL;CELL:9988776655
TEL:23232323
END:VCARD
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).
The internal internet browser stores its bookmarks in the C:/system/APPS/BROWSER/folders directory. Suppose you have the group "Tech" containing a dozen of bookmarks. There will be a C:/system/APPS/BROWSER/folders/Tech directory, containing a dozen of .URL text files (example filename: PROVA.URL). In the first line there is the string "[InternetShortcut]"; in the second "URL=" followed by the actual bookmark, and in the third there is "WA=0". The first two lines end with CR/LF sequence; the third does not have CR/LF. Example of a bookmark:
[InternetShortcut]
URL=file:///D:/Media%20files/other/
WA=0
(as you can see, this bookmark allows browsing a directory of the Memory Stick Duo and does not start the Internet connection). Another example:
[InternetShortcut]
URL=https://frat.cmnlibrz.org/main/login.asp?language=ITA
WA=0
(notice the https for the secure connection; normal web sites are just like URL=http://www.xyz.net).
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.
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>
to:
#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
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 HelloWorld.app 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 makmake.pl -D
/home/alfmar/Symbian/UIQ_21/UIQExamples/HelloWorld/HelloWorld ARMI
HelloWorld_AppUi.o
HelloWorld_AppView.o
HelloWorld_Application.o
HelloWorld_Document.o
HelloWorld_Main.o
HelloWorld.app
make: Nothing to be done for `FINAL'.
Some commands to keep in mind:
As above, builds the application program (compile and link C++ sources and compile resource files), but shows lots of log messages.
These two commands clear the intermediate files (object files, executables, etc) so that next bldmake and abld commands will compile again everything.
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 HelloWorld.app (4964 bytes), and is found
here:
$EPOCROOT/epoc32/release/armi/urel/HelloWorld.app
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:
$EPOCROOT/epoc32/data/z/system/apps/HelloWorld/HelloWorld.rsc
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 HelloWorld.app 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
(0x101f80be),1,0,0,{"SonyEricssonP900PlatformProductID"}
"HelloWorld.rsc"-"!:\system\apps\HelloWorld\HelloWorld.rsc"
"HelloWorld.app"-"!:\system\apps\HelloWorld\HelloWorld.app"
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 HelloWorld.app 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 Name.app 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:
$EPOCROOT/Documentation/Packages/UIQ_2.1/uiq/index.html
(one can create a short soft link to it) while a quick reference of UIQ
include files and .lib libraries starts at:
$EPOCROOT/Documentation/Packages/UIQ_2.1/uiq/uiqcpp/APIReference/QuickRef/UIQQuickRef.html
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>
to:
#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/BasicApp.app .
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 BasicApp.app 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
(0x101f80be),1,0,0,{"SonyEricssonP900PlatformProductID"}
"license.txt"-"",FT,TA
"BasicApp.rsc"-"!:\system\apps\BasicApp\BasicApp.rsc"
"BasicApp.app"-"!:\system\apps\BasicApp\BasicApp.app"
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:
This package is a self-extracting .exe file for the Windows platform. Once installed, it will add five files in the SDK include directory (the header files CameraExtensions.h, Ecam.h, StreamingAmrPlayer.h, StreamingAmrRecorder.h, Vibration.h) and three libraries in the epoc32/release/armi/urel (the files ecam.lib, StreamingAmr.lib, Vibration.lib). To get them under Linux, restart installation from the point "install the UIQ SDK under Windows" above, installing then also this package, and then moving the entire C:\SYMBIAN tree (containing also these P900 specific files) to Linux and all other operations.
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
(qub_v1_00.zip) 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
SOURCEPATH ..\group
SOURCEPATH ..\src
USERINCLUDE ..\inc
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 Test.app 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*
./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.
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.
The old versions of EDoom (before 1.3) had some little problems (I wasn't able to uninstall it using the "Uninstall" P900 application menu function: I had to do it manually, erasing the folders /system/apps/edoom and /documents/Media files/document/DOOM both on C: and on D: and the file D:/system/install/edoom.SIS -- this is not the cleanest way to do an uninstall: infact EDoom created also a C:/system/fonts directory with two Truetype fonts and a freetype.dll library, which I did not erase).
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!
