As a very happy Rhapsody customer, the news that Rhapsody will start selling DRM-less music at 0.89 cents a pop is ubertastic.

If I was European or Canadian I would be 30% more excited -- considering the falling dollar.

I have been using it mostly as a radio so far, and avoided purchasing music because it would be DRMed, but there are a bunch of titles that I would like to own.

Let the double-click all-amateur shopping begin!

A few years ago we met Rafi at one of our Mono summits in Boston, he works for Mainsoft and he has always been amazing.

Watch his interview on what he is doing with Grasshopper here and here.

He talks about Mainsoft's contributions to Mono, about his testing procedures and the kind of things that are possible with Grasshopper when integrating ASP.NET applications when running on J2EE servers.

As you may or may not know, the Mono team is in the process of switching from the Ximian Bugzilla to the Novell Bugzilla. The Ximian Bugzilla installation is a very old, patched, modified, buggy and unmaintained version of Bugzilla. The Novell Bugzilla team has offered to take over the maintenance of Bugzilla and give us both a modern Bugzilla installation and access to various tools that will help our process.

As part of this process we need everyone to create Novell.Com accounts.

When creating your Novell.Com account, please make sure to use the same e-mail address that you use to login to the Ximian Bugzilla. This will ensure that your Bugzilla configuration stays the same.

Please create your Novell.Com account now, so that you will be able to immediately access the Novell Bugzilla when we do the final switchover.

To create a Novell.Com account, please go to this URL and fill out the form: here

Important: To link your existing bugs from bugzilla.ximian.com to the new bugzilla make sure that you use the same email address in that form so you can keep tracking the bugs that we had for you before.

We appreciate all of the contributions that you have made to mono in the Ximian Bugzilla and hope that you will continue to contribute in the Novell Bugzilla.

Given Toshok's initial reaction to the lack of JSon support in Silverlight last night:

He decided to do something about it.

Silverlight is "webby" in that you can use plain text files and you can generate its content from PHP or any other webby framework by using the mighty print statement.

But XAML is annoying to type, it is webby, but its not uber-webby. It would be nice if Silverlight supported incarnation from JSon instead of incarnation from XAML, for one, it is more wrist friendly than XAML and it also a lot nicer on the eyes.

This morning Chris implemented a JSon to XAML. See his blog post.

This is done with a Javascript program, so it will work with your stock Silverlight installation.

It would be much nicer if Silverlight's Control class had a CreateFromJson in addition to CreateFromXaml.

See Chris post on the subject. You can now use syntax like this for Silverlight:

	
var json = {
  Canvas: {
    name: "Toplevel Canvas",    children: {
      TextBlock: {
        Text: "Hello World"
      }
    }
  }
}
	

Silverlight comes with a shrunk down version of the CLR called the CoreCLR and also comes with a reduced version of the core class libraries.

Silverlight uses a subset of the 2.0 API and removes a lot of stuff that would only be used on a desktop or a server and removes overloads that people are not likely going to use and according to some blog posts even things like System.Collections will be removed giving preference to the generics-based API in System.Collections.Generic.

Nice graphic showing my Inkscape skills:

To support this "thin" profile in Moonlight we had a couple of choices.

We really did not want to branch our source code and chop code left and right until we removed all the extra baggage. We also did not want to use compilation defines because that would get ugly very fast.

Instead what we did was productize Linker tool that was developed as part of the Google Summer of Code last year.

The Linker could take an assembly and a description of the desired API entry points and produce a new assembly that only contains the requested entry points plus any of its dependencies. Although the Linker from last year was able to do some basic linking, but as with all software projects, the devil is on the details. JB has been working on productizing the tool ever since he joined Novell back in May.

The idea was that we would feed the linker a superset of our 2.0 library (2.0 plus the handful of Silverlight-esque APIs) plus a linker description file, and it would produce the resulting Silverlight compatible assembly.

The above approach allowed us to minimize the number of ifdefs that were required in the source code. In addition to the linking stage we also needed a way of inject a number of security attributes (again to avoid having a mess of ifdefs everywhere).

So JB created new specialized tool that allows us to add, remove and validate assemblies. We call this the Tuner. Both the linker and the tuner are based on Cecil a library for handling CIL files.

The tuner can do most of the heavy lifting, but there are a couple of areas that still required human intervention:

