Compartir a través de


Silverlight Differences on Windows and Macintosh

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Although Silverlight is generally a cross-platform solution, there are some basic architectural differences between Microsoft Windows and Macintosh that you should be aware of as a Silverlight developer.

Functional Differences

Windowed Mode

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.

Input Events

Various input events have different behaviors depending on the platform. For example, some of the behavior differences are because of physical or logical differences in the input devices. Other differences are due to the differences in the plug-in hosting layers for the browser.

Silverlight has support for right-click input events, through the MouseRightButtonDown and MouseRightButtonUp events. Some current mouse devices or related devices for Macintosh do have a physical right mouse button. Even in cases where there is no physical button, Macintosh users can use various hardware or software input techniques that result in a right-click input event for application listeners. Silverlight processes this input as a right-click and raises the MouseRightButtonDown and MouseRightButtonUp events.

Some current mouse devices for Macintosh have a physical or virtual mouse wheel. However, the program access layer used by Silverlight on Macintosh does not support forwarding the mousewheel event to Silverlight in a browser-hosted situation. You can handle the Silverlight MouseWheel event from a Macintosh platform client, if the Silverlight application is running out-of-browser. Otherwise, consider handling mousewheel events for Macintosh platform at the HTML DOM level; for more information, see Platform Dependencies.

NoteNote:

If you are handling keyboard input (such as with the KeyDown and KeyUp events) and process cases with modifier keys, you should be aware that the Control key on Macintosh could be pressed to produce the right-click equivalent.

For general keyboard handling, there are two sets of keys. There is a set of keys that is a common between all supported platforms and another set that varies by platform. A platform key is reported as a PlatformKeyCode. Modifier keys (obtained through the Keyboard.Modifiers property) might vary per platform. For more information about the PlatformKeyCode property and key handling, see Keyboard Support.

Silverlight supports dragging a file list "payload" from outside the Silverlight plug-in into a targeted element in the Silverlight content area. This feature is exposed through input events, such as the Drop event on the UIElement class. Because of limitations in Safari's input model for hosted plug-ins, you can only enable this feature on Safari through an HTML scripting workaround/shim. You cannot enable this feature on Firefox. For more information, see Handling Drag-and-Drop Events for Macintosh

Networking

Silverlight uses different socket implementations on Microsoft Windows versus Macintosh. This can result in behavior differences that are noted in the individual API reference pages in namespaces such as System.Windows.Sockets. For more information, see Working with Sockets.

Out-of-Browser Applications

Out-of-browser applications generally run identically in Windows and Macintosh excepting any of the other issues noted in this topic. However, the platforms require different uninstall steps to be taken by users. On Windows, users uninstall an application by using Programs and Features in Control Panel. Alternately, users can right-click the application and select the uninstall option. On Macintosh, users uninstall an application by dragging it to the trash bin.

Trusted applications can integrate with native functionality that differs depending on the host operating system. For example, on Microsoft Windows platforms, trusted applications can interoperate with Automation APIs through the AutomationFactory class.

Certain other out-of-browser features might differ very slightly on the Macintosh, due to reliance on the Macintosh system. For example, the underlying implementation of WebBrowser uses different HTML components on Macintosh than on Microsoft Windows. Thus the HTML in WebBrowser is rendered by different useragents on each platform. There can be subtle differences in the appearance of the rendered HTML, due to conventional HTML issues such as how each browser handles CSS.

Debugging

You can debug Silverlight-based applications on Macintosh computers by establishing a remote debugging session from a computer that is running Microsoft Windows with Visual Studio installed. For more information, see Walkthrough: Setting Up Remote Debugging on the Macintosh.

Differences in CLR Library API Behavior

The following table lists differences in behavior in .NET Framework class library types and methods when a Silverlight-based application executes on Microsoft Windows and on Macintosh.

.NET Framework feature

Windows behavior

Macintosh behavior

Char.ToLower(Char, CultureInfo)

Converts a Char to lowercase using the conventions of the specified culture.

On Mac OS v10.4 and earlier versions, converts a Char to lowercase using the conventions of the current culture.

Char.ToUpper(Char, CultureInfo)

Converts a Char to uppercase using the conventions of the specified culture.

On Mac OS v10.4 and earlier versions, converts a Char to uppercase using the conventions of the current culture.

Decimal.ToString

Returns a string representation that is consistent with other integral types.

Because the Decimal data type is not supported, the string representation of a Decimal value may be different from the string representations of the other .NET Framework numeric types that are supported by Mac OS X.

Double.NegativeInfinity.ToString

Returns the string -Infinity.

Returns the infinity symbol preceded by a negative sign (-∞).

Double.PositiveInfinity.ToString

Returns the string Infinity.

Returns the infinity symbol (∞).

Single.NegativeInfinity.ToString

Returns the string -Infinity.

Returns the infinity symbol preceded by a negative sign (-∞).

Single.PositiveInfinity.ToString

Returns the string Infinity.

Returns the infinity symbol (∞).

Single.ToString

Returns a string representation that is consistent with other floating-point types.

Because the Single data type is not supported, the string representation of a Single value may be different from the string representations of the other .NET Framework numeric types that are supported by Mac OS X.

UInt16.ToString

Returns a string representation that is consistent with other integral types.

Because the UInt16 data type is not supported, the string representation of a UInt16 value may be different from the string representations of the other .NET Framework numeric types that are supported by Mac OS X.

UInt32.ToString

Returns a string representation that is consistent with other integral types.

Because the UInt32 data type is not supported, the string representation of a UInt32 value may be different from the string representations of the other .NET Framework numeric types that are supported by Mac OS X.

UInt64.ToString

Returns a string representation that is consistent with other integral types.

Because the UInt64 data type is not supported, the string representation of a UInt64 value may be different from the string representations of the other .NET Framework numeric types that are supported by Mac OS X.

System.Globalization.CultureInfo properties

CultureInfo objects other than CultureInfo.InvariantCulture retrieve their data from Windows. The value of a particular culture's properties may even vary within versions of Windows.

CultureInfo objects other than CultureInfo.InvariantCulture retrieve their data from Mac OS X. The value of a particular culture's properties may even vary within versions of Mac OS X.

CultureInfo.CultureInfo constructor

If the name parameter does not identify a valid culture, the constructor throws an ArgumentException.

If the name parameter does not identify a valid culture, the constructor returns a reference to the current culture.

CultureInfo.DisplayName

CultureInfo.EnglishName

CultureInfo.Name

CultureInfo.NativeName

Because information about culture names is retrieved from Windows, the value of these properties may vary by versions of Windows.

Because information about culture names is retrieved from Mac OS X, the value of these properties may vary by versions of Mac OS X.

TextInfo.ListSeparator

Returns a string that is defined by the CultureInfo object.

Always returns a comma (,) regardless of the culture.

System.Windows.Controls.SaveFileDialog

If the user tries to name a file using invalid characters, such as ">", "<", or "|", then a window popup is displayed with an error message "The file name is not valid."

If the user tries to name a file using invalid characters, such as ">", "<", or "|", then a System.ArgumentException exception is thrown with the message "Illegal characters in path."

Uri parsing

Can fully parse UNC paths.

UNC path parsing converts to forward slashes, which can result in incorrect values in the individual Uri properties. For more information, see AbsolutePath.