CIL-enabled languages). System.Windows.Forms is an API defined
by Microsoft to build GUI applications.
+Q: Why not implement System.Windows.Forms on top of Gtk# or Qt#?
+
+A: There are several reasons for this.
+
+ First of all, Gtk+ and Qt are standard toolkits on Linux, and their
+ proponents want to use their favorite toolkits when writing
+ applications.
+
+ Related to this is the idea that System.Windows.Forms is
+ brain-dead in certain areas, such as internationalization.
+ System.Windows.Forms uses explicit sizes for all controls, as opposed
+ to Gtk+ and Qt which use a box/packing model, which can better deal with
+ the different string lengths different languages will have.
+
+ Next is compatibility. It is not possible to implement
+ System.Windows.Forms on top of Gtk+/Qt and have 100% compatibility,
+ because System.Windows.Forms exposes <i>lots</i> of Win32-isms, such as the
+ Win32 message loop. In order to maintain compatibility, Wine must be used,
+ and this is being done; see the
+ <a href="/winforms.html">System.Windows.Forms effort page</a>.
+
+ Additionally, Wine apps don't currently fit in -- visually -- with
+ Gtk+ or Qt apps.
+
Q: Will I be able to run my smart clients on systems powered by Mono?
A: As long as your applications are 100% .NET and do not make use
exposing it to other RPC systems (like CORBA) is really simple, and
does not even require support from an object.
- We will be implementing CORBA inter-operation as an extension to the
- Mono classes so that we can integrate with Bonobo, just like
- Microsoft provides COM inter-operation classes and support
- mechanisms.
+ <a href="http://remoting-corba.sourceforge.net/">Remoting.CORBA</a> is
+ a CORBA implementation that is gaining momentum.
+
+ Building an implementation of the Bonobo interfaces once this is ready
+ should be relatively simple.
Q: Can I serialize my objects to other things other than XML?
Q: Will Mono use ORBit?
-A: No. Mono will be using a new implementation of CORBA that isn't still started.
+A: There are a few advantages in using ORBit, like reusing existing code
+ and leveraging all the work done on it. Michael Meeks has posted
+ a few <a href="http://lists.ximian.com/archives/public/mono-list/2002-September/008592.html">reasons</a>,
+ as well as some <a href="http://lists.ximian.com/archives/public/mono-list/2002-September/008657.html">ideas</a>
+ that could be used to reuse ORBit.
+
+ Most users are likely to choose a native .NET solution, like <a href="http://cvs.gnome.org/bonsai">Remoting.CORBA</a>
+
<a name="monodoc"></a>
** MonoDoc
Q: What is MonoDoc?
-A: MonoDoc is a graphical documentation editor and viewer. Currently, MonoDoc
- consists of a Gtk# application and is in heavy development. There is also a
- Qt# version of it.
-
+A: MonoDoc is a graphical documentation browser for the Mono class
+ libraries. Currently, monodoc consists of a Gtk# application and is
+ in heavy development.
<a name="devel"></a>
** Development Tools and Issues
+Q: I am having trouble compiling a new version of Mono from CVS, it
+ complains about my runtime being out of sync.
+
+A: Jonathan Pryor has provided the following answer:
+
+ To upgrade your class libraries and compiler, see the See
+ README.building in the MCS directory.
+
+ The single biggest source of confusion seems to be the "Your
+ runtime is out of sync" messages. Realize that this is *normal*
+ while BUILDING. Think about it: you're building a new class
+ library with the old runtime. If the new class library references
+ a function that the old runtime knows nothing about, the runtime
+ system issues this warning.
+
+ Basically what needs to happen is for a new mono runtime to be
+ compiled, then the corlib class library be compiled, and once this
+ is done, install the new runtime, followed by corlib.
+
+ Once this is done, you can continue building your entire
+ environment.
+
Q: Will it be possible to use the CLI features without using byte codes
or the JIT?
<a name="asp">
** Mono and ASP.NET
-Q: Is Mono supporting ASP.NET?
+Q: Does Mono support ASP.NET?
+
+A: Yes.
-A: Yes. The development of the support for ASP.NET comes in various stages,
- here is what Gonzalo has been working on: 1. The Parser. 2. Getting the
- parser to generate output compatible with ASP.NET. 3. Running the sample
- output with the real Microsoft runtime but using our generated page. 4.
- Running the sample with our classes with the .NET runtime. 5. Running
- our sample code with our classes with our runtime. This is the process
- we are following. Currently Gonzalo has reached point 5.
+ Mono supports ASP.NET, we have shown an unmodified IBuySpy
+ installation running on Mono as well as various other programs. You can
+ try it yourself downloading the XSP server.
Q: Do I need install cygwin to work on ASP.NET in mono or Linux is enough since
it is self host right now.
A: Linux is enough.
+Q: How can I run ASP.NET-based applications with Mono?
+
+A: You need the Mono runtime and a hosting web server. Currently we distribute a
+ small web server called `xsp' which is used to debug applications, or you can choose
+ to use Daniel's Apache 2 module.
+
Q: Any plan to make ASP.NET in mono works with Apache in Linux?.
-A: Yes, we have plans to do so, but we need to wait for Patrik's patches to
- HttpRuntime. Once that is there, writing a mod_mono should be trivial
- (look at mono/samples/embed for a sample embedded application).
+A: Daniel has authored an Apache2 Module for Mono that hosts the ASP.NET runtime
+ and is available here: <a
+ href="http://apacheworld.org/modmono/">http://apacheworld.org/modmono/</a>
+
+Q: Will you support Apache 1?
+
+A: Modules developed for Apache 2 are not compatible with Apache 1.3
+ Daniel plans to support Apache 1.3 in the future but the current focus is on
+ Apache 2, because of the better support for threading and Windows.
+
+Q: Can I run Apache 1 and Apache 2 on the same machine?
+
+ You can always keep a copy of Apache 2 running in paralell with your Apache
+ 1.3 (either different port or using a reverse proxy).
+
+ You can also bind the two servers to different IP addresses on the
+ same physical machine.
<a name="ado">
** Mono and ADO.NET
Q: Could Java target the CLI?
-A: Yes, Java could target the CLI. We have details on a <a
- href="ideas.html#guavac">project</a> that someone could take on to
- make this happen.
+A: Yes, Java could target the CLI, Microsoft's J# compiler does that.
- Microsoft has an implementation of the Java language called J# that
- can target the CIL execution engine.
+ The <a href="http://weblog.ikvm.net/">IKVM</a> project builds a
+ Java runtime that works on top of .NET and on top of Mono. IKVM is
+ essentially a JIT compiler that translates from JVM bytecodes into
+ CIL instructions, and then lets the native JIT engine take over.
Q: Is it possible to write a JVM byte code to CIL converter?
be translated into the equivalent "meaning" in CLR-land.
</ul>
+ See also the <a href="http://weblog.ikvm.net/">IKVM project</a>
+
Q: Could mono become a hybrid CIL/java platform?
A: No. It is quite far from the philosophy of the project. The idea of Mono
Q: Do you plan to implement a Javascript compiler?
-A: Yes. Eto Demerzal has started a Rhino port to C#.
- After this is completed, we will begin developing
- the JavaScript compiler.
+A: Yes. The beginnings of the JScript compiler can be found on CVS.
+ Cesar coordinates this effort.
Q: Can Mono or .NET share system classes (loaded from mscore.dll and other
libs) or will it behave like Sun's Java VM?
encourage you to make those classes operate correctly well in both
Mono and .NET.
+ Today Mono ships with a number of extra libraries that were
+ developed either by members of the Mono community, or other
+ groups.
+
Q: Is there any way I can develop the class libraries using Linux yet?
-A: Yes. Some class libraries can be developed on Linux. Search for
- Paolo's post (he lists which classes can be compiled fine now).
+A: Yes. Mono has been selfhosting since March 2002.
Q: Is there any way I can install a known working copy of mono in /usr,
and an experimental copy somewhere else, and have both copies use
patents filed now, or changes made by Microsoft specifically to
create patent problems)?
-A: No. First, its basic functional capabilities have pre-existed too
- long to be held up by patents. The basic components of Mono are
- technologically equivalent to Sun's Java technology, which has been
- around for years.
-
- Mono will also implement multi-language and
- multi-architecture support, but there are previous technologies
- such as UCSD p-code and ANDF that also support multiple languages
- using a common intermediate language. The libraries are similar
- to other language's libraries, so again, they're too similar to
- be patentable in large measure.
-
- However, if Microsoft does patent some technology, then our plan is
- to either (1) work around it, (2) chop out patented pieces, (3)
- find prior art that would render the patent useless.
+A: First some background information.
+
+ The .NET Framework is divided in two parts: the ECMA/ISO covered
+ technologies and the other technologies developed on top of it like
+ ADO.NET, ASP.NET and Windows.Forms.
+
+ Mono implements the ECMA/ISO covered parts, as well as being a
+ project that aims to implement the higher level blocks like
+ ASP.NET, ADO.NET and Windows.Forms.
+
+ The Mono project has gone beyond both of those components and has
+ developed and integrated third party class libraries, the most
+ important being: Debugging APIs, integration with the Gnome
+ platform (Accessibility, Pango rendering, Gdk/Gtk, Glade, GnomeUI),
+ Mozilla, OpenGL, extensive database support (Microsoft only
+ supports a couple of providers out of the box, while Mono has
+ support for 11 different providers), our POSIX integration
+ libraries and finally the embedded API (used to add scripting to
+ applications and host the CLI, or for example as an embedded
+ runtime in Apache).
+
+ The core of the .NET Framework, and what has been patented by
+ Microsoft falls under the ECMA/ISO submission. Jim Miller at
+ Microsoft has made a statement on the patents covering ISO/ECMA,
+ (he is one of the inventors listed in the patent): <a
+ href="https://mailserver.di.unipi.it/pipermail/dotnet-sscli/msg00218.html">here</a>.
+
+ Basically a grant is given to anyone who want to implement those
+ components for free and for any purpose.
+
+ The controversial elements are the ASP.NET, ADO.NET and
+ Windows.Forms subsets. Those are convenient for people who need
+ full compatibility with the Windows platform, but are not required
+ for the open source Mono platform, nor integration with today's
+ Mono's rich support of Linux.
+
+ The Mono strategy for dealing with these tehcnologies is as
+ follows: (1) work around the patent by using a different
+ implementation techinque 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.
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.
+ The patents do not apply in countries where software patents are
+ not allowed.
+
+ For Linux server and desktop development, we only need the ECMA
+ components, and things that we have developed (like Gtk#) or Apache
+ integration.
+
<a name="etc"></a>
** Miscellaneous Questions
Q: Is it possible to use Visual C++ with Mono?.
-A: Well, It's possible to run VC++ generated apps under Mono though.
+A: It's possible to run VC++ generated apps under Mono, but we do not
+ provide a Manager C++ compiler ourselves.
<a name="problems"></a>
** Mono Common Problems
projects / mono.git / blobdiff