There are 1,619 API calls that folks have reported that are either flagged with a [MonoTODO] attribute or are not implemented in Mono yet.

The list was compiled out of the 244 Moma submissions available as of 8pm.

A lot of these are 2.0 calls. The API lists are available here:

• System.Data (65 calls)
• System.Web (143 calls)
• System.Windows.Forms (778 calls)
• System.Xml (12 calls).
• The Rest (624 calls).

I will be updating those urls with API updates as we move along.

Within 12 hours of announcing Moma we received 114 submissions generated by the tool detailing what features were missing.

There were a number of interesting discoveries, these are:

False Positives: One of the most commonly reported error were method calls and property accesses to the System.Net.WebRequest class. These turned out to be incorrect, since this class is an abstract class that happens to have stubbed all those methods and throws NotImplementedExceptions as a mechanism to ensure that implementors get those methods right.

Developers will always be using a subclass that is created by the WebRequest.Create factory method (It makes me wonder why the methods were not flagged as abstract)

New or overwritten methods: In a number of places, overwritten methods are showing up in the report. For example, a very common one is Exception.GetType(), or with Label::set_Text (the Label.Text setter), in both cases the problem is caused by 2.0 introducing a new method that overrides the base definition.

The code, if compiled with Mono would have produced the correct result, but the binaries would not have worked as the member references were done to newer classes. Most of these are innocuous, and we already introduced the missing APIs for the most commonly reported problems.

Outdated MonoTODOs: We have plenty of miss-used MonoTODOs, these are the messages that we used internally to flag that something in a method is incomplete, and ideally, it should provide an explanation of why the flag was set.

But this is an attribute that we have used a bit recklessly over the past few years, and has had a number of meanings, from valid uses like "This method only implements half the specification" to less useful instances like "I do not like this API", to "Someone should optimize this routine" to "One day I would like to look improve this". So plenty of MonoTODOs were hints aimed at the source code maintainer, and not really to the developer that consumes the API.

Eliminating all of the bogus MonoTODOs is an ongoing process, but we might still get a few erroneous reports for a while that might confuse developers.

In particular, a lot of people hit on various methods in DataSet. None of those errors are correct, they are implemented, but they had old "MonoTODO" flags left behind.

Limitations in the .NET API: In a number of cases, developers have resorted to P/Invoke into the Win32 API, and the results are very interesting, the top reasons for using P/Invoke have been:

• Message dispatching: SendMessage, PostMessage.
• GDI/DC operations: GetDC, CreateBrush, CreateRgn, SelectObject, DrawText.
• Window operations: SetWindowPos, SetForegroundWindow ShowWindow, GetWindowRect, ClientToScreen, MoveWindow and Hook handling.
• Allocation: GlobalAlloc
• Fonts and Printing Dialogs.
• Shell access: to get recently used files, icons for files and a handful of others.

There are of course many more, but these are the majority of the uses.

Some of those APIs are easily translated into portable calls (Message dispatching, window operations, allocation) while others are very hard (GDI/DC operations) and some others are better if replaced as a chunk with alternative code.

Our next goal will be to provide a portability assembly that will take care of those operations that are easily translated, so P/Invoke calls would be replaced with calls into this portability assembly. On Windows, we will continue to P/Invoke the same methods, while on other platforms we would route the request through Mono's internals.

In the case of Shell access, the best thing to do is to provide a cross-platform API that does the integration with the user shell, and provide an API that developers can migrate to. This would be effectively a "complement" for APIs that are today not available for Windows.Forms and even be a lot simpler for many people to use than resorting to P/Invoking.

Lack of Comments: The first version of Moma lacked support for entering some comments from the person submitting the report, so all we got in our hands are the list of unimplemented methods, but we do not know much about the applications that are using it.

When we ran this over applications we had, we were able to identify pieces that can be replaced as units based on the class names where they were used (this is part of the report that people get, but not part of the information transmitted to us). For example, a commercial application that we want to port (with the assistance of the owners) has neatly isolated things like printing dialogs in its own file.

