Symbian and Windows on the same device - what the hell?

I've just finished knitting the brows after reading it in the news that IBM launches an initiative that has something to do with the mobile world. "It seems", I thought, "that there's so much money in mobile business that even the Big Blue could not resist".

But now I'm totally down on the floor with the idea of having more than one, potentially completely different, operating systems on the same device. I've just read that Motorola invests in VirtualLogix, Inc. whose "VirtualLogix VLX enables multiple operating system environments to run concurrently on shared hardware and provides a range of performance, fault tolerance and security options to address specific market requirements".

In my opinion, the whole solution abounds with challenges. Technically, from usability/business point of view, whatever. The thing is that each member of the value chain must learn/tackle something new. For example,

  • Device manufacturers must be prepared for having to integrate such hardware elements in the same device that enable multiple operating systems to run in parallel also considering the cost of virtualization (in terms of time, but money-wise, too). These pieces of hardware must give the best performance so that the user experience is constantly good on all platforms. For example, whilst a ~500MHz CPU performs well on a Windows Mobile-powered device, it's a dual 330MHz CPU that gives the same performance on an Nokia N95 8GB. Of course, this applies not only to the CPU, but to memory, persistent storage, etc., too. Thus, hardware costs will definitely be higher than for regular phones.
  • Of course, there will be a constant fight for giving the same performance as on a normal device and also keep the price of the device as low as possible. As to software vendors,
    • Writers of guest operating systems (each operating system will be guest, by the way) must prepare for a new challenge, namely that scarce system resources will become even busier and harder to get access to.
    • Some weird situations could also occur, for example, when a resident background application would be waiting for an incoming call, which would eventually be "stolen" by another virtual device with a higher priority.
    • In addition, it would result in a much better user experience if commonly used resources, such as persistent storage, were shared. For example, the file system:
      • One use case would be to allow the user to seamlessly move files between OSes.
      • Another to allow browser applications of the same type running on different platforms (e.g. based on WebKit on Android and S60) to share cookies, forms data, etc.
      • On the other hand, mobile OS vendors should be careful about what they would give access to: a secure platform cannot afford making a security hole by letting other platforms access sensitive shared files (such as DRM-protected content) unless a satisfactory level of protection is applied.
  • I'm not sure as to how network operators could be affected by the introduction of a multi-OS mobile device other than having to adjust something in their administration system. Oh yeah, a seamingly not so important question: branding should apply to ALL operating systems running on the same device. Anyway, I think these issues would be less important and easier to solve than the challenges described above.
  • Not necessarily a content provider issue, but it rather concerns the content consumer who would not like to pay for the same content twice in order to be able to use it on the same device, but on a different platform. For example, I wouldn't like to pay again for an MP3 music that I've already downloaded to my Windows Mobile device, but would like to listen to it now on my S60 phone (remember, we're talking about the same phone!).
  • Finally, the user: I think the experience, as such, would be new to the user. The feeling that she can choose which device she'd like to work with today. However, it's uncertain at what price this feeling would come: in terms of user experience, reliability, price of the device, etc.
Personally, I think it's not the right time to introduce such an advanced technology, not as if it was a question now. When smartphones are still often considered as a toy used by mobile geeks, when most people still want to use them only for voice calls and text messages, when enterprise infrastructures rely on/users committed to either Windows Mobile or Symbian, but not both - there is simply no business demand and serious reason to hurry. It must be a long-term plan, though I still wonder if/how/when it will work out.

Originally from mobile-thoughts.blogspot.com.

My two cents,

Tote


Re: Symbian and Windows on the same device - what the hell?

Yes, what the hell. For me, this is only a sign how desperate companies already became, facing the utterly terrible fragmentation of the mobile OS landscape.

And, for Motorola, is there really no other solution to their problem "Can't decide which OS to use" other than "Bright idea, we will put them all into the phone at the same time!"

Time for new management, if you ask me.

Re: Symbian and Windows on the same device - what the hell?

That's what they're doing right now: changing the management. Or you would change even the new one? Eye-wink

Re: Symbian and Windows on the same device - what the hell?

Or, I've presented an alternative view here...

http://twmdesign.co.uk/theblog/?p=114

Re: Symbian and Windows on the same device - what the hell?

Symbian OS and the GSM stack can already be executed on a single processor in the new versions of the Symbian OS, if this was your point.

Re: Symbian and Windows on the same device - what the hell?

Yes, but the question is how it is done. I don't think you can take just any GSM stack and put it alongside Symbian on the same CPU. I would guess it must be Symbian's GSM stack, tweaked for your hardware, or at least a GSM stack that follows a lot of conventions and has to implement a lot of interfaces to play nice with the Symbian kernel.

In this way, you arrive at a GSM stack that you can't use on the same phone hardware if you as manufacturer want to offer the same phone, but with Linux in addition to your Symbian-based model. You end up "porting" (in a certain sense) your GSM stack to Linux. And to Windows Mobile. And to...

With virtualization, goes the theory as I understood it, you can put *one* GSM stack unchanged alongside *any* operating system on a *single* CPU.

Nice theory, but frankly I don't buy it. This virtualization layer adds a whole level of new complexity where things can go wrong. Maybe you might manage to save some work because there is no need for porting the GSM stack, but I think you will spend about an equal amount of work to get the whole "virtual" thing right. Plus you spend license fees for the virtual machine that you could have spent for a second CPU. Zero-sum game, at best.

Re: Symbian and Windows on the same device - what the hell?

As far as I know the reason for device manufacturers and Symbian to maintain the separation between the RTOS and the Application OS is that device manufacturers want to protect their IPRs and their home-brew GSM stacks. I'm not sure if there is a Symbian GSM stack, as such, and even if it does exist if any device vendors have taken that into use.

What I can read, though, from VirtualLogix VLX introduction is that there would be a single comms stack, which they would provide: "... Enables the use of a rich OS on a single ARM core architecture without the need to modify the existing modem software".

Re: Symbian and Windows on the same device - what the hell?

>> without the need to modify the existing modem software".

That was my point exactly.

Cost is the chief driver for one chip - but people often underestimate the cost of modifying and maintaining a complex platform. Software asset reuse is massively important to a big company because hardware can be swapped quicker than software these days.

On top of that. Real time programming/embedded programming is distinct engineering discipline - often clouded by the fact that many developers who have written mobile apps classify themselves as embedded programmers.

The other way of doing singe chip it is to introduce a personality layer. This essentially provides a library of mutexes, threads etc which emulates an incumbent RTOS allowing for compilation of the signaling stack and test code on top of another OS.
The disadvantage of personality layer is that you need one for each OS, and each has to be carefully verified.

Here are some examples of typical layouts:

- The first Symbian phone which I worked on had RTOS and Symbian running on a single chip (back in 1999). Series 40 devices tend to run everything on the RTOS, but "open" OSes rarely attempt to run signaling stacks.

- The iPhone is 2 chip. It has a 2.5g daughter board which could be switched for 3G without having to modify the main ARM11 cpu.

- Freescale's MXC reference design is single chip, but runs most of the signaling stack on a starcore DSP.
http://www.freescale.com/files/wireless_comm/doc/fact_sheet/3GREFDESIGNFS.pdf

When you start adding real time multimedia, virtual memory paging (by nature undeterministic) and a product which is assembled from many many partner deliveries, it takes an enormous amount of effort to verify the integrity of an entire system.

In summary. One chip, one OS is not a synonym for "best solution", like all engineering, the best solution takes into account cost, skillset, organizational factors, complexity, reuse and ROI.

I wrote a bit more about it in context here:
http://twmdesign.co.uk/theblog/?p=104