Hi Folks,
In this article I’d like to go over some well-known Silverlight divergent behaviours between Windows and Mac.
Cross Platform? What’s that?
Previous .Net UI frameworks like WPF & WinForms were mostly limited to running exclusively on Windows machines.
Silverlight differs from WinForms & WPF in that it runs primarily in the browser and works on multiple operating systems.
From the history of web development (especially from Javascript) we all recognize the importance of writing code that runs on multiple browsers and operating systems.
The Misconception – Silverlight is 100% Cross Platform
Confused? Perplexed? Bewildered? Get a hold of yourself and be a man.
It is often said in Silverlight books, articles and presentations world-wide that “Silverlight is Cross Platform”.
It’s quite easy to see why when first introducing Silverlight speakers don’t immediately go “Well, sort of Cross Platform” or reserve themselves by saying “mostly cross-platform that is.”
Let’s look at some definitions for “Cross Platform”:
- “[…] capability of software to run identically on different platforms […]” – Source
- “Of software, etc., designed to work on various operating systems” - Source
Silverlight is in fact not fully cross platform.
In that strict sense of the definition, Silverlight does have some places where it behaves differently for different operating systems.
There’s a small, yet important, list of differences in how code executes on a Mac and on a Windows machine.
This article is only sourced from MSDN
Every factual statement about a Windows-to-Mac difference that is listed in this article will be quoted directly from MSDN.
I’ve compiled this list based on the following Bing search: site:msdn.microsoft.com/en-us/library Silverlight AND ("Mac" OR "Macintosh" OR "OS X")
I will not be using my personal working experience with Silverlight, or my experience having worked at Microsoft, or any knowledge gained at Microsoft, or any external 3rd party evidence. This article is strictly sourced from official Microsoft Silverlight documentation.
Difference #1: WindowLess is always True
Category: Plugin Browser Integration
“For Windows, you can display a browser-hosted Silverlight content area in either a windowed mode or a windowless mode. For Windows, the default is a windowed mode.
For Macintosh, there is no windowed mode. The mode is always windowless regardless of the Windowless setting.” - MSDN
While on a Windows Machine, you can choose to have WindowLess=False, that state just isn’t available on a Mac.
Which sounds pretty harmless, until we run into issues like this one:
“if Silverlight is running on a Macintosh computer (where windowless mode is always active, regardless of theWindowless setting), the Background property value can specify an alpha value for the color.” – MSDN
If we were to specify an <object> background property with opacity and WindowLess=False, it would still be transparent on a mac.
While on a Windows machine, the background would look perfectly solid.
That would cause a performance hit on a Mac, while leaving Windows machines completely unaffected.
This issue might be especially important since visual properties like background might be set by designers, and not developers.
Difference #2: Different System.Net.Sockets Stack
Category: Coding difference
“On Windows, the System.Net.Sockets namespace provides a managed implementation of the Windows Sockets (Winsock) interface.
On Apple Mac OS X, the System.Net.Sockets namespace provides a managed implementation of the sockets interface based on Berkeley Software Distribution (BSD) UNIX.” - MSDN
The Silverlight Sockets implementation uses different O/S features to implement it’s sockets support.
Perfectly sensible approach, but that might cause some divergent coding differences between Mac and Windows. Like this one:
“On Mac OS X, this property controls how many bytes can be in the network stack's waiting-to-be-sent buffer before additional calls to the BeginSendToGroup or BeginSendTo methods start failing. Applications on Mac OS X may need to be concerned with this property if they are sending a large number of UDP packets in a short timeframe.
On Windows, calls to the BeginSendToGroup or BeginSendTo methods will take longer to call the callback depending on the value of the SendBufferSize property if the send buffer is full. The SendBufferSize property only controls whether the user's buffer stays locked in physical memory until the send completes.” - MSDN on UdpAnySourceMulticastClient.SendBufferSize Property
With the UdpAnySourceMulticastClient.SendBufferSize Property we can see some wildly divergent networking behaviour between Windows and Mac.
This should cause developers to revaluate how you use the SendBufferSize property, and BeginSendTo & BeginSendToGroup methods.
Difference #3: Different source for HighContrast mode
Category: Different O/S UX
“On computers that run Windows, the HighContrast property is true when the user has enabled High Contrast in Control Panel. On Macintosh computers, HighContrast is true when the user has selected the White on Black option in Universal Access.” - MSDN
It’s important to note that Macs do not have a “High Contrast” mode but rather they have a “Black on white” mode.
When providing instructions to end-users on how to enable HighContrast mode for an application, it’s important to remember these differences.
Difference #4: Different Exception details
Category: Debugging
“There are known issues with reported line offsets when a XamlParseException occurs on a Macintosh client. Line numbers/positions on other clients are more accurate.” – MSDN
When debugging on a Mac or when users are sending application error reports, developers might see the XamlParseException.
However, if the exception arises from a Macintosh the Line number and Column positions might be all wrong.
Difference #5: HtmlPage.Window doesn’t equal itself
Category: Coding difference
- MSDN
When comparing HtmlPage.Window to itself, there are different results on a Windows machine and on a Mac machine.
Difference #6: MessageBox will always have an Icon
Category: UX Difference
“The message box may have a slightly different appearance on different platforms. For example, the message box includes an icon when it is displayed on a Macintosh.” – MSDN
Based on this MSDN excerpt even when invoking MessageBox.Show even without an Icon, Mac will always display an Icon.
While Windows machines will not show any icon.
This may be an important difference for applications when visual consistency is an important factor.
Difference #7: Cross-Zone networking security restrictions
Category: Security Restriction Differences.
“Cross-zone URL: Internet Explorer defines the concept of security zones with a security level assigned to each zone. Four zones are defined: Internet, Local intranet, Trusted sites, and Restricted sites. In addition, the local machine is also considered to be another zone. A Silverlight application downloaded from a web server in one security zone tries to access resources on a target server in a different security zone. Cross-zone access restrictions are designed to prevent a Silverlight application downloaded from a server in the Internet zone from accessing resources in the more trusted Local Intranet, Trusted Sites, and local machine zones. This prevents a Silverlight application run from a remote internet server from getting access to resources on the local intranet and other resources (an elevation of privilege). Cross-zone access is blocked even if a security policy file on the target server would allow the resource to be accessed. Note that cross-zone access is not restricted for applications downloaded from the server in the Local intranet zone to resources on an internet server. However, any access cross-domain requires a security policy file. Cross-zone access restrictions are implemented only for Silverlight 2 and later applications running on Windows.
The concept of security zones and cross-zone access is not currently supported for Silverlight applications running on the Apple OS X.” – MSDN
There are 2 types of Cross-X networking restrictions:
1) Cross-Domain: The famous restrictions developers know and love from clientaccesspolicy.xml. Based on a comparison of site-of-origin and the location of the remote networking resource.
2) Cross-Zone: A restriction based on the zone-of-origin (internet, intranet, trust or local) an application was downloaded from and which zone a network resource is located in.
While Cross-Zone is less familiar to most of us, it is by no means less important.
However, on a Mac the cross-zone restrictions don’t take place, either by being fully blocked or by being fully allowed.
- MSDN
The above chart illustrates rather effectively which cross-zone interactions are allowed on Windows Machine. But as MSDN says, that is not the case for Mac.
If an application uses Cross-Zone networking it is important to make sure those work in a Macintosh environment.
Difference #8: Silverlight 4 Drag & Drop
Category: Coding Difference, Missing Feature on Mac
“To handle drag-and-drop events for applications hosted by Safari browser on the Macintosh, you must forward the relevant HTML DOM events to the specific handler in Silverlight” – MSDN
When implementing code that handles the new Silverlight 4 Drop/DragX event sit is important to know that the events will not fire on Mac by default.
There is special HTML & Javascript code that needs to be included to assure that Silverlight 4 Drop support in enabled on a mac.
“The forwarding technique described for Safari might not work for Firefox.” - MSDN
However, even with this change Silverlight 4 Drop support might not work on Macintosh FireFox.
Difference #9: Uris
Category: Coding Difference
- MSDN
It is vitally important to know that when doing any parsing work with the Uri Class, it’s properties will behave differently on different operating systems.
Difference #10: BCL classes
Category: Coding differences
The following table lists out some common Base Class Library differences between Windows and Macintosh:
- MSDN
Difference #11: Exiting Full Screen Keystrokes
Category: UX difference
“A Silverlight plug-in that is in full-screen mode can return to embedded mode in several ways. The simplest way to leave full-screen mode is for the user to enter a keystroke or keystroke combination:
Windows users should press ESC or ALT+F4.
Macintosh users should press ESC.” – MSDN
When exiting full-screen mode back to normal browsing mode, the “Alt + F4” keystroke combination will only work in Windows.
If an application provides guidance for users on how to exit full-screen mode, it might be best to limit it to “Press ‘Esc’ to exit full screen mode” or some such similar message.
Users who have previously used the ALT+F4 combination on the application when running on Windows, could be somewhat confused to see it’s disabled on a Mac.
Difference #12: Silverlight 4 COM Automation
Category: Missing Feature on Mac
“Trusted applications can integrate with native functionality that differs depending on the host operating system. For example, on Windows, trusted applications can interoperate with Automation APIs through the AutomationFactory class.” - MSDN
The new Silverlight 4 Operating System Automation features are currently only enabled on Windows.
While going from Silverlight 4 Beta and Silverlight 4 RC the class has been renamed from “ComAutomationFactory” to “AutomationFactory”. Signalling that Macintosh might be supported for this feature in the future.
Either way, as of Silverlight 4 RC there appears to be no way to use the multitude of features offered by Silverlight 4 Automation on a Mac.
“A ha! A Microsoft Conspiracy!”
At this point some of you might be thinking to yourself “ah ha! A microsoft conspiracy! I have proof!” or some such nonsense. That’s wrong, cut it out.
These same differences would realistically have to exist in one form or another in other RIA platforms such as Flash and JavaFX.
A common trend amongst all the differences we’ve surveyed in this article is that they’re all to do with deep Operating System Integration or Browser Integration. These are either issues with the operating system or the browser itself.
Remember that .Net at it’s core is just a framework abstraction on top of the O/S.
And as anyone who’s ever written a framework knows, some differences cannot be abstracted away.
In my opinion, a lot of these differences are issues that at the end of the day just requires developers to be alert.
Most of these differences aren’t in the Silverlight UI rendering itself, but more towards O/S integration or Browser integration.
Be aware of these issues and work to avoid them.
What can Microsoft do? Option #1 - Developer Education
I have yet to see a Silverlight presentation that mentions that there are differences between Silverlight on Windows and Silverlight on a Mac.
It always saddens me to see YetAnotherConference(TM) that doesn’t mention this topic at all.
Maybe there could be a PDC/Mix/DevDays/WhateverConference session called “Silverlight differences between Windows and Mac”?
While it’s definitely not in anyone’s best interest to point out Silverlight isn’t fully cross-platform, it’s better to educate developers then pretend it is.
Another good avenue for developer education is through MSDN articles.
While there is a MSDN article titled Silverlight Differences on Windows and the Macintosh it is minimal and does not contain most examples found elsewhere on MSDN and others that must surely exist. It is imperative that Microsoft properly documents these non Cross-Platform issues in a central location.
What can Microsoft do? Option #2 - Visual Studio Warnings
Another more proactive route Microsoft might choose to follow on this issue, is to encapsulate all of the Cross-Platform differences into FxCop / Code Analysis rules.
Those rules would execute whenever a developer builds an application and would provide immediate feedback on code that might behave differently on various platforms.
Creating such Build Warnings appears to be an integral part missing from the Silverlight developer experience.
The mono team might even choose to do the same in order to help developers build truly cross-platform applications.
What should developers do? Option #1 – Educate ourselves
There’s nothing wrong with saying “I’m not familiar with this topic” and reading about it.
If up until you’ve read this article you’ve thought Silverlight is 100% cross-platform, maybe your colleagues do to?
What should developers do? Option #2 – Report bugs to Microsoft
If you come across other issues/bugs that break cross-platform behaviour in Silverlight, make sure to report it to Microsoft.
The “Connect” system allows you to report bugs to microsoft and follow up to make sure they’re fixed.
Report bugs on Connect @ http://tinyurl.com/SilverlightBug
What should developers do? Option #3 – Automated Nightly Tests
Writing tests and running them on nightly on both Windows and Macintosh is a recommended practice.
There’s quite a bit of infrastructure work involved, and if you don’t know how to test there’s a steep learning curve.
But having automated tests that execute nightly is the best thing we can do to help ourselves spot these issues early.
If you’re not familiar with Silverlight Unit Testing I’d suggest the following article @ SILVERLIGHT UNIT TESTING, RHINOMOCKS, UNITY AND RESHARPER.
Statlight is a dedicated Silverlight Unit Testing Automation tool by Jason Jarrett that also comes in very handy when automating Silverlight Tests @ http://statlight.codeplex.com/
As of November 2009 it is possible to execute Silverlight Unit Tests from the command line prompt, see Jeff Wilcox’s post @ Walkthrough: The power of the November 2009 Silverlight Toolkit testing tools
Fin
In this article we’ve talked about the common misconception that Silverlight is fully Cross-Platform.
We’ve seen many examples from MSDN that clearly state Silverlight is not fully Cross-Platform.
And we’ve gone over what we as Developers should do to overcome this issue, and what Microsoft can do to help.
I’d love to hear your thoughts in the Comments on this issue.
I’d also like to thank David Gadd, Chris Walsh and Kelly White for providing feedback on this article before it was published.
Sincerely,
-- Justin Angel
Comments