Cecil and Obfuscated Assemblies: Some of the applications that were processed were obfuscated. But the P/Invoke signatures also seem obfuscated, am not sure how those are actually resolved at runtime.

Moma's version: at some point, we will need to enable Moma to download new API definitions from our site, to allow developers to check back if their applications are ready without having to download a new copy of Moma.

Accounting: There are a number of limitations on the accounting and statistics that can be done with the results.

It is hard to tell with precision how many of these are .NET 1.1 vs .NET 2.0, which ones are C# and VB and which ones are ASP.NET vs Windows.Forms. This is caused because Moma only uploads lists of missing methods, it does not upload other information that might be confidential, so Moma erred on the side of safety and removed data that was not necessary for us.

The accounting for ASP.NET is further limited, since Moma does work on assemblies, and not on .aspx files. Those that used ASP.NET are most likely helper code that is used in ASP.NET applications.

Another challenge with the data is that each submission contains the report for all the assemblies submitted. The end user might have chosen a single program, a single project (made up of many executables and libraries) or multiple programs.

This is not a problem, but it is worth keeping in mind when you read the results below.

Results

From the submitted applications, ten of them work out of the box without any changes; Another 30 contained reports that could be ignored (MonoTODOs that should not have been there, the NotImplementeds that did not exist). Almost all of them contain calls to methods that are either easy to implement, or were already implemented.

At least 29 of the applications are 2.0-based (by looking at Label::set_Text and Exception::GetType) and 16 of them are VisualBasic applications. One of the applications embeds IKVM.

32 applications were ASP.NET applications; 56 used Windows.Forms; 32 use System.Data and 44 used System.Drawing (see the above caveats about interpreting this data; This is based on assemblies and submissions, not on projects).

P/Invoke usage, from the 114 applications submitted:

• 67 do not contain any P/Invoke calls.
• 9 contain between 1 and 3 P/Invoke calls.
• 10 contain between 4 and 10 P/Invoke calls.
• 9 contain between 11 and 20 P/Invoke calls.
• 5 contain between 22 and 48 P/Invoke calls.
• 6 contain between 55 and 100 P/Invoke calls.
• 5 contain between 102 and 180 P/Invoke calls.
• 3 container more than 200 P/Invoke calls
  In the three cases, about half of the P/Invokes are to their own libraries.

(details).

So roughly half of the .NET applications can port without any concerns about P/Invoke. The remaining 40% are easily portable (those that have less than 48 P/Invokes) another 5% would take a few weeks, and maybe a Linux/Mono expert to assist on the port. The last 5% will require some large refactoring to work on Linux.

The application that uses the most P/Invoke that we have received so far seems to be some kind of designer and also happens to use the System.Security.CodeAccessPermission::Assert a lot.

Update: Sebastien comments that this is most likely a case of badly designed software, it is intended to avoid lots of stack walks to check for permissions. The above was probably copy/pasted from some recipe as an optimization that was useful in the 1.x frameworks. It is not required for 2.0.

From the received applications, 15 of them need more work on VisualBasic. Although most of the Visual Basic applications reported NotImplementedExceptions for a number of their methods in CompilerServices, that turned out to be false positives, which leaves us with only 24 methods missing in the VB.NET runtime

Unsupported Technologies

There are a few features that we do not support, and do not plan to support, in Mono. These technologies are either being phased out (EnterpriseServices, System.Messaging, to be replaced by WCF/Olive), or they would require a lot of work that we are currently not planning on doing (COM).

EnterpriseServicesis was used only by two applications, and all they seem to miss is a call to ServicedComponent::Dispose(). I suspect these are generated by a tool, considering the lack of any other methods references (and that we know are flagged).

System.Messaging is another of the libraries that we have not implemented and it showed up in only three applications.

COM, showed up in three applications.

Update

By the time this post went up this morning, we had received 171 submissions.

Update: Moma 1.0 reports some false positives, see the post here for some explanations.

Jonathan Pobst wrote a very nice tool, the Mono Migration Analyzer (Moma) a tool that can be used by Windows .NET developers to evaluate whether their software will need any modifications to run on the Mono supported platforms, here is the welcome screen:

