Everything and the Mobile Software Universe…

Found at All About Symbian:

Red Five Labs has just announced that their Net60 product, which enables .NET applications from the Windows world to run unchanged under S60, is now available for beta testing.

.NET on S60 3rd Edition now a reality?

This is really interesting: even the battle for languages/execution environment is not settled.

For years Mobility coding was tightly coupled with assembly code, then C and in lesser extent C++. The processor of choice is the ARM family (ok some others exist, but no more in the phone industry)…this was before Java.
Basically Java (the language) is no more than a virtual processor with its own instruction set, and this virtual processor, also called a Virtual Machine, or JVM in the case of java, simply do what every processor do: it processes some assembly code describing the low level actions to be performed by the processor to execute a given program/application.

On the PC other execution engines have been developed: the first obvious one, the native one is the venerable x86 instruction set: thanks to it all the PC applications are “binary compatible”. Then Java also, and more recently … the Macromedia/Flash runtime (yes Flash is compiled in a Byte Code which defines its own instruction set). An other big contender is the .NET runtime…with you guessed what, its own instruction set.

At the end it is easy to categorized the executions engines:

• The “native” ones: the hardware executes directly the actions described in a program, compiled from source code to a machine dependent format. A native ARM application running on a ARM processor is an example, or partially for a Java program that is running on an ARM with Jazelle (some Java byte code are directly implemented in hardware)
• The “virtual” ones: Java, .NET, JavaScript/Flash (or ActionScript, not so far from JavaScript: the two languages will be merged with the next version: ActionScript 3 == JavaScript 2 == ECMAScript 4) where the source code is compiled in a machine independent binary format (often called byte code)…But how an ARM emulator running on an x86 PC may be called? you guessed, virtual.

So why bother with virtual execution engines?
Java has been built with the premise of the now famous (and defunct ) write once run everywhere, because at that time (and I really don’t know why) people were thinking that it was enough to reduce the “cross platform development issue” to the low level binary compatibility, simply allowing the code to be executed. And we know now it is not enough!

Once the binary issue was fixed, the really big next one were APIs (and to be complete the programming model) … and the nightmare begins. When we say Java we only name the Language, but not the available services, same for JavaScript, C# or ActionScript. So development platforms started to emerge CDLC J2ME .NET framework, Flash, Adobe Flex, Silverlight, Javascript+Ajax, Yahoo widgets … but after all what are GNOME, KDE, Windows, MacOS, S60, WinMob ?…yes development platforms.

The Open Source community has quickly demonstrated that binary compatibility was not that important for portability: once you have the C/C++ source code and the needed libraries plus a way to link everything, you can simply recompile for ARM/x86 or any other platform. Hum I’ve made a big assumption here: you have “a way to link everything”. And this is really a big assumption: on many platforms you don’t have any dynamic link, nor library repository or dynamic service discovery…so how to expose cleanly your beloved APIs?
This is why OSGI has been made, like COM, Corba, some .NET mechanisms, etc : all is around component based programming, encapsulating a code around what it offers (an API, some resources) and what it uses (API and resources).

Basically an execution engine has to:

• Allow Binary Compatibility: Abstracting the raw hardware, ie the processor, either using a virtual machine or a clean build environment
• Allow clean binary packaging
• Allow easy use and exposition of services/APIs

But it seems impossible for virtual engines to dissociate the language(s) and the engine: Java …well for Java, ActionScript for Flash, all the # languages for .NET. An execution engine is nothing without the associated build chain and development chain around the supported languages.
In fact this is key as all those modern languages have a strong common point: developers do not have to bother with memory handling, and as all the C/C++ coders will tell you it means around 80% less bugs, so a BIG productivity boost, but also and it is something a tier one OEM told us: it is way more easy to train and find “low cost” coders for those high level languages compared to C/C++ experts!… another development cost gain.

A virtual execution engine basically brings productivity gain and lower development cost thanks to modern languages ….. we are far far away from “write once run everywhere”

