We just released Mono 1.1.10,
our best release so far. The major feature missing from this
release to call it Mono 1.2 is the completion of our
Windows.Forms implementation.
Miguel de Icaza
[email protected]
We just released Mono 1.1.10,
our best release so far. The major feature missing from this
release to call it Mono 1.2 is the completion of our
Windows.Forms implementation.
In this document I only present the direction of development of the Mono team at Novell; A more comprehensive view of other Mono developments by the Mono community is something that am working on and will post at a later date.
I also present how our team's priorities are shifting in response to Novell's own internal use of Mono and external factors like the final release of .NET 2.0.
Since the Mono 1.1.xx series has got a significant amount of fixes over 1.0.xx we have encouraged users and developers to move to the Mono 1.1.xx series.
To avoid regressions we have done a number of things:
We have used this separate branch development for the new string collation framework, the ASP.NET implementation, the new cross platform register allocator and the Cairo 1.0 migration. And we currently do the same for our VM optimizations, the precise garbage collector work and the C# 2.0 compiler.
The basic idea is that we turned the 1.1.xx series into a release that can be deployed on production as opposed to merely a development release. This is similar in spirit to the kernel 2.6.xx releases.
As a general rule we try to fix bugs before we write new features.
For details on what has been done in the 1.1.xx development cycle, please see the release notes for each of the releases: 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.1.8, 1.1.9 and 1.1.10.
Windows.Forms is the only piece that is holding us from officially renaming Mono to Mono 1.2, it is still missing a few features. Our plan is to complete the missing features by the end of this month and then move to bug fixing and testing open source our publicly accessible Windows.Forms applications. We are planning on spending three months on bug fixing at this point.
Our aim with Mono 1.2 is to release a Windows.Forms implementation that implements the .NET 1.1 API, not the 2.0 API.
These are the most visible missing bits from feature completion:
Our Windows.Forms implementation is implemented on top of the GDI+ API for rendering and a relatively small driver to interact with the host windowing system. Our GDI+ implementation on Unix (Linux and OSX) uses Cairo as the rendering engine. As for the windowing system drivers, today we have two complete drivers (Unix/X11 and Win32) and one driver under development (OSX).
Some minor features missing are:
There are a number of features that we have explicitly postponed from this release and will only make it into 1.2 if they are contributed by external contributors, otherwise they will have to wait for Mono 2.0:
Our WinForms page tracks the progress.
We started work on the foundation for 2.0 in mid-2003 as soon as the early drafts of the new changes were submitted to ECMA. This gave us plenty of time to work on our C# 2.0 compiler and the changes to our VM to support generics. Today they are both considered feature complete.
Our IL assembler and IL disassembler are almost complete and should be able to roundtrip our generics-based libraries soon.
The core is complete enough that the latest versions of IronPython and Nermerle work with it.
Developers are starting to use the new features available in 2.0 and they have started to file bugs against our runtime and compiler.
So far our policy was that we supported the 1.1 profile for the libraries. The 2.0 profile is being developed but is only supported in the "if it breaks, you get to keep both pieces" modality. Bugs on the 2.0 support in the compiler and runtime were routinely fixed.
With the release of .NET 2.0 we are shifting some of our development efforts to work on the most important areas of the 2.0 profile.
We are hoping to include the most important bits of the profile in the upcoming release of Mono 1.2, but we are not making any promises about the completeness of the 2.0 APIs. Mono 1.2 will release when Windows.Forms is complete.
The System.Xml 2 is pretty complete, mscorlib and System assemblies still require significant amounts of work.
See also the ASP.NET section for details on the progress in that area.
Martin has been working on our debugger. Today it is capable of debugging 1.x applications (2.0 should be supported as soon as Cecil support for generics is completed).
To test the debugger today you must use SVN versions of Mono as well as the debugger as it is still rapidly changing.
We are now accepting feedback on the debugger: limitations and interface. Since it currently only works as a command line debugger you might want to read the debugger guide in our web site.
If you find problems with the debugger, please file a file a bug report.
Lluis has
moved from working on ASP.NET 2.0 to work on the MonoDevelop
IDE.
Our most important goal with MonoDevelop is to make it rock solid and eliminate every crashing bug that has been reported.
As for the features, MonoDevelop now sports a plugin architecture similar to Eclipse: components can be downloaded and installed without having to recompile the application (see here).
Integration of a GUI designer is progressing (currently Glade3, but we hope to replace it with Stetic when it becomes available).
Finally as the debugger interface stabilizes we plan on enabling the debugger interface in MonoDevelop again.
During the last year the Mono JIT has been ported to three new architectures (x86-64, Itanium and Arm processors) in addition to the platforms it supported before (x86, PowerPC, SPARC, SPARC 64 bits and S390).
At this point the Novell team does not have any plans to work on new ports. Although some members of the community have expressed their interest in adding S390x and MIPS support to Mono.
Paolo has been working on a new garbage collector (GC)
engine. Currently Mono GC interface is almost pluggable (the
work to plug different GCs was done a few months ago).
The new GC engine is a precise, generational, compacting collector. This means that the Mono GC will be able to return memory to the operating system when it no longer needs it.
We are making a few tradeoffs to ship this version of the collector quickly. For instance this new GC will treat the stack conservatively has two effects: it makes it easy for embedders of Mono to use the new GC but it also might flag a lot of pinned objects.
We hope that the new GC can be tested in February or March, the code will start landing in December.
We have been working for quite some time on various new code optimizations. The code is getting ready to be submitted to the main Mono repository. Over the next few weeks expect various patches to be posted.
Currently we are working on the following areas to improve the performance of the generated code
Massi has recently posted his Fast Dead Code Elimination and he described it on this blog post.
Massi has also been working on our HSSA-based framework and dead code elimination based on it. This optimization should be posted for review to the mailing list this week.
Once those two are done, Massi is going to work towards making FastDCE + CopyProp + Inlining be part of the default optimizations for Mono which will bring some immediate visible results.
After this our plans for HSSA are:
The quality of the code might suffer because removing redundant code introduces new temporary variables. To fix this we need a feedback mechanism to the register allocator that does not exist today.
To address the previous (and other problems) Zoltan is
starting work to eliminate the tree-based IR from Mono.
The C# compiler comes in two editions:
Our gmcs compiler support as of November 2005 is known to lack one feature: the late changes to nullable types in the specification. Other than that the compiler is considered feature complete.
As the C# compiler is at the core of much of our work we will continue to focus on bug fixes. The recent C# 3.0 features although easy to implement will have to wait.
We had plans last year to complete a free Visual Basic compiler. Today the compiler exists in beta form and Novell will no longer fund the development of this compiler.
The folks at Mono Brazil have taken over the development and maintenance of the compiler.
The VB compiler is based on an old mcs fork that was originally created by Rafael Texeira. To upgrade the compiler from its current form to support generics in 2.0 we believe that it might be necessary to start from a fresh copy of `gmcs' and merge the various changes that make up the VB compiler.
Code Access Security (CAS) has been available in Mono since
version 1.1.4, it is enabled by running `mono' with the
--security command line option.
Although CAS is in a very advanced stage and it will be available on Mono 1.2 we will not guarantee that CAS is complete until the next major release of Mono. We are still missing the code verifier and in 2.0 there are new CAS features that we do not implement yet.
Sebastien who maintains the code has been busy adding CAS attributes to our class libraries and creating the associated tests, he discussed the state of CAS here.
As for how the CAS permissions are being set, he discusses that here.
Sebastien has written a general bug finding tool, similar in spirit to FxCop, which we are using to set the proper CAS rules on our libraries. You can learn more on the Gendarme page.
We released a fairly updated version of ASP.NET with Mono 1.1.9 which is much faster and consumes less memory. Our new implementation uses several tricks to improve the performance which we will blog about later.
In Mono 1.1.10 Gonzalo introduced a new automatic configuration option to the Apache module. Setting up mod_mono now behaves like other modules for other languages, for instance users and administrators can drop .asmx, .ashx or .aspx files anywhere on their exposed directories and they will automatically be handled by Mono's ASP.NET implementation without having to make any changes to the ASP.NET configuration.
As for the 2.0 support in ASP.NET we have implemented various controls that do not depend on the new Configuration API (menus, trees, masterpages, gridviews and anything they require).
Chris Toshok has taken over from Lluis on developing ASP.NET 2.0 and is almost done with the new System.Configuration namespace which is the foundation for the next batch of features in ASP.NET (profiles, portal parts and many others required it).
Chris has also done some work on an open source implementation of Atlas.
As for the stability of the APIs: the System.* ones are set in stone and we verify the compatibility using our "corcompare" tools. The .NET 1.1.x API has been implemented (as described in Mono 1.0 Features).
The Mono.* namespace on the other hand is still a moving target.
the Mono.Cairo assembly has had to adapt to the changes in the underlying Cairo 1.0 library and we also had to do various changes to cope with early bugs and limitations in our API design.
The Mono.Posix assembly has incorporated a new namespace: Mono.Unix which offers a more comprehensive binding and also provides a high-level .NET-ish API for accessing Unix as opposed to Mono.Posix which only contained raw access to Unix.
Version 2.4 of Gtk# has been released. The new features on
this release are documented here,
it binds Gtk 2.4 which is the most commonly available version
of Gtk+ at this point.
We have created an upgrade guide for developers moving their code from Gtk# 1 to Gtk# 2.
On the development side of Gtk#, a new version is available for testing that binds the Gtk+ 2.8 API and exposes a handful of new methods as well as the Cairo properties that are part of Gtk+ 2.8.
The work to add databinding support to Gtk# is currently on hold until Windows.Forms is completed. We expect to work again on a databound-aware Gtk# after Mono 1.2 has shipped.
We have integrated a few of the projects that were developed thanks to the Google Summer of Code program:
We are planning on integrating the ASP.NET editor work from Michael Hutchinson and Blagovest Dachev as well as the bugfinder engine from Aaron Tomb into Gendarme.
T Senganal will take over the maintenance of ADO.NET and will start working with the developers that are using the new features in ADO.NET 2 to get their providers working on Mono.
Cesar is very close to pass all the Mozilla JavaScript tests with our implementation of JScript.
If you want to track the state of the JScript compiler and runtime see the JScript page on the Mono web site.
You have reached the end. Congratulations!