Moma works by analyzing all the instructions that the code contains and all the references to external types and assemblies (.exe and .dll files). The analysis is done using Cecil, a library used to examine, introspect and manipulate ECMA CIL images.

The first step is to select the assemblies to analyze:

During the analysis, Moma will look for any references to methods, fields, properties or events that the program does on external assemblies and report any of the following problems:

• Using un-implemented classes, methods or accessing missing properties or fields.
  This would happen for example if a piece of functionality that developers expect is not yet available on Mono (most likely, 2.0 features).
• Calls to methods, references to fields or types that have been flagged with the special "MonoTODO" attribute.
  Class libraries in Mono, when incomplete, are flagged with an attribute, like this:

  	[MonoTODO ("In Mono this is controlled by the --share-code flag")]
  	public LoaderOptimization LoaderOptimization {
  		// implementation details.
  	}
  		

  
  If your program uses the above property, Moma will provide a warning with the above text.
• P/Invoke invocations. P/Invoke has two uses: to call into your own unmanaged libraries, or to call into Win32 APIs that are not exposed in the .NET API.
  Moma will report all uses of P/Invoke (uses, not declarations; A lot of people include a lot of declarations that they never use).
• Any methods in Mono whose signature exists, but that throws a NotImplementedException when called.

After analyzing your code, Moma will then present a summary of the issues found in your application:

The report is a summary of the issues identified by Moma. You can get a detailed report of issues by clicking on "View Detailed Report". This new report is what you will be using when you go through your application making sure that your code is portable, the report looks like this:

Finally, you can help us prioritize which classes and features are most important, you can do so by submitting the report to our team:

Early Experiences

I used Moma in a couple of applications from third party vendors that we are interested in bringing to Linux. The results so far are very promising as we are not missing that much.

The majority of the problems so far have been in sections of code that P/Invoke to get to some features not available in the framework, things like preferences, recently used documents, CPU detection and a handful of features to get information about windows, items on the screen and a few more.

To help port those applications we will be creating a portability assembly that will provide an API that Windows developers can call and will provide the proper native equivalent on Linux, Windows and OSX.

Getting Moma

You can download Moma 1.0.1 from here.

Update New version is here.

Lluis Sánchez has posted his tentative release plan for MonoDevelop 1.0.

My father has a follow-up to his previous studies where he estimates the number of fake votes introduced in the July election. The programs to run the study at home are here.

The interesting result is that statistically 3,700,000 were inserted into the election results (to match the actual published results), with the majority of the inserted votes going to the party that officially won (by a less than 220,000 votes).

David has posted a roadmap for Compiz. It is all about the core engine, not much about plugins.

It also seems like a new repository for plugins will be created.

Also, he released a new version of Compiz, it is much smoother than the Compiz I have installed on my laptop.

A Linux distribution that contains only 3 binaries compiled with the C compiler: the kernel, libc and perl.

Someone needs to do a Mono/Linux distribution and follow the steps of these guys ;-)

Uri Avneri on the ongoing massacre in Gaza.

Gideon Levy:

"Gaza threatens to become Chechnya. There are thousands of wounded, disabled and shell-shocked people in Gaza, unable to receive any treatment. Those on respirators are liable to die due to the frequent power outages since Israel bombed the power plant. Tens of thousands of children suffer from existential anxiety, while their parents are unable to provide help. They are witnesses to sights that even Gaza's old-timers have never seen before".

Paolo has blogged his updates on running Mono on the Nokia 770, with the techincal details about the port.

From Reddit, Top 10 Reasons against DRM.

And a nice new discovery Defective by Design.Org.

Michael Schwarz has a tutorial for Windows users that are using the Mono VMware image on how to run their ASP.NET and AjaxPro applications on Mono.

The tutorial is a step-by-step tutorial on how to move your files from Windows to Linux and accessing it from there.

At the end of the article, he focuses on running the application with XSP, I left a comment on how to run it with Apache:

Running xsp in a console is similar to running Microsoft "Cassini" server, it is a small web server, and it is not very powerful.