But as we have seen before it is really not enough and here comes the real development environments based on virtual execution engines :

• .NET framework platform : an .NET VM at hearth, with a big big set of APIs, this is what I would like to know what are the APIs exposed in this s60 .NET port
• Silverlight : also a .NET VM at hearth + some APIs and a nice UI framework
• J2ME: a JVM + JSR + …well different APIs for each platform
• J2SE: a JVM + a lot of APIs
• J2EE: a JVM + “server side” frameworks
• Flex : Adobe Action Script Tamarin VM + Flex APIs
• Google Android: Java VM + Google APIs,… but more interestingly also C++: as android use Interface IDL description C++/Java interworking will work (I have some posts to do about it)
• …and the list goes on

So at the end what really matters is the development environment as a whole, not simply a language (for me this is where android may be interesting). For example the Mono project (that aims to bring .NET execution with Linux) was of few interest before they ported the Windows Forms (Big set of APIs to make graphical stuff in .NET framework) and made them available in their .NET execution engine.

What I haven’t mentioned is that the development costs gain allowed by modern languages comes at a cost: Performance.
Even if Java/.NET/ActionScript JIT helped partially for CPU (Just in Time compilers: VM technology that translates virtual byte code to real machine code before execution), it is still not the case for the RAM used, and in the embedded world the Moore law doesn’t help you, it only helps to reduce silicon die size, to reduce chipset cost, so using a virtual engine actually will force you to … upsize your hardware, increasing the BOM of your phone.
And it isn’t a vague assumption: when your phone has to be produced in the 10 millions units range, using 2MB of RAM, 4MB of flash and an ARM7 based chipset helps a lot let you make money selling at low cost….we’ve spent some nights/days optimizing stuff to make it happen smoothly very recently

At OpenPlug we have built a nice execution engine, not virtual, running “native code” on ARM and x86, with an easy to use service discovery mechanism: a component platform for low cost phones. Then we have added a development environment with tools and middle to high services….we have learned big time and sometime with pain all the bricks needed for such an environment! …

A key value may be around one framework and multiple execution engine for easy adaptation with legacy software and productivity boost for certain projects/hardware, or some parts of the software.

Because once you know how to cleanly make some code running independently from the hardware, you have to offer a programming model! Implying how to share resources between your modularized pieces of code…and in that respect execution engines are of no help, you need an application framework (like OpenPlug ELIPS, or Hiker from access, Android is about that, but also S60 and Windows Mobile): it will abstract the notion of resources for your code : Screen, Keypad, Network, CPU, memory, … this is another story, for another post!

Please comment!
Thomas

Found here:
IDIOT TOYS: Tech reviews for the bored: Nokia used to be better at coming up with phone names
(where did they found this name???)

 
How fast it is moving! The number of form factors is also something to think about: phones hardware will never be commoditized! Which is a good news for…software innovation.

Tags: Nokia

Check this good review: Review: Shazam iD, TrackID is no longer just a Sony Ericsson thing

Was waiting for such a service for ages …. “Tell me what is this song currently on the radio!”.

I’ve not tried bu tI like it

Ok exit the Motofone F3 here is the Sagem my150x : Today I had briefly this baby in hand from an insider. The screen in monochrome, but with a particular technology that looks like old LED based VCR. Notification icons are “hardware based” like the F3, menus are pretty simple and quite well readable with a good contrast, no T9 for SMS. I was impressed by the sturdy sleek and fashion design, and the really great tactile feeling of the case (really similar to the great smooth Samsung plastics).

But what is really amazing is its BOM: 16$ ! Some “rumors” are telling that it will be sold 29 euros in Carrefour. And it seems that in UK Orange to sell Sagem my150x pay-as-you-go phone for 10!

This is the first phone sporting the Infineon ULC mono chip…and this is great!

For further reading check the following reviews:

TrustedReviews – Sagem my150X and MobileGazette Sagem my150x