Though this is not surprising, it does show the risk of Microsoft's strategy. Rewriting large, native code applications to meet the requirements of the new platform will be an undesirable task for many developers. Both Google and Palm eventually relented, and permitted native development for Android and webOS. Microsoft, for its part, says that the lack of native code is a technology issue rather than an immutable design philosophy—the inability to safely sandbox native code is the problem. This certainly leaves the door open to a future native code SDK. There are even claims that Microsoft will make an exception and allow Adobe to develop a (native) Flash for Windows Phone.

Third-party browsers are an important part of the Windows Mobile software ecosystem. In particular, Opera Mobile is excellent in all the ways that Pocket Internet Explorer is terrible; it is fast, accurate, finger-friendly, and standards compliant. Though Windows Phone 7 Series will include an improved Internet Explorer (one that should at least be finger-friendly), the browser experience is still set to lag behind its desktop counterpart for the forseeable future. The lack of native code is likely to be as unpalatable for Opera as it was for Mozilla, and if this turns out to be the case, it will mean that Windows Phone has no third-party browsers.

In turn, this puts even greater pressure on Microsoft to ensure that Internet Explorer in Windows Phone 7 Series delivers an acceptable browsing experience. While the current (old) platform could depend on third parties to provide browsing salvation, this will not be an option for the new platform. With a high quality Web browser as an essential feature of competing smartphone platforms, this could leave Windows Phone at quite a disadvantage.

I don't know about this being a big casualty. Firefox on mobile was in stasis when I jumped ship to the iPhone almost two years ago and at alpha 2 now it seems like that didn't change much (at least for WinMob).

The lack of native code is likely to be as unpalatable for Opera as it was for Mozilla...

It's worth noting that Opera only a few days ago released a native version of Opera mini for WinMo 5 and 6, before it was java reliant. They're also releasing Opera mini for the iPhone (it's in Apple's review blackhole at the moment) which wouldn't involve native code. I imagine Opera would be better suited to this, especially since the mobile market is one of their strengths, so they're likely to put the effort in. However Mozilla haven't had a great mobile browser yet

From what I had seen Fennec was never really terribly usable on Windows Mobile anyway, this seems more like a publicity stunt than anything else.

Why would the usability of an application correlate with their desire to offer it? Moreover, how does their announcement that all Fennec-on-Windows-Mobile-development has ceased correlate to a publicity stunt? They were simply announcing that, since the future of Microsoft's mobile platform is currently closed, their engineering effort is better spent on those platforms that are not.

There are even claims that Microsoft will make an exception and allow Adobe to develop a (native) Flash for Windows Phone.

Seems strange to make an exception to your sandboxing rule for Adobe and Flash, who (as I understand it) are responsible for most browser crashes.

Business move, when it's released it at least gives newspaper something to say when they don't know what else to talk about. Gives the "Unlike the Apple iPhone, Windows Phone 7 offers full support for Flash..." which is apparently what everyone cares about these days.

The iPhone doesn't have third party browsers. That hasn't hurt it at all. Until we see the browser microsoft ships on WP7, we don't know whether they'll be hurt or not by the lack of third party browsers.

I don't think this will be such a big issue. There's a body of .NET code to rely on, and most mobile apps are written from scratch anyway. The key will be developer mindshare. Palm is failing because they didn't get any developers to build apps for their platform, even if the platform itself is arguably superior to the competition. Microsoft will have to make it worthwhile for developers to choose WP7. That means leveraging cloud services, and a solid launch day line-up of apps and devices.

There are even claims that Microsoft will make an exception and allow Adobe to develop a (native) Flash for Windows Phone.

Which, if true, just goes to show that Microsoft's stated reasons for requiring managed code are bald-faced lies. Flash's history of security holes in the past few years make it clear that if security is really a major concern, Flash is among the common bits of software that most require sandboxing.

Its also worth noting that the iPhone has had an relatively unstable Mobile Safari from day one, and it hasn't really hurt it at all.

The WebView control that Apple allows developer access to (which they claim is the same control that Safari uses) can freeze and crash on almost anything... Including at one point Apple's own home page. I believe almost every OS revision has included the words "Improved stability in Safari". So, a fully functional stable browser is not a requirement for a successful smart phone as much as we'd like to believe.

(As a iPhone dev, I used to get the WebView to crash on a rather simple plain HTML 'help' file simply by scrolling for 10-15 seconds on any device)

A little out of the box thinking is needed from developers who want to port native code. They can use a technology like NestedVM - http://nestedvm.ibex.org/ . It translates native binary code to Java bytecode. It can work in the same way for .NET.