The VMWare image comes with both the small server, and Apache integration (which would be equivalent to running your ASP.NET with IIS on the Windows world).

To run your applications with Apache, instead of xsp, just put your whole ASP.NET application in the /srv/www/htdocs directory.

To go there, just open the file manager, type Control-L, that will open the location bar, and enter /srv/www/htdocs

Copy the files there, and you are done, say you the directory MyWeb20App in /srv/www/htdocs, now you can browse to that location by going to:

http://localhost/MyWeb20App

Paolo has completed the support for the new ABI on the Nokia 770 which was part of the OS upgrade earlier this year.

The code currently lives in SVN, and will be part of the upcoming Mono 1.2.1.

But now would be a good time to use the new dependency tracking system on the Nokia and package all the Mono components.

I read on the Unity web site that FreeVerse is shipping their first Unity-based game.

And we are of course very proud of it, because Mono is driving all of those effects.

Mono is 10 megs out of the 66 megs in the distribution. Now that our embeddable eglib has been completed, we can shrink down an extra megabyte from the game download.

Congratulations to the Sun guys for the open sourcing of Java, another great contribution of Sun to free software.

I blogged about this in the past, but it is worth linking to it again, as I raised what I think are some interesting points regarding the open source community and implementation of large bodies of code.

Also, from reading Slashdot today I get the impression that there is too much of zero-sum mindset, a feeling that those of us in the Mono community would not be happy about this development, which is nonsense. We are after all, free software developers. Maybe this is based on the assumption that we are competing for the same contributors, and hence a fear of scarcity prevails. I like to think that although there is some overlap, our communities are vastly different.

Or maybe it is not a zero-sum mindset, but merely a matter of rooting for the home team brought to the world of programming languages.

In any case, a big hug to all the folks involved in open sourcing Java, am sure there will be quite a lot to learn from it, and am sure distributions cant wait for the full SDK release next year.

Update: interesting post from Tim Bray and Sam Ruby on the subject.

Lluis checked-in last week a new memory profiler for Mono applications.

He originally created this profiler based on `heap-buddy', while trying to understand memory consumption in MonoDevelop. I used it last week to trim down 340k of Tomboy memory consumption (removed a Hashtable that contained bools).

If you are a Mono application developer, you will find this tool very helpful in finding where your memory is going. It will look your app look better (and Mono look better ;-)

Joe and Larry will hopefully be pleased.

The profiler lives in module `heap-shot' on SVN.

For more information see Lluis' Blog

After two years of brewing, we finally released Mono 1.2. The release notes are here.

I would have blogged a lot more details, but it has been a couple of busy weeks: the Mono meeting burned all my spare time for two weeks, last week events and this week in Barcelona at the TechEd have not given me much time to blog about it.

Next week: Baden-baden for the Prio .NET Conference in Germany where am doing a keynote to present Mono to the .NET audience, and a tutorial session on Mono.

Some press coverage is here.

Thanks for sending your questions, some questions I could not answer myself, and I passed them on to Novell.

Novell has now posted the answers to some of the most frequently asked questions here

In particular, this covers the GPL section 7 questions, and our commitment to OIN (the patents listed today in OIN's site are Novell's contribution to the pool).

In Spanish: Miguel de Icaza, on Wednesday November 8th at 19:30 in the Aula Magna at the Universitat de Barcelona at Gran Via de les Corts Catalanes, 585.

Topics: Mono, Desktop Development with Mono, Xgl and Compiz, Linux, Microsoft and Novell announcement,

In English: Miguel de Icaza (Novell) and Philippe Cohen (Mainsoft) On Thursday November 9th at 19:00 in the Barcelona Princess Hotel, next to the TechEd forum.

Topics: Porting .NET applications using Novell's Mono or Mainsoft's Grasshopper. Deployment of applications into J2EE application servers with Mainsoft's Grasshopper.

Thanks to everyone that sent their comments and questions, there are a few questions that I would like to answer that have been a common theme.

These are my personal opinions, and do not represent in any way Novell's official position (its at the end of every page on my blog, but I figured its worth pointing out up front).

