Porting WW to Mono

From World Wind Wiki

Revision as of 13:17, 24 September 2011 by Mkpl (Talk | contribs)
Jump to: navigation, search

This is an overview of issues in porting WorldWind to Mono. During the 2006 inspection World Wind was of version, and Mono of version 1.1.12. The updated inspection uses WorldWind 1.4.1 Alpha and Mono 2.2.


Up to Date Investigation of Mono Issues

The page below this section was last edited around 2006 so some of it is bound to be out of date. In an attempt to update this effort I ran the last Alpha release of WorldWind through the "Moma" Mono Migration Analyser. There is a qualifier ... "MoMA may fail to point out areas that will cause problems, and may point out areas which will not actually be an issue".

Image:Ww moma.jpg

The third item should read "No methods that throw NonImplementedException are called". See the MoMA issue descriptions page. The detailed listing can be seen on this MoMA Scan Results page.

See this Mono Guide to porting Winforms applications that uses this approach.

Win32 stuff that needs rewriting

WorldWind.PerformanceTimer: High resolution timer
WorldWind.Net.ProxyHelper: Proxy configurator used by WorldWind.Net.WebDownload
Utility.DataProtector: Used to encrypt user credentials
Utility.BindingsCheck: Windows pre-SP1 .NET runtime 1.1 "50 bindings problem" check, used by WorldWind.MainApplication
Utility.Win32Message: Turn Win32 error codes into messages, used by DataProtector and BindingsCheck
PluginEngine.PluginListView: Custom ListView that relies on Win32 API
WorldWindow.IsAppStillIdle: Private property relying on Win32 messaging, never used
WorldWind.MainApplication: Custom overridden WndProc, checking of whether the app is running already and sending of cmdline args to a running instance of the app, all three, relies on Win32 messaging
Three NativeMethods classes: Separate helper classes for custom Win32 messaging, used by the messaging issues described above

Windows.Net framework depedencies

Here are listed classes that are needed by WW, but Mono hasn't got them in full functionality yet. Excluding DirectX/3D, these depedencies are not necessarily very difficult to handle.

The inspection was based on a class status information shown in Mono docs and Mono WinForms development status.

These two will need a serious replacement
System.Windows.Forms: DateTimePicker, Form ("mdi under development, transparency not supported"), PropertyGrid, RichTextBox and TextBox may introduce trouble
System: Array and Environment.SpecialFolder
System.Text: StringBuilder
System.Xml: XmlTextWriter
System.IO: MemoryStream

These are the rest of the required namespaces which might work as is:

System.Globalization, System.Drawing, System.Web, System.Collections, System.Net, System.Reflection, System.Diagnostics, System.Xml.Schema, System.Xml.Serialization, System.Drawing.Drawing2D, System.Drawing.Design, System.CodeDom.Compiler, System.CodeDom, System.ComponentModel, System.Collections.Specialized, System.Runtime.CompilerServices, System.Runtime.InteropServices, System.Resources, System.Threading, System.Xml.XPath, System.Configuration, System.Security.Permissions, System.Security, System.Drawing.Imaging, System.Drawing.Text, System.Timers, Microsoft.VisualBasic, Microsoft.CSharp and Microsoft.JScript.

Note about what works

When I compiled WW with #Develop with 1.10, all the projects in the solution compiled except for WorldWind and WorldWindow. This does not mean that the code will run without error. Since Mono does not stub methods that are not working, it means someone has implememnted it, but may or may not be passing the unit tests.

Personal tools