It may sound far-fetched, but it actually works in practice and the performance is adequate for lots of things. It is a fascinating technology.

There are even claims that Microsoft will make an exception and allow Adobe to develop a (native) Flash for Windows Phone.

Seems strange to make an exception to your sandboxing rule for Adobe and Flash, who (as I understand it) are responsible for most browser crashes.

Consider:

(i) Microsoft's size and marketshare;(ii) The heavy realiance of WP7S on Silverlight; and(iii) The (at least partial) overlap between Silverlight and Flash.

For me, this spells antitrust lawsuits if MS blocks Flash on its web-enabled phone OS and doesn't have a REALLY strong case for it. It's ridiculously easy to spin this as a plan to kill Flash on the mobile market, all while raising Silverlight awareness in order to push it on the desktop, replacing Flash. Which of course may very well happen if they get it right with Silverlight and Flash keeps getting bad publicity.

Can't say I feel very strongly about allowing or blocking native code. The technicalities of the subject are far beyond my abilities hehe. I think consumers will eventually decide if native code is a must or not. I'm feeling very curious about these WP7S phones and may consider getting one after testing them. I already own a Zune HD and would love for it to be a phone.

Microsoft has the best developer tools out there period. Since all new apps are to be create from scratch anyway, I doubt developers would miss NDK. Many developers who moved from windows to mac just to develop for the iphone still complain how crappy Xcode is compared to VS.

I think to do a truly acceptable job of sandboxing native code, they would have to switch to a capabilities-based security system--but this has substantial repercussions for API design, and the Win32 API (or the approximation to Win32 that WinCE provides) isn't up to it.

I'm not sure what security WinCE 6 even supports.

There is also the problem of privilege escalation vulnerabilities. Do we really know how well-written WinCE actually is? I imagine it would be easier for native code to attack the OS than it is for managed code.

That said, if the Flash thing is true, it's pretty remarkable; Flash's lousy reputation is well-deserved. The only saving grace is that most exploits will try to inject x86 code, which of course will fail on ARM.

,,,Until we see the browser microsoft ships on WP7, we don't know whether they'll be hurt or not by the lack of third party browsers.

But I think we can guess that it's going to be at least a small problem for Microsoft, early on. Based on their past performance there with 5 and 6, fair or not, some people may forgo WP7 if it has no alternate browser available from day one (or two, or three). The new browser might be absolutely perfect, but some people are not going to give it a chance unless/until they hear and read lots and lots of really good things about it, or even get hands-on experience with it. How much that will hurt Microsoft's chances of success with this remains to be seen, I couldn't guess. Perhaps not much in the general consumer market, but a bit more in the tech-geek market. The numbers might not mean much to them right now.

Apple made a lot of effort to ensure that the skills acquired by Mac developers would translate to iPhone development. Most apps may be written from scratch, but the APIs which are used are directly analogous to those used for desktop apps. This meant that the entire Mac dev community was able to contemplate iPhone development. And it ensured that companies which wanted to get into iPhone development had a pool of developers to draw expertise from.

Palm, in contrast, signalled that all development should be done using web design principles. There is certainly a large pool of developers who are capable of using JavaScript and CSS to create web sites. But, that expertise does not necessarily extend to the kind of direct interaction most people expect from a mobile application.

Now Microsoft seems to be making the same decision as Palm. There are many C# programmers of course, but they are more skilled at creating in-house enterprise applications. Rather than tapping into the talents of native application designers Microsoft is going to require that companies tap into the vertical market application designers. These people are skilled at quick and dirty UI and database optimization, not at direct interaction.

As mentioned in the post, Palm relented, and offers a native SDK. As did Google for Android.

Which is why I think that capitulation from MS will unfortunately be sooner rather than later. I say "unfortunately", because whilst I would like native code development, I would also like it to be secure, which is certainly not the case on the iPhone.

ergh... what? There have been quite a few third party browsers on the iPhone for a while if you actually care to check it out before you post it. Apple doesn't however allow any non-webkit browser so it's possible that Opera mini will be rejected rather than "duplicated functionality".

The iPhone doesn't have third party browsers. That hasn't hurt it at all. Until we see the browser microsoft ships on WP7, we don't know whether they'll be hurt or not by the lack of third party browsers.

That's not quite true. There are plenty of third party browsers; they just have to use Webkit.

Opera has just applied to the app store for theirs, which doesn't use Webkit. But that one renders and compresses pages on its own server, then sends it to the browser. We'll see what happens with that.