Q: Which Patents Does Mono Infringe?

I do not know of any patents which Mono infringes.

Although Novell provides most of the work to develop Mono, Mono is still a community project with many constituents and collaborators from companies, universities, governments and individuals, and as such we will continue to work and operate as a community project.

This means that we will continue to follow the rules that we have set for ourselves when it comes to patents:

The Mono strategy for dealing with these technologies is as follows: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.

This is what we would have done before the agreement, and that is what we will continue to do.

Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono.

There is more information on the web site on the above link.

We will continue to develop Mono under the same restrictions that we had before the agreement.

Q: Is it now possible to integrate code that uses Microsoft patents today?

Although it is possible, we will not integrate such code, as Mono is a community project.

And we will also continue to keep the Microsoft and Mono stacks separated, as there is no need to add dependencies between them and also makes it easy to split out all the non-ECMA components of Mono out.

Why did you guys work this deal with Microsoft?

Although I did not take part of the actual negotiations, and was only told about this deal less than a week before the announcement, I had been calling for a long time for a collaboration between Microsoft and Open Source and Microsoft and Novell.

There are numerous interviews that touch on this topic and most recently my interview in Microsoft's Port25

In the past I had called for this same kind of cooperation with other companies. In 1999, we started talking to Sun and HP regarding GNOME; In particular in 2000 we had a meeting with Marco Boerries at Sun to discuss the desktop, and their adoption of GNOME as their new desktop. At that time we discussed the plans to have a combined desktop made up of components of StarOffice and GNOME (at that meeting, I conceded that I would no longer work on Gnumeric, and instead we would improve OpenOffice; Sun conceded that Evolution would be their default mailer instead of the StarOffice one).

Have you not learned from history? Microsoft has damaged all of their partners in the past!

I have gotten a few emails along those lines and folks asking for comment, and a lot of hate mail (more than usual). I find it hard to reply to this comment, because this is really going to come down to personal opinions and personal biases.

In my personal opinion, I think that we have to give it the benefit of the doubt, try to turn the hand that has been dealt into the best possible outcome for everyone. Or as Benjamin Zander would say, I will give them an A, and work from there.

Similar deals have been done in the past, in 1997 Microsoft signed a similar deal with Apple, and Apple used that agreement and the incoming monies to turn the company around.

Sun signed a similar agreement with Microsoft in 2004, which at the time I realized enabled Sun to ship Mono on Solaris (which we already supported at that time).

Now, I can not say that the crowd applauded Apple and Sun at the time, and both of them ship a lot of GPL code, not the Linux kernel, but a lot of GPL code, and the sky has yet to fall on our heads.

Back in April of 2004, I wrote about that deal:

I am counting the minutes for Sun to ship our Mono implementation for Solaris. Maybe we can still make it to the Solaris 10 release.

Just picture the benefits, out of the box free C# compiler on Solaris SPARC and Solaris Intel. Out of the box ASP.NET and ADO.NET on SPARC, and the Gtk# bindings for writing applications for the Java Desktop System.

Not to mention that they get the industry's most sexy JIT compiler for free.

