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

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

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

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

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

Within 12 hours ofannouncingMoma we received 114submissions generated by the tool detailing what features weremissing.

There were a number of interesting discoveries, these are:

False Positives: One of the most commonly reportederror were method calls and property accesses to theSystem.Net.WebRequest class. These turned out to beincorrect, since this class is an abstract class that happensto have stubbed all those methods and throwsNotImplementedExceptions as a mechanism to ensurethat implementors get those methods right.

Developers will always be using a subclass that is createdby theWebRequest.Create factory method (It makes mewonder why the methods were not flagged asabstract)

New or overwritten methods: In a number of places,overwritten methods are showing up in the report. Forexample, a very common one isException.GetType(), orwithLabel::set_Text (the Label.Text setter), in bothcases the problem is caused by 2.0 introducing a new methodthat overrides the base definition.

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

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

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

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

In particular, a lot of people hit on various methods inDataSet. None of those errors are correct, they areimplemented, 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, andthe results are very interesting, the top reasons for usingP/Invoke have been:

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

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

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

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

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

Lack of Comments: The first version ofMoma lacked support forentering some comments from the person submitting the report,so all we got in our hands are the list of unimplementedmethods, but we do not know much about the applications thatare using it.

When we ran this over applications we had, we were able toidentify pieces that can be replaced as units based on theclass names where they were used (this is part of the reportthat people get, but not part of the information transmittedto us). For example, a commercial application that we wantto port (with the assistance of the owners) has neatlyisolated things like printing dialogs in its own file.

Cecil and Obfuscated Assemblies: Some of theapplications that were processed were obfuscated. But theP/Invoke signatures also seem obfuscated, am not sure howthose are actually resolved at runtime.

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

Accounting: There are a number of limitations on theaccounting 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 onesare ASP.NET vs Windows.Forms. This is caused because Momaonly uploads lists of missing methods, it does not uploadother information that might be confidential, so Moma erred onthe side of safety and removed data that was not necessary forus.

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

Another challenge with the data is that each submissioncontains the report for all the assemblies submitted. Theend user might have chosen a single program, a single project(made up of many executables and libraries) or multipleprograms.

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

Results

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

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