Its also worth noting that the iPhone has had an relatively unstable Mobile Safari from day one, and it hasn't really hurt it at all.

The WebView control that Apple allows developer access to (which they claim is the same control that Safari uses) can freeze and crash on almost anything... Including at one point Apple's own home page. I believe almost every OS revision has included the words "Improved stability in Safari". So, a fully functional stable browser is not a requirement for a successful smart phone as much as we'd like to believe.

(As a iPhone dev, I used to get the WebView to crash on a rather simple plain HTML 'help' file simply by scrolling for 10-15 seconds on any device)

I've been using my 3G since September 2008, and I can say that it rarely crashes. It used to crash somewhat more some time ago, but almost never for the past six months or so. I suppose you can always write some code that is designed to deliberately crash any browser, but let's not exaggerate minor problems so as to make them sound as though they are major ones. Some browsers on other platforms crash much more.

Microsoft has the best developer tools out there period. Since all new apps are to be create from scratch anyway, I doubt developers would miss NDK. Many developers who moved from windows to mac just to develop for the iphone still complain how crappy Xcode is compared to VS.

I don't know where you get that idea. The iPhone SDK is considered to be the best mobile development kit out there. Not that much is even known about MS's new one for the Windows Phone 7 Series.

There are even claims that Microsoft will make an exception and allow Adobe to develop a (native) Flash for Windows Phone.

Seems strange to make an exception to your sandboxing rule for Adobe and Flash, who (as I understand it) are responsible for most browser crashes.

Consider: (i) Microsoft's size and marketshare; (ii) The heavy realiance of WP7S on Silverlight; and (iii) The (at least partial) overlap between Silverlight and Flash. For me, this spells antitrust lawsuits if MS blocks Flash on its web-enabled phone OS and doesn't have a REALLY strong case for it.

You must be joking. MS has nowhere of a monopoly in mobile OS.

I'm not saying it does, but Flash exists both on mobile and desktop OS's. All I was saying is that MS would be foolish not to consider the risks of antitrust lawsuits based on their using a mobile platform to push Silverlight, and then bringing it as a Flash replacement on the desktop. I have nothing against high market share based on merit, but surely you'll agree that blocking a competitor's software from the start (i.e. no Flash on WP7S) can be presented in a very disfavourable way to MS, attracting the likes of the EC and the FTC.

slumbergod wrote:

Wow, m$ have made some fantastically stupid decisions since Gates left. This must surely rate as one of the best. It is so incredulous what else can you do but laugh. Way to go Microsoft! Hahahaha

I don't know what decisions you're talking about exactly, since you didn't bother to name any. I myself think that announcing WP7S such a long time ahead of expected shipping date is questionable, as are the decisions not to have full-fledged multitasking, copy/paste or native code on WP7S. However, given how MS actually seems to be listening to the market and banging it right on the nail with their latest launches, I'd wait and see the reception they get for their new phone OS. I for one don't buy or not buy a phone based on whether they have any of those abilities.

There are even claims that Microsoft will make an exception and allow Adobe to develop a (native) Flash for Windows Phone.

Seems strange to make an exception to your sandboxing rule for Adobe and Flash, who (as I understand it) are responsible for most browser crashes.

Consider: (i) Microsoft's size and marketshare; (ii) The heavy realiance of WP7S on Silverlight; and (iii) The (at least partial) overlap between Silverlight and Flash. For me, this spells antitrust lawsuits if MS blocks Flash on its web-enabled phone OS and doesn't have a REALLY strong case for it.

You must be joking. MS has nowhere of a monopoly in mobile OS.

I'm not saying it does, but Flash exists both on mobile and desktop OS's. All I was saying is that MS would be foolish not to consider the risks of antitrust lawsuits based on their using a mobile platform to push Silverlight, and then bringing it as a Flash replacement on the desktop. I have nothing against high market share based on merit, but surely you'll agree that blocking a competitor's software from the start (i.e. no Flash on WP7S) can be presented in a very disfavourable way to MS, attracting the likes of the EC and the FTC.

First of all, anyone is free to develop whatever they want on the WP7. They just can't use native code. If Adobe wants Flash on WP7, then they can. No one is stopping or blocking them. Unlike Apple. If Apple isn't getting sued for worse behaviour, I see no reason why MS should be sued.

As mentioned in the post, Palm relented, and offers a native SDK. As did Google for Android.

Which is why I think that capitulation from MS will unfortunately be sooner rather than later. I say "unfortunately", because whilst I would like native code development, I would also like it to be secure, which is certainly not the case on the iPhone.