I am walking with an extra cell phone battery in case McNealy or Schwartz decide to call me up over the weekend to discuss potential agreements (if I don't pick up, please leave a message, the wonders of ATT wireless).

Am afraid to report that neither Scott nor Jonathan emailed me or left a voice mail at the time. I think it would have been grand for Sun, but maybe Java emotions were too strong inside the company for this to be even considered.

Could a better deal been struck for the Open Source community?

Possibly. But I do not know what the latitude was inside the deal.

What I can personally say is that considering that Microsoft is 100 times larger than Novell (market cap wise alone) it was probably difficult.

Getting rid of patents completely would probably have to involve a few giants. Microsoft has a 282B market cap, so maybe a combination of IBM (138B), Google (143B), Oracle (92B) and even Sun (18B) would have to come together and enter a gigantic patent love-fest to make a better deal for everyone happen (By comparison Novell is at 2.2B).

And this is why I find it surprising that Sun's Simon Phipps had forgotten that Sun entered a similar agreement a few years ago, and had this to say about the Microsoft/Novell deal:

It's a remarkable reversal of opportunity, all the more remarkable that the Novell participants smiled the whole way through what had clearly become a Microsoft event. They went in seeking a huge payout, and emerged with the payout, yes - but also with a commitment to pay it back in royalties on open source software they sell.

A larger opportunity could probably happen with a setup like the one I described previously. But whether this could actually be done, is left as an exercise to the reader (or alternative approaches that would completely eradicate software patents from the map).

Let me point out that McNeily seemed to be all smiles at the equivalent event a few years ago; Nothing bad about that, but Simon probably should notice that Sun is eight times larger than Novell, and if anything, his company is 8.18 in a better position that Novell is to take advantage of these opportunities.

The big new of the day: Microsoft and Novell are set to collaborate. You can read all about it here, you can also go straight to:

• The press release
• The FAQ
• Watch the webcast with the announcement.
• Joint Letter to the Open Source Community.

But the question on everyone's mind regarding today's announcement is what is the position regarding Mono, from the Q&A:

Q: What are you announcing?

...

Under a patent cooperation agreement, Microsoft and Novell provide patent coverage for each others customers, giving customers peace of mind regarding patent issues.

Q: What does the patent agreement cover with regard to Mono and OpenOffice?

Yes, under the patent agreement, customers will receive coverage for Mono, Samba, and OpenOffice as well as .NET and Windows Server. All of these technologies will be improved upon during the five years of the agreement and there are some limits on the coverage that would be provided for future technologies added to these offerings. The collaboration framework we have put in place allows us to work on complex subjects such as this where intellectual property and innovation are important parts of the conversation.

And from our joint letter:

Mono, OpenOffice and Samba:

• Under the patent agreement, customers will receive coverage for Mono, Samba, and OpenOffice as well as .NET and Windows Server.
• All of these technologies will be improved upon during the 5 years of the agreement and there are some limits on the coverage that would be provided for future technologies added to these offerings.
• The collaboration framework we have put in place allows us to work on complex subjects such as this where intellectual property and innovation are important parts of the conversation.
• Novell customers can use these technologies, secure in the knowledge that Microsoft and Novell are working together to offer the best possible joint solution.

So today we have secured a peace of mind for Novell customers that might have been worried about possible patent infringements open source deployments. This matters in particular for Mono, because for a long time its been the favorite conversation starter for folks that find dates on Slashdot.

Anyways, now that we got that out of the way, I wanted to point to Michael Meeks' blog entry on the OfficeXML collaboration, which one of the major areas of collaboration, his blog entry is here, regarding the general question around why support Office XML, Michael says:

This should not be a surprise - Jody Goldberg (on my team) has been working hard for months with Microsoft and others on the ECMA process. At one stage there around 1/2 the open 'issues' wrt. improving disclosure (and hence the spec.) came from Jody. I for one am proud of the job that he did there, an (ongoing) investment that will yield better interoperability for years to come.

Anecdotally, I would like to point out that the work that happened through the ECMA TC45 has proved very fruitful, as things that were completely left out of the Oasis specification and in the original TC45 submission were put in there because Jody and Michael that have previously worked on Gnumeric and OpenOffice managed to get these things into the spec.

Read Michael's blog for more details, as he has many nice things to say about Open Office and Office XML.

I have a longer blog entry in the works, I promise I will post later more of the details on the various areas of collaboration on the business angle, and the technical angle

If you have some questions about this, please email me at [email protected] and I will include answers to your questions on my updated blog entry.

XNA is a new set of tools for assisting in game design, development and mangement (see the XNA Wikipedia page).

One of the components is the "XNA Framework" a set of .NET APIs for actually building the applications. It does not expose DirectX which makes it simpler to be ported to other platforms.

Rob Loach has started a project to do an open source implementation using the TaoFramework (Tao provides bindings for all things OpenGL and a few other media libraries).

Rob's implementation is being developed here. Currently most of the development is happening on Windows, but the project on SVN has support for building this on Linux with Mono as well.