32 applications were ASP.NET applications; 56 usedWindows.Forms; 32 use System.Data and 44 used System.Drawing(see the above caveats about interpreting this data; This isbased 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 thethree cases, about half of the P/Invokes are to theirown libraries.

(details).

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

The application that uses the most P/Invoke that we havereceived so far seems to be some kind of designer and alsohappens to use theSystem.Security.CodeAccessPermission::Assert alot.

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

From the received applications, 15 of them need more workon VisualBasic. Although most of the Visual Basicapplications reportedNotImplementedExceptions for anumber of their methods in CompilerServices, that turned outto be false positives, which leaves us with only 24 methodsmissing in the VB.NET runtime

Unsupported Technologies

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

EnterpriseServicesis was used only by two applications, and allthey seem to miss is a call toServicedComponent::Dispose(). I suspect these aregenerated by a tool, considering the lack of any other methodsreferences (and that we know are flagged).

System.Messaging is another of the libraries that we havenot 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 received171 submissions.

Update: Moma 1.0 reports some false positives, seethe postherefor some explanations.

Jonathan Pobst wrote a very nice tool, theMono MigrationAnalyzer (Moma) a tool that can be used by Windows .NETdevelopers to evaluate whether their software will need anymodifications to run on the Mono supported platforms, here isthe welcome screen:

Moma works by analyzing all the instructions that the codecontains and all the references to external types andassemblies (.exe and .dll files). The analysis is done usingCecil, alibrary used to examine, introspect and manipulate ECMA CILimages.

The first step is to select the assemblies to analyze:

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

• Using un-implemented classes, methods or accessingmissing properties or fields.
  This would happen for example if a piece offunctionality that developers expect is not yetavailable on Mono (most likely, 2.0 features).
• Calls to methods, references to fields or typesthat have been flagged with the special "MonoTODO"attribute.
  Class libraries in Mono, when incomplete, areflagged 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 willprovide a warning with the above text.
• P/Invoke invocations. P/Invoke has two uses: tocall into your own unmanaged libraries, or to callinto Win32 APIs that are not exposed in the .NET API.
  Moma will report all uses of P/Invoke (uses, notdeclarations; A lot of people include a lot ofdeclarations that they never use).
• Any methods in Mono whose signature exists, butthat throws aNotImplementedException whencalled.

After analyzing your code, Moma will then present a summaryof 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 "ViewDetailed Report". This new report is what you will be usingwhen you go through your application making sure that yourcode is portable, the report looks like this:

Finally, you can help us prioritize which classes andfeatures are most important, you can do so by submitting thereport to our team:

Early Experiences

I used Moma in a couple of applications from third partyvendors that we are interested in bringing to Linux. Theresults so far are very promising as we are not missing thatmuch.

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

To help port those applications we will be creating aportability assembly that will provide an API that Windowsdevelopers can call and will provide the proper nativeequivalent on Linux, Windows and OSX.

Getting Moma

You can download Moma 1.0.1 fromhere.

Update New version ishere.

Lluis Sánchez has posted histentativerelease plan for MonoDevelop 1.0.

My father has a follow-up to his previous studies where heestimates thenumber of fake votes introduced in the July election.The programs to run the study at home arehere.

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

David has posted aroadmapfor Compiz. It is all about the core engine, not much aboutplugins.

It also seems like a new repository for plugins will becreated.

Also, he released anewversion of Compiz, it is much smoother than the Compiz Ihave installed on my laptop.

ALinuxdistribution that contains only 3 binaries compiled withthe C compiler: the kernel, libc and perl.

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

Uri Avneri on theongoingmassacre in Gaza.

GideonLevy:

"Gaza threatens to become Chechnya. There are thousands ofwounded, disabled and shell-shocked people in Gaza, unable toreceive any treatment. Those on respirators are liable to diedue to the frequent power outages since Israel bombed thepower plant. Tens of thousands of children suffer fromexistential anxiety, while their parents are unable to providehelp. They are witnesses to sights that even Gaza's old-timershave never seen before".

Paolo hasbloggedhis updates on running Mono on the Nokia 770, with thetechincal details about the port.

From Reddit,Top10 Reasons against DRM.

And a nice new discoveryDefective byDesign.Org.

MichaelSchwarz has a tutorial for Windows users that are usingthe Mono VMware image on how to run their ASP.NET andAjaxPro applications onMono.

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

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

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

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

To run your applications with Apache, instead of xsp, justput your whole ASP.NET application in the/srv/www/htdocsdirectory.

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 thedirectoryMyWeb20App in/srv/www/htdocs, now you can browse tothat location by going to:

http://localhost/MyWeb20App

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

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

But now would be a good time to use the new dependencytracking system on the Nokia and package all the Monocomponents.

I read on the Unity web site that FreeVerseis shippingtheir firstUnity-based game.

And we are of course very proud of it, because Mono isdriving 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 canshrink down an extra megabyte from the game download.

Congratulations to the Sun guys for theopensourcing of Java, another great contribution of Sun tofree software.

I blogged about thisinthe past, but it is worth linking to it again, as I raisedwhat I think are some interesting points regarding the opensource community and implementation of large bodies of code.

Also, from reading Slashdot today I get the impression thatthere is too much ofzero-summindset, a feeling that those of us in the Mono communitywould not be happy about this development, which is nonsense.We are after all, free software developers. Maybe this isbased on the assumption that we are competing for the samecontributors, and hence a fear ofscarcityprevails. I like to think that although there is someoverlap, our communities are vastly different.

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

In any case, a big hug to all the folks involved in opensourcing Java, am sure there will be quite a lot to learn fromit, and am sure distributions cant wait for the full SDKrelease next year.

Update: interesting post fromTimBray andSamRuby on the subject.

Lluischecked-in last week a new memory profiler for Monoapplications.

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 memoryconsumption (removed a Hashtable that contained bools).

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

Joe andLarry willhopefully be pleased.

The profiler lives in module`heap-shot'onSVN.

For more information seeLluis'Blog

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

I would have blogged a lot more details, but it has been acouple of busy weeks: the Mono meeting burned all my sparetime for two weeks, last week events and this week inBarcelona at the TechEd have not given me much time to blogabout it.

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

Some press coverage ishere.

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

Novell has now posted the answers to some of the mostfrequently asked questionshere

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

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

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

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

Topics: Porting .NET applications using Novell's Mono orMainsoft's Grasshopper. Deployment of applications into J2EEapplication 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 thathave been a common theme.

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

Q: Which Patents Does Mono Infringe?

I do not know ofany patents which Mono infringes.

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

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

The Mono strategy for dealing with these technologies is asfollows: (1) work around the patent by using a differentimplementation technique that retains the API, but changes themechanism; if that is not possible, we would (2) remove thepieces 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, andthat is what we will continue to do.

Not providing a patented capability would weaken theinteroperability, 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 abovelink.

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

Q: Is it now possible to integrate code that usesMicrosoft 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 Monostacks separated, as there is no need to add dependenciesbetween them and also makes it easy to split out all thenon-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 theannouncement, I had been calling for a long time for acollaboration between Microsoft and Open Source and Microsoftand Novell.

There are numerous interviews that touch on this topic andmost recently my interview in Microsoft'sPort25

In the past I had called for this same kind of cooperationwith other companies. In 1999, we started talking to Sun andHP regarding GNOME; In particular in 2000 we had a meetingwith Marco Boerries at Sun to discuss the desktop, and theiradoption of GNOME as their new desktop. At that time wediscussed the plans to have a combined desktop made up ofcomponents of StarOffice and GNOME (at that meeting, Iconceded that I would no longer work on Gnumeric, and insteadwe would improve OpenOffice; Sun conceded that Evolutionwould be their default mailer instead of the StarOffice one).

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

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

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

Similar deals have been done in the past, in1997Microsoft signed a similar deal with Apple, and Apple usedthat agreement and the incoming monies to turn the companyaround.

Sunsigneda similar agreement with Microsoft in 2004, which at thetime I realized enabled Sun to ship Mono on Solaris (which wealready supported at that time).

Now, I can not say that the crowd applauded Apple and Sunat the time, and both of them ship a lot of GPL code, not theLinux kernel, but a lot of GPL code, and the sky has yet tofall on our heads.

Back in April of 2004,Iwrote about that deal:

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

Just picture the benefits, out of the box free C# compileron Solaris SPARC and Solaris Intel. Out of the box ASP.NET andADO.NET on SPARC, and the Gtk# bindings for writingapplications for the Java Desktop System.

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

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

Am afraid to report that neither Scott nor Jonathan emailedme or left a voice mail at the time. I think it would havebeen grand for Sun, but maybe Java emotions were too stronginside 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 latitudewas inside the deal.

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

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

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

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

A larger opportunity could probably happen with a setuplike the one I described previously. But whether this couldactually be done, is left as an exercise to the reader (oralternative approaches that would completely eradicatesoftware patents from the map).

Let me point out that McNeily seemed to beallsmiles at the equivalent event a few years ago; Nothingbad about that, but Simon probably should notice that Sun iseight times larger than Novell, and if anything, his companyis 8.18 in a better position that Novell is to take advantageof these opportunities.

The big new of the day: Microsoft and Novell are set tocollaborate. You can read all about ithere, youcan also go straight to:

• Thepress release
• TheFAQ
• Watchthe webcast with the announcement.
• JointLetter to the Open Source Community.

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

Q: What are you announcing?

...

Under a patent cooperation agreement, Microsoft and Novellprovide patent coverage for each others customers, givingcustomers 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 receivecoverage for Mono, Samba, and OpenOffice as well as .NET andWindows Server. All of these technologies will be improvedupon during the five years of the agreement and there are somelimits on the coverage that would be provided for futuretechnologies added to these offerings. The collaborationframework we have put in place allows us to work on complexsubjects such as this where intellectual property andinnovation are important parts of the conversation.

And from our joint letter:

Mono, OpenOffice and Samba:

• Under the patent agreement, customers will receivecoverage for Mono, Samba, and OpenOffice as well as.NET and Windows Server.
• All of these technologies will be improved uponduring the 5 years of the agreement and there are somelimits on the coverage that would be provided forfuture technologies added to these offerings.
• The collaboration framework we have put in placeallows us to work on complex subjects such as thiswhere intellectual property and innovation areimportant parts of the conversation.
• Novell customers can use these technologies,secure in the knowledge that Microsoft and Novell areworking together to offer the best possible jointsolution.

So today we have secured a peace of mind for Novellcustomers that might have been worried about possible patentinfringements open source deployments. This matters inparticular for Mono, because for a long time its been thefavorite conversation starter for folks that find dates onSlashdot.

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

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

Anecdotally, I would like to point out that the work thathappened through the ECMA TC45 has proved very fruitful, asthings that were completely left out of the Oasisspecification and in the original TC45 submission were put inthere because Jody and Michael that have previously worked onGnumeric and OpenOffice managed to get these things into thespec.

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

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

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

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

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

Rob Loach has started a project to do an open sourceimplementation using theTaoFramework (Taoprovides bindings for all things OpenGL and a few other medialibraries).

Rob's implementation is being developedhere.Currently most of the development is happening on Windows, butthe project on SVN has support for building this on Linux withMono as well.

Blog Search

Contact

Archive