Jaa

How does Silverlight compatibility work?

  • Artikkeli

Compatibility is extremely important to Silverlight, so how exactly do we achieve it?  Before we get into that, we need to take a moment to define different types of compatibility. The most important is application compat -- if you have a xap written for SL2, it should run unchanged when you run it with the Silverlight 4 plug-in.  (SL1 doesn’t have xaps but similar concepts apply to SL1 applications)  Our goal is to never break applications, even if they are doing things the wrong way or relying on undocumented behavior, and while there's not much we can do about the app that uses reflection to enumerate all properties and crashes when it encounters new ones (really happened!), our experience with SL1/2/3/4 is we get pretty close to that goal.
 
Another kind of compatibility is upgrade compat -- when you take a Silverlight 2 app and recompile it against SL4, does it still work? Similarly, can you take a control library developed for SL2 and use it unchanged in my SL4 application?  This isn't quite as important to us as application compatibility – if fixing a bug means breaking upgrade compatibility, we’ll fix the bug -- but it's something we keep in mind with every change we make. 
 
Quirks mode
 
In order to support older applications, Silverlight has the concept of "quirks mode". In quirks mode, Silverlight tries to be bug for bug compatible with the previous version. (Actually, there's more than one quirks mode -- quirks mode for SL2, quirks for SL3, etc)  When the SL4 plug-in runs an application developed for SL3, Silverlight detects what version the xap was designed for & goes into the appropriate quirks mode.
 
Of course, each quirks mode bug is also an upgrade breaking change -- if your application depends on that bug, when you upgrade your app, you'll need to stop relying on the old behavior.  In order to facilitate this, the Silverlight team documents the differences between quirks mode and normal mode, see https://msdn.microsoft.com/en-us/library/cc645049(VS.95).aspx. 
 
It would be too unwieldy to quirk every last change and bug fix that goes into Silverlight.  But we err on the side of caution and quirk anything that may affect a functional real-world application. To keep things simple, we don't quirk issues that would only affect test cases not real-world apps, nor do we worry about changing a broken app into a different kind of broken app. (E.g., the app used to kill the browser, now it crashes with an unhandled ArgumentException)
 
Another key to compatibility is testing.  With each release of Silverlight, we run hundreds of apps to make sure they behave the same.  We test a broad mix of apps developed internally and provided by customers and partners.
 
Side by side
 
While we don't support side-by-side everywhere, we do use side-by-side technologies in certain places.  The most obvious is the SDK, you can have SL SDK v2, v3, and v4 all on the same machine. And when your application uses an SDK library, the exact version you built against is included in your xap – an SL3 app using DataGrid will use the SL3 implementation, even when running on the SL4 plug-in.
 
We also use side-by-side under the covers to implement some really big quirks.  SL4 for instance contains both a old SL3-compatible parser and a new SL4+ parser, because we knew there were too many parser changes to try to quirk them each individually. Similarly, there's an old & new text engine, and SL4-mode enables a slew of JIT codegen optimizations that aren’t done on SL2 & 3 apps.
 
From time to time, we wonder if it would make sense to go all the way with side-by-side like we do with the .NET Framework and allow multiple versions of the Silverlight plug-in to be installed.  Never say never, but we don't think side-by-side makes sense right now for a few reasons:

  • Users want to install one thing that lets them run all Silverlight content. They don't want to install three or four different plug-ins, and they don't want one plug-in that's three or four times bigger than SL4.
  • In-place updates keep servicing costs down.  When a new browser or operating system is released, we only need to make the change once, in the latest version of Silverlight.
  • Everyone runs the latest version of the Silverlight plug-in.  So everyone writes apps for the latest version of Silverlight. And ISV’s and control vendors can target that latest version and not worry their customers will demand an SL2 version.  You can also reduce if not completely eliminate some mix-and-match concerns -- What happens if an SL4 app tries to load an add-in that's written for SL5?  What happens if an SL4 app serializes a file that an SL3 app tries to read? 
  • Similarly, less mix-and-match simplifies things for Silverlight. For instance, we don't have to worry about what happens if an SL4 plug-in uses LocalMessageSender to communicate with an SL3 plug-in -- under the covers, the shared memory protocol we use is implementation-defined, and we can change it between versions because there's only one version of Silverlight on any given machine.

So that's the inside scoop on how we keep Silverlight compatible with previous versions. As usual, we'd love your feedback so we can build a product that works best for you. Thanks.

Comments

  • Anonymous
    September 12, 2010
    The comment has been removed
  • Anonymous
    September 12, 2010
    To: Anja I understand your frustration when your favorite thing stops working. Have you reported your issues via the contact / feedback on the website you are experiencing problems?  If you could provide a little information, I’m sure the provider would be glad to help you to view your favorite programs and get on with life. Could you please comment here on:
  1. Address of the website (URL) you are trying to view your favorite show?
  2. Copy the text wording of the error you are seeing?
  3. Any additional details that with viewing experience? fyi: I totally agree with you; programs should make our life easier and reduce complexity. This has more to do with how programmers & designers created their program than the underlying technology. If we do our job right, you should not be away of any complexity & to you "IT JUST WORKS!" Thanks in advance for providing the additional information. Thanks, and all the best, --Brian

  • Anonymous
    September 12, 2010
    The comment has been removed

  • Anonymous
    September 13, 2010
    Do the 100s of test apps include internal MS projects using Silverlight, or are they just small apps like a Silverlight replacement for the Windows Calculator?  Just wondering how SCM works here, especially since apps outside the Silverlight team's control may have an evolving set of test cases.

  • Anonymous
    September 13, 2010
    The comment has been removed

  • Anonymous
    September 13, 2010
    ik heb silverlight geinstalleerd maar als ik dan uitzending gemist wil kijken met zilverlight krijg ik niks te zien en ik kan ook de website niet toevoegen bij machtigingen. wat moet ik doen groetjes bianca heemskerk email adres b.heemskerk@live.nl

  • Anonymous
    September 13, 2010
    The comment has been removed

  • Anonymous
    September 15, 2010
    Nick, Thanks for taking the time to reply.  If your test suite includes internal MS apps, then what is the process when a regression is detected in one of those apps?  Does somebody on the Silverlight team create a smaller test case independent of the internal MS app so that it can then be given to the Moonlight team for Silverlight compatibility compliance testing? Also, something Miguel and his band of merry hackers did for Mono was create a tool to allow Mono users to report what APIs they were actually using.  This allowed them to know what API subsets people were actually using.  As Miguel joked about WCF, it also told them what API subsets people actually understood, and revealed that people stayed away from "WCF APIs that required a Ph.D. or better in distributed systems" to understand.  The tool -- Mono Migration Analyzer (MoMA) -- allows people to contribute to Mono by reporting what APIs they are actually calling.  It could be useful for MS to do similar analysis using, say, the Common Compiler Infrastructure Metadata codeplex project, written by the same MS Research guy who wrote ILMerge.  For example, I've heard John Gossman say on the WPF Disciples mailing list that customers find RoutedCommand objects confusing (and I agree there) and would expect people to not use them.  But I would also be interested to know how many people use WPF features I don't like and are not usable in Silverlight, like DataTemplate's DataType ADT.

  • Anonymous
    September 20, 2010
    Hi Bianca, Ik heb je een mail gestuurd om je uitzendinggemist probleem op te lossen. grt, --mark