+Q: What kind of rules make the Common Intermediate Language useful for
+ JITers?
+
+A: The main rule is that the stack in the CLI is not a general purpose
+ stack. You are not allowed to use it for other purposes than
+ computing values and passing arguments to functions or return
+ values.
+
+ At any given call or return instruction, the types on the stack
+ have to be the same independently of the flow of execution of your
+ code.
+
+Q: Is it true that the CIL is ideal for JITing and not efficient for
+ interpreters?
+
+A: The CIL is better suited to be JITed than JVM byte codes, but you
+ can interpret them as trivially as you can interpret JVM byte
+ codes.
+
+Q: Isn't it a little bit confusing to have the name of "XSP" (the same
+ as in the Apache Project) for the ASP.NET support in Mono?.
+
+A: In Mono, xsp is just the name of the C# code generator for ASP.NET
+ pages. In the Apache Project, it is a term for the "eXtensible Server
+ Pages" technology so as they are very different things, they don't
+ conflict.
+
+Q: What about using something like Jabber instead of the System.Messaging
+ namespace?.
+
+A: In short, MSMQ is not something like Jabber, but asynchronous messaging
+ through queues. Useful queues do more than serialize messages, they are
+ also platform bridges.
+
+Q: Are you supporting XMLDocument and relatives?.
+
+A: Currently, we aren't implementing them yet. It would require updates to
+ most of the XmlNode derivatives so it's not a trivial task. We are
+ currently focusing on getting XPath support working.
+
+Q: Is there any plan to develop an aspx server for Mono?.
+
+A: The web server turned out to be very simple compared to the rest of the
+ work. Gonzalo has got the page generator mostly done (a module called
+ xsp, who has nothing to do with the XSP term used in the Apache Project).
+ Patrik has done a lot of the work to get the ProcessRequest to work.
+ You can try to help in the final touches to the System.Web classes and
+ writing regression tests for the widgets we have.
+
+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).
+
+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
+ their own libraries? (I'm still not very good at library paths in
+ Linux)
+
+A: Yes. Just use two installation prefixes.
+
+Q: How should I write tests or a tests suite?
+
+A: If you do a test suite for C#, you might want to keep it
+ independent of the Mono C# compiler, so that other compiler
+ implementations can later use it.
+
+Q: Would it be too terrible to have another corlib signed as mscorlib?
+
+A: We rename corlib to mscorlib also when saving the PE files, in fact,
+ the runtime can execute program created by mono just fine.
+
+Q: Is there a relatively straightforward way to repeat the steps taken
+ by Paolo to get Mono completely self-hosted on Linux?
+
+A: To build the compiler and class libraries in Linux, run:
+ <ul><li>make -f makefile.gnu. To install them, run: </li>
+ <li>make -f makefile.gnu install prefix=/opt/mono</li>
+ </ul>
+
+ If you want to produce and distribute a monocharge tarball, run:
+ make -f makefile.gnu dist
+ Of course you have to run these in the top level mcs directory.
+
+Q: Is it possible to build a C# file to some sort of intermediate format which
+ can linked into a final module, like the traditional .c -> .o -> .so path?
+
+A: You could do: mcs /target:module file1.cs, mcs /target:module file2.cs,
+ mcs /target:exe file1.dll file2.dll /out:mybin.exe
+
+Q: Is there any plans for implementing remoting in the near future?, When will
+ work in System.Runtime.Remoting.dll start?
+
+A: The remoting infrastructure is in place. Some of the channels and
+ formatters are not.
+
+Q: I'm wondering if there are any plans to start using nant to build the
+ class lib + test lib. i think that every project need/should use an
+ automated build process and nant + a couple of tools enables this. is
+ the problem that the compiler can't run nant yet?
+
+A: Maybe well be doing some sort of automated build process + testing when
+ the summer finish.
+
+Q: My C code uses the __stdcall which is not availble on Linux, how can I
+ make the code portable Windows/Unix across platforms?
+
+A: Replace the __stdcall attribute with the STDCALL macro, and include this
+ in your C code for newer gcc versions:
+
+ #ifndef STDCALL
+ #define STDCALL __attribute__((stdcall))
+ #endif
+
+<a name="asp">
+** Mono and ASP.NET
+
+Q: Does Mono support ASP.NET?
+
+A: Yes.
+
+ 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: 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: What is the status of ADO.NET support?. Could I start migrating
+ applications from MS.NET to Mono?.
+
+A: You could start right now using the ADO.NET support in mono, of course,
+ if you want to help filling the missing gaps while you develop your app
+ :-) Well, what I mean is that we're not that far to having full ADO.NET
+ support in Mono, and we've got a lot of working things, so if we could
+ get more help, we'd finish it really soon :-)
+
+Q: In developing the data architecture for the application are there and
+ objects I should stay away from in order to insure the smoothest possible
+ transition (minimum code rewrite) to Mono's ADO.NET implementation? (For
+ example, strongly typed datasets versus untyped datasets, etc...)
+
+A: We are implementing all the classes in Microsoft .NET's System.Data, so
+ you can be sure that things will work the same in Mono as with the Microsoft
+ implementation.
+
+Q: Does Mono can to connect to Sybase by using Mono.Data.*?
+
+A: Yes. use Mono.Data.SybaseClient. First of all you have to create a
+ SybaseConnection, and then, from it, use it as any other
+ IDbConnection-based class.
+
+<a name="java">
projects / mono.git / blobdiff