Windows Mobile 7 will come with Silverlight
Saturday, September 26, 2009 at 8:56PM In a move to improve the potential success of both Silverlight and Windows Mobile 7, Microsoft has announce that Silverlight would be supported on that mobile platform when it ships.
On Tuesday, Microsoft announced that its RTM'd Windows Embedded platform incorporates Silverlight 3 as an app runtime, not just a media player. On Wednesday, Intel announced it is supporting Silverlight 3 to run on its Atom-based devices, running both Windows 7 and Linux.
Microsoft has already announced Silverlight support on the Xbox 360 on some Nokia phones. And Windows Mobile 7, the software giant's next phone operating system, will come with Silverlight 3, said Brian Goldfarb, a marketing director for Microsoft's Silverlight team.
"We are 100 percent dedicated to seeing Silverlight across all three screens – PC, TV and mobile," he said.
The previous Silverlight versions were focused on media, Goldfarb said. Microsoft is hoping Silverlight 3, on the other hand, catches on as a platform for third-party application development.
"We look at Silverlight as a sort of comprehensive runtime platform," he said.
Silverlight 3 is a "cross-browser, cross-platform, cross-device solution," Goldfarb said.
This is one of the few forward-looking moves to come out of Redmond in quite a while.
In fact, I am still surprised that (Microsoft’s) MSN properties still ask me - daily, I might add – to install Flash player before the page loads. It is particularly galling when Tier-1 MSN partners such as foxsports.com require it, or kill your page load times.
Microsoft needs to seed Silverlight as an integral part of its operating systems, and make sure everyone has it from the get-go, obviating the need for a download.
What I would like to see more off is out-of-browser Silverlight apps, such as the excellent blu app from thirteen23.com.
Follow me on Twitter
Initial link from The Seattle Post-Intelligencer’s Microsoft Blog.
Reader Comments (6)
Here's one problem with Silverlight, though: what good is it if there isn't an ironclad certainty that it will be freely (as in price and non-patent-encumbered ) available, for all time, and with equivalent performance, across any system or OS? For example, at the moment, there is no Silverlight for Linux proper (as opposed to only Moblin-based Linux), and from what I hear, Moonlight isn't even close to Silverlight in terms of compatibility. Not to mention that the porting of Silverlight to Moblin sort of raises the question of why Moonlight (perhaps even Mono as well) is even necessary.
Flash isn't perfect, but so far it's the closest to a true platform independent entity we have in that area at the moment. An even better solution would be to incorporate a vendor-neutral open standard for rich media into the HTML 5 spec.
Of course, blu is a full-on WPF app (XBAP-deployed), not an out-of-browser Silverlight app. WPF and Silverlight are two distinct entities sharing a few genes, if you will.
@SilverlightMan: thanks for the education. I trip over those details all the time.
@Will: There isn't any ironclad certainty that Flash or AIR would be free in perpetuity also, is there?
As for other platforms, while I believe there should be versions created for them, I also believe that resources should be directed at where the most bang could be achieved immediately, so to speak. That would mean Windows, with it's gargantuan market share - compared to other OSs.
Also, I seem to remember that the port to Moblin is an Intel project, not a Microsoft undertaking, per se. While I don't know the inner workings of Linux, or the politics involved, I think Moonlight, as a framework, or whatever it is, is necessary, as it might shorten the development time for Silverlight on other Linux distros.
A vendor-neutral spec might be nice; however, where is the ROI for the companies investing in bringing that vision to a reality?
Finally, I sometimes don't understand open source types with regards to choice. For a group that advocates openness, you guys want to limit choices for all to what you like. Please tell me the fairness of that?
Granted Flash is virtually ubiquitous at this time. Does it mean that nothing else should be developed? If something better is envisioned, should the new option not be developed further?
If that is the case, then shouldn't all development on all versions of Linux stop immediately? And I am not saying place them in stasis; I am talking about a total stop, delete all files position.
Your mantra should be inclusiveness for all, including Windows, and all other options.
My mantra?
The blog name says it all.
With regards to Flash, as I said earlier, it has problems as well. Among them, it seems that, at least anecdotally, the performance of Flash is typically worse under OSX and Linux than under Windows. But that is something that only Adobe can fix, given the proprietary nature of Flash.
Certainly just being ubiquitous does not automatically make something best-of-breed. Nowhere did I or will I argue that Flash is the one true rich content medium.
But let me clarify the concern here: what we are talking about is internet content that anyone should be able to access equally, regardless of their choice of OS. If Silverlight is in anyway restricted to only Windows or made in a way that gives Windows preferential treatment in terms of performance or compatibility, then any content that depends on Silverlight has been withheld from the portion of the population that exercises their choice by using a different OS. Just like the highways are open to motorists no matter which model car they choose, the internet should be open to users no matter what OS and browser they choose. If Silverlight is truly OS neutral/agnostic, including Windows _and_ other options, then I suppose I have little to worry about in that regard. If not, then some concerns remain about Silverlight adoption. But again, I'm not trying to restrict choice, but preserve it. Silverlight is only problematic if it in some way imposes restrictions on the user's choices as described above.
@Will : I agree with you wholeheartedly on the preferential treatment for certain apps.
However, I think we should also all remember that companies spend dev funds to create these products, and expect a payback for them.
That said, if any product is gunning for primacy, I agree with you that the developer should take the next three or so major operating systems into consideration, and either dev for them, or make a roadmap public.
Since you are here, would you care to comment on the OpenOffice.org/DIS29500 (Office Open XML) brouhaha?
In that instance, open source adherents were trying to restrict everyone's choice to just OpenOffice's specs.
Was that fair? Or just?
Thank you for your comments, and believe it or not, I am learning from them.
In response to the office format incident, first off Open Document Format is not just "OpenOffice's specs". From what I can tell, it is true that ODF evolved from OpenOffice's specs, but the ODF standard that evolved from those specs is an open standard governed by a committee of various companies. Whereas with the Flash vs. Silverlight issue, we have two proprietary specs governed solely by their respective companies, in ODF we have a true vendor-neutral spec. No one entity has complete control over it or its direction, but multiple entities within the industry can contribute to it and have a say in its development. Once again, this leads to greater choice since there is little threat of vendor lock-in.
In ODF we have a single open standard for the representation of information supported by multiple implementations of information editing software that adhere to the standard. A quick search can list over 10 different office suite applications that support ODF, such as OpenOffice, Google Docs, Lotus Symphony, and KOffice. (I'm not including Microsoft Office here. Though there are third party plugins that I've heard work well, the native "support" in 2007 SP2 is very broken. From what I hear, it strips formulas out of spreadsheets, creates documents that can't be read by other ODF compliant software, etc. Also, the Mac Office 2008 appears to have no native ODF support.) It should be a simple matter to create a document in any one of these programs and open it in another, since they are all following a common, open standard. There is little to prevent a user from switching to and from these programs, since they know their data won't be held hostage in a format that can only be reliably read or written to by the program they are currently using. Also, because the format is open and freely available to anyone to implement, anyone can have a say in the development of the format or create a new software package that supports the format. Therefore competition and choice thrives.
In the case of a proprietary format controlled by a single entity, there is always the problem of vendor lock-in. If someone is using Office Program X, which uses the closed proprietary format DocumentX, then they may have difficulty exchanging documents with users of Office Program Y, since that program might not be able to read the DocumentX format. Furthermore, since Program Y uses its own proprietary DocumentY format, a user with a lot of files already in the DocumentX format might find themselves practically unable to switch to ProgramY, even if they find that ProgramY is a better value or fit for them. And if someone else wants to enter the market with ProgramZ after the other two are already established, then it's almost impossible to do so without having compatibility with the DocumentX and DocumentY formats. If ProgramX were to become essentially a monopoly in document software, then the situation gets even worse, as now everyone's data is held hostage by Company X, as everyone must use only Company X's Office Program X, and only on the operating systems that Company X decides on, under the license terms and prices that Company X dictates. Where is the choice in that?
What I've said so far applies mostly towards situations like we had with Microsoft's older binary formats. Those are still widely used, now that Microsoft has released the file specs for its binary formats, then problem of compatibility with those formats appears to be a thing of the past.
Now let's address OOXML. First off, we must raise the question of why OOXML was needed in the first place, a question you might be able to shine some light on. After all, we already had ODF approved as a standard before OOXML even applied for standardization, if I remember correctly. Since ODF is an open standard, the question is: "Why didn't Microsoft just participate in the development of ODF instead of trying to create their own standard again?". That would keep us from having multiple standards for the same purpose and simplify compatibility issues. It's not like ODF was a closed format that Microsoft could have no _democratic_ say in. Incidentally, how much influence would other entities outside of Microsoft have in the development and evolution of the OOXML format?
At the same time, I'm not sure how much impact this will actually have, but I've noticed that, even after being ratified by ISO, the list of defects in OOXML is 800 pages long. That's 200 pages longer than the full spec of ODF.
http://www.noooxml.org/forum/t-174349/800-pages-of-defect-for-ooxml-here-it-is
Also, what is the situation on OOXML with regards to patents? Ie, what effect will the patent infringement case involving i4i an Microsoft have on the OOXML format? (i4i has already examined ODF and determined that it does not infringe on their patent)
To go back to compatibility, where are we now? We now have two different standards for documents. As for ODF, practically every office program except Microsoft's Office and Apple's iWork offers working native support for it. I can't say that I've done exhaustive testing, but I've not yet encountered any problems round-tripping documents between 3 or 4 of the ODF programs. And on the OOXML side, not even Microsoft yet has a program that adheres to the OOXML standard as it is currently written, though that may come in 2010. Microsoft does have the docx, xlsx, and pptx formats, which I don't think are exactly the OOXML standard. I don't know how good ODF/OOXML conversion is at the moment, but I hardly ever see anyone use the docx, etc. formats anyway; people I've seen generally still use the binary formats and/or ODF for compatibility. Ideally, if we must have two document standards, then it would be good to see equal support both for them across the major office suite programs.
In the end, I hope I have clearly explained how standardization on a single, vendor-neutral open format for documents, backed by multiple compatible implementations of the standard in competing software packages, improves compatibility and actually increases choice in the market. The various office programs can compete fairly on the basis of their merits while speaking a common language instead of relying on vendor lock-in to suppress competition. My concern with OOXML is that it seems somewhat redundant to me, may still contain many technical defects, and may be patent encumbered (depending on what, if any, effect the i4i case has on it), which could make it difficult or unsafe for other parties to implement it. I am also unsure as to how much influence entities outside Microsoft can have on it's development.
Again, if I am in error in any of my statements of fact, please point those out and correct them.