• In a handful of cases abstract methods are no longer exposed in Silverlight, we had to work around this directly (XmlReader).
• In a few cases there are some interfaces and class hierarchy changes required, those also had to be done manually.

Finally, since our C# compiler depends very strongly on its mscorlib (the reason we have 3 compilers today, one for each profile is linked precisely to this dependency on mscorlib) we had to add special support to the VM to allow the compiler to call into methods that we had hidden as part of the tuning process.

This afternoon for the first time JB was able to build the 2.1 profile from the start up to the Silverlight support libraries and the Silverlight plugin with the tuned assemblies.

Although we have been debugging Moonlight with 2.0 assemblies for the past few months due to some of the API changes some applications like the SimpleXPSViewer did not work.

There is still some work left to do as you can see from the warnings generated by the tuner, but we are getting there.

Silverlight Toolkit

With the 2.1 profile in place it is now possible for people on Linux and MacOS to develop Silverlight applications without using Windows.

The bad news is that the 2.1 profile will not be available in Mono's 1.2.5 release as we branched that release a few weeks ago. So developers interested in doing Silverlight development on Linux or MacOS will have to wait until our 1.2.6 release in a couple of months.

In the meantime Ankit has added support to MonoDevelop for compiling existing Silverlight VS Solutions as well as generating Unix makefiles from the VS solution file. You must be using an SVN release of MonoDevelop (sadly, 0.15 wont do it). for this to work though:

bash$ mdtool generate-makefiles SilverlightAirlines.sln --simple-makefiles
Creating configure script
Creating rules.make
Creating Makefile.include
Adding variables to top-level Makefile
Makefiles were successfully generated.
bash$ 	
	

The default is to generate auto-tools based makefiles. It is recommended that people with acid reflux, ulcers or other delicate stomach conditions use the --simple-makefiles option. --simple-makefiles produces a configure and Makefile script that are essentially the labor of love.

If we can sort out the license for the Silverlight.js template, we should also be able to ship MonoDevelop templates for creating Silverlight content.

Chris Toshok and myself will be in Microsoft offices in Redmond, WA from Monday to Wednesday next week. Email or post in the comments if you are interested in doing some kind of get together/dinner.

In related news, Jackson posted a screenshot of Silverlight Scribbler running on Moonlight on his blog:

Jackson and Sebastien also got parsing of XAML bezier paths working just in time for the June 21st demo, I like this screenshot:

An important component of Silverlight is a simplified security system for protecting what can be done and what can not be done by user code.

.NET 1.x and 2.x have a system called the "Code Access Security" (CAS) which Mono has never completely implemented since it there are very few applications that actually took advantage of it (Update: On the comments someone points out that CAS is fundamental for any uses of ClickOnce deployment; Mono has no support for ClickOnce deployment either). This is probably due to its complexity, which leads to people not trying it out in the first place.

With Silverlight it becomes very important to ensure that we can execute code in a secure fashion and without allowing malicious code to get access to any resources on the system. Code that is downloaded and executed inside Silverlight/Moonlight needs to be sandboxed.

This new security system is described in a few blog entries from Shawn Farkas:

• The Silverlight Security Model
• Silverlight Security II: What Makes a Method Critical
• Silverlight Security III: Inheritance

Today Mark posted his first implementation of this new security system for Mono for use in Moonlight:

Here's a preliminary patch for CoreCLR security, including a small patch for System.Security. It should do pretty much everything with the exception of catching method calls via reflection (I'm not sure how this is handles in Silverlight yet, and Silverlight on my Windows machine doesn't like me anymore - grr). I've included a small C# test program which tries out all the different ways (of which I'm aware) to call a method. That'll become a regression test eventually.

If mono is called with "--security=core-clr" then security attributes are only honored in system assemblies (those in $(PREFIX)/lib/mono/2.1) - other assemblies are always security transparent. To do better testing there's also an option "--security=core-clr-test" which honors security attributes in all assemblies.

Comments are welcome.

In addition to the new CoreCLR security system, the needs of Silverlight have finally pushed us to implement the code verifier in Mono. This is currently under development by Rodrigo.

CoreCLR is very similar to the design that Jim Pubrick has prototyped for SecondLife. Hopefully Jim can switch to the CoreCLR security system. Some of the needs for sandboxing that folks like SecondLife have (execution of untrusted code) can be found in our MonoSandbox page.

This is a great summary of how the security system works, from Shawn Farkas:

Over the last week we took a look at the new Silverlight security model. When you're writing a Silverlight application though, there's a lot of information there that you may not want to wade through to get yourself unblocked.  Here's a quick cheat sheet highlighting the important points that you'll need to know when working with the Silverlight security model:

• All applications written for Silverlight are security transparent.  This means that they cannot: [details]
  • Contain unverifiable code
  • Call native code directly
• Silverlight applications can access public methods exposed by platform assemblies which are either: [details]
  • Security transparent (neither the defining type nor the method has any security attributes)
  • Security safe critical (the method has a SecuritySafeCriticalAttribute)
• Silverlight applications may contain types which derive from: [details]
  • Other types defined in the application
  • Unsealed, public, security transparent types and interfaces defined by the platform
• Silverlight applications may contain types which override virtual methods and implements interface methods which are: [details]
  • Defined in the application itself
  • Defined by the platform and are transparent or safe critical

Early this morning Jackson got the Silverlight Chess program working on Mono's Moonlight:

This demo did not work for a while as it requires that the x:Name declarations from controls created dynamically be merged with the container namescope.

Between Chris and Jackson the javascript bridge is complete enough that a few hours later (after fixing a double free) it is now possible to have the Mono VM play against the browser Javascript in Firefox/Linux as well:

Although the original plans were to only support Silverlight 1.1 because we thought that they would be very different runtime, it turns out that by supporting 1.1 we can also support 1.0.

Various 1.0 demos are working with our implementation as well. The limitations currently are more with our overall support than in a 1.0 vs 1.1 difference.

Speed

Testing the Chess on Windows vs MacOS on relatively similar hardware seems to give an edge to Windows (as I do not have any two identical machines to compare, it just feels like the Windows box is performing about twice as fast).

Am interested in finding out from folks that have similar hardware if there is any significant performance difference in the CoreCLR implementations between OSX and Windows.

The second screenshot is Mono running on a ThinkPad T60P ([email protected]) am curious if someone with Windows with the same machine can report on the .NET vs Javascript nodes/sec.

I was reading a comparison between Adobe's Tamarin JIT and Sun's HotSpot and there was some discussion started by Chris:

Maybe, I'm missing something, but I really don't see why Mozilla doesn't build on the Java platform rather than Tamarin. Investing effort in writing a full ECMAScript 3 or 4 translator to JVM byte-code seems like an easier and faster way to get much better results than Tamarin.

To which one of Brendan Eich's replies was:

We don't depend on closed source in-process code, period. I've also mentioned the license requirements, not that it mattered due to the lateness of Java's open source transition (GPL alone is not ok).

I ran the same program that was posted there on Mono, and extrapolating the values (my machine is faster than Chris, but am using Java HotSpot 1.6):

• Tamarin: 58 second
• Rhino JS engine: 31.944 seconds;
• Mono: 10 seconds;
• HotSpot: 2.23 seconds

Someone on the thread pointed out that using type annotations might bring Tamarin to 11 seconds. Update: , but Chris was not able to replicate that behavior..

It is clear that Mono's floating point performance is far from ideal. Currently Mono on x86-32 platforms is still using the x87 "stack" style of floating point operations as opposed to the more efficient XMM style of code generation that we used on x86-64. We should look into this.

Update: Mike ran the tests on x86-64 where Mono has a different floating point implementation and the results are promising, instead of being 4 times slower than Java in this test Mono is only 2 times slower.

That being said, for Mozilla purposes, it seems that using Mono as their JIT instead of Tamarin would be a better choice:

• Mono can be shrunk down to 5 megs by picking files (uncompressed) and even more if you are willing to ifdef stuff.
• Mono's VM is licensed under the LGPL.
• Mono runs IronPython, IronRuby and the DLR out of the box, no need to modify either one of them.
• Mono already supports more platforms than Tamarin (and I believe we support more than Sun's JVM).

Planning-wise its probably too late to use Mono on Mozilla, which is a shame.

It might still be interesting to prototype using Mono + Rhyno as a Javascript engine or completing the DLR-based Javascript and see how fast it can get.

This could probably be prototyped on WebKit/Gtk easily.

There is some kind of bug in Mono's implementation of Silverlight that is causing ZeroGravity to claim that I have won:

But at least Aaron's favorite music is playing in the background.

In other news, Chris just got Silverpad Pad working with the refreshed version of Silverlight:

And Silverlight Airlines from the 1.1 Refresh: