Silverlight On the Way To Linux

Afforess writes "For the past two years Microsoft and Novell have been working on the 'Moonlight' project. It is a runtime library for websites that run Silverlight. It should allow PCs running Linux to view sites that use Siverlight. Betanews reports 'In the next stage of what has turned out to be a more successful project than even its creators envisioned, the public beta of Moonlight — a runtime library for Linux supporting sites that expect Silverlight — is expected within days.' Moonlight 2.0 is already in the works."

Comments

there's one thing I'll stay clear of

[jacquesm]

Standards anybody ?

I still think there should be a new standard that would obviate the need for flash, you can keep your silverlight and shove it.

Re:Why Is Porting Needed?

[cnettel]

A few things: you cannot write a (Mozilla) browser plugin all in managed code, there is simply no interface. You at least need a bridge. Silverlight is also related to WPF/Avalon, which has a native component on Windows. Most importantly, though: Silverlight is not open source. Moonlight is. It is not a port, it is a sanctioned, but independent, rewrite, which is also related to advances in the Mono support for quite a few things that weren't there 2 years ago.

No printing support

[javilon]

If we are looking at silverlight as a flash replacement, it is just a flash clone with no market share, so that makes it a non starter. Also, flash comes installed by default this days on every operating system and browser. Silverlight doesn't. That is enough of a show stopper on itself.

If on the other hand, we are looking at it as a way to code the client side of business apps with a rich interface using a strongly typed, compiled language, it could have some potential, except for one thing. No printing support. Printing support is essential for business apps and Silverlight doesn't provide it, at all.

Re:What a surprise... backhanded support

[cyberjessy]

A bit of history. Silverlight 1 is a joke as a product, Silverlight 2.0 is the real deal. To start with, Silverlight 1 does not have the CLR (.Net runtime), it was pretty much useless for anything complex. Even back when v1 was released, companies (and Microsoft itself) were releasing all the cool stuff in v2.0 alpha.

So mono never really had to chase v1, which had zero chances of succeeding. Which is probably why Mono is still at v1. However, getting v2.0 running would not be too difficult. It is mostly a scaled down .Net runtime, with some multimedia added.

And if you have ever used Mono, you would notice that they have a remarkably complete implementation of .Net, with compilers compatible with the newest from Microsoft.

Re:What a surprise... backhanded support

[YttriumOxide]

Well, if you're still "learning" C#, then there's a good chance that 99.9% of what you're writing will already run flawlessly under mono. It's not until you start doing a lot of tricky and OS specific things that compatibility breaks. Simple thing to do: Download the VMWare image of Suse with Mono installed (or install Mono yourself on a Linux or Mac system) and then just try to run your compiled .NET apps directly. There really isn't much more to it than that.

Tips for maintaining cross platform compatibility in general:

• Avoid using hardcoded paths - System.Environment.GetFolderPath(System.Environment.SpecialFolder.foo) is useful
• Along the same lines, avoid using hardcoded slash or backslash when dealing with paths - System.IO.Path.DirectorySeparatorChar should be used instead
• Avoid using the Windows registry, Microsoft.Win32.Registry (or anything in the " Microsoft " namespace for that matter)
• (obviously) avoid calling native platform libraries - stick to pure .NET (things designed around a specific platform but "usable" on other platforms such as UI stuff (like System.Windows.Forms or GTK#) are okay, but it's good to keep those parts of your code as separate as possible from the "meat" of the program so it is easier to replace them later for a more native feel if you want to)
• If using System.Windows.Forms for your UI (i.e. anything you build in the Visual Studio designer bit), keep your Windows controls as "standard" as possible (drag/drop/edit properties) - don't use too much custom stuff (controls you've designed yourself, or highly modified forms of existing controls), since that tends to look worse on other platforms.