Doubtful. MS seems to be banking on .net being its future. What better way to get developers buying into the platform than to force them to use .net and silverlight to develop. Also by using .net MS and developers get to benefit from .net's strengths. Like Java, its fairly portable due to its inherent design. That is something MS can build upon to decouple itself from x86 in the future on the desktop platform, but they can also use it to entice developers to want to develop to a wider audience with less effort.

The only reason why the sdk for Palm and Android didn't work is because they were fairly limited, it wasn't about being native or not, it was about capability. Those sdk's were not very capable, were slow, and in Palm's case just plain didn't make sense. MS's strategy is to leverage .net which is being heavily pushed by MS as their primary development platform, Silverlight, which is a really .net with web specific functionality and marry the two as a development platform for a phone. The platform is extremely robust and powerful, you can do pretty much everything you can do using native code using languages that are familiar and an SDK that is already familiar to those who develop using Visual Studio which is the vast majority of Windows developers. Frankly, other than Adobe and Mozilla, I don;t see too many complaints about not being to run native code if you are developing for the platform.

Which is why I think that capitulation from MS will unfortunately be sooner rather than later. I say "unfortunately", because whilst I would like native code development, I would also like it to be secure, which is certainly not the case on the iPhone.

Managed code is not intrinsically more secure than native code. The important thing is how they are designed.

I can design a system, using any modern kernel, so that a particular application can do nothing but touch its own piece of the file system and its own data, and allow it to start getting more functionality from there. This is just as much control as there is with managed code.

In fact, a strong argument can be made that a well-designed system based on security of native code is potential more secure than managed code. The achilles heel of managed code is that, in a production system, you are going to still end up with a significant amount of native code, such as your graphics rendering code. In fact, one of the big pieces of native code you will have will likely be the web browser core... code that is well known to be extremely complicated and a common source of vulnerabilities.

If you are relying on managed code for your security, any vulnerability in any of that native code opens your world up to the attacker. The more system-level native code you have, the more code you have to do extremely strict security audits of, and even so the more chance you have for vulnerabilities. And since so much standard code is in the form of native code, this is a difficult battle: libpng, libz, libjpeg, sqlite, the list goes on; there is just going to be a lot of native code.

In contrast, if you enforce security at the native level, most of your potential holes are at the kernel level in how it isolates processes and users. And if you rely on user IDs for your application sandboxing (as Android does), you get the double advantage of making use of the same multi-user protection features that these kernels were designed to support and are paranoid about maintaining. At that point, you can now start poking specific holes through the tight security to allow the native code to interact with things outside of itself in a controlled, well-defined way, with less chance of them being able to take advantage of bugs in other processes and users to compromise them.

And by the way, Android was designed from the start to support native code. Its security is entirely based on application sandboxing through processes and user IDs, in part to allow for this. The main reason why an NDK didn't exist in the initial release was simply a matter of the time required to define a native ABI and API that could be supported going forward, as well as tool and other support.

The other reason for Android being designed this way is that we think it is simply a more secure way to do things. For example, if an attacker compromises your browser through a bug in it, the amount of damage it can do is quite limited because it is still running in the native code sandbox of the browser that has very limited access to anything else. Likewise an attack through a media codec will end up only having access to the media sandbox with extremely limited access to other things. (In fact there was a security vulnerability found in one of the media codecs last year, but this was not a big deal because Android's application sandboxing meant there was actually little that could be done with that.) And this applies as well to any application: for example an application that uses a web view inside of itself, if compromised, can still only execute things in the native sandbox of that app.

Microsoft has the best developer tools out there period. Many developers who moved from windows to mac just to develop for the iphone still complain how crappy Xcode is compared to VS.

Well, it's up to MS how much they will balance between developer needs, and consumer-needs.They want to push tools to developers, and phones to consumers.

Judging by this article, and other consumers - some might say, Opera Mobile is the best mobile browser out there, period. And many users who moved from Symbian/S60 phones to Windows Phone will probably complain when they are stuck with the much slower IE on their new phone.

Consumers will focus on your needs, just as developers focus on their needs.If browsing is important for that consumers, they will take this into account when buying their next phone.

For a moment there, I thought the article used "Opera Mobile" and "excellent" in the same sentence. I have a phone that had Opera Mobile pre-installed, and it's a terrible, _terrible_ piece of software. I will admit, though: compare anything to Pocket IE, and it'll look like the bestest browser evar. But it doesn't say a hell of a lot.