Porting WW to Mono
From World Wind Wiki
This is an overview of issues in porting WorldWind to Mono. During the 2006 inspection World Wind was of version 1.3.3.1, and Mono of version 1.1.12. The updated inspection uses WorldWind 1.4.1 Alpha and Mono 2.2.
Contents |
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".
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.
Microsoft.DirectX.Direct3D, Microsoft.DirectX: | 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.