.NET support through mono

I’m not famililar with programming in BeOS but I’m a developer very interested in the OS. One thing that I feel would generate a lot of attention for Haiku is if a group was working of a port of mono or some other .NET port to run on Haiku or any BeOS implementation.

I’m not sure how much of the mono code is tied to Linux at the time as I understand the intention was to keep the bulk of the code written as managed code on top of the rest of the famework. So, if this is true alternate bindings should be able to be provided in most cases at least to provide the basic .NET runtime so that completely managed executables and libraries could be used directly in Haiku.

Of course there are many considerations such as implementing the mono stack on Haiku what if any GUI to support. An option may also be to make a dotnetified BeOS GUI API. Other considerations are probably similar to ones mentioned on mono-project.com

I’m mentioning this here because I’ve been searching for people who may already be at work on this but have not yet found any. If there there does exist projects or discussion in this topic area please direct me to them and excuse my ignorance.

kainhart wrote:
I'm not famililar with programming in BeOS but I'm a developer very interested in the OS. One thing that I feel would generate a lot of attention for Haiku is if a group was working of a port of mono or some other .NET port to run on Haiku or any BeOS implementation.

I’m not sure how much of the mono code is tied to Linux at the time as I understand the intention was to keep the bulk of the code written as managed code on top of the rest of the famework. So, if this is true alternate bindings should be able to be provided in most cases at least to provide the basic .NET runtime so that completely managed executables and libraries could be used directly in Haiku.

Of course there are many considerations such as implementing the mono stack on Haiku what if any GUI to support. An option may also be to make a dotnetified BeOS GUI API. Other considerations are probably similar to ones mentioned on mono-project.com

I’m mentioning this here because I’ve been searching for people who may already be at work on this but have not yet found any. If there there does exist projects or discussion in this topic area please direct me to them and excuse my ignorance.

I agree with you, but then that might be because I write .net code (c#) and feel it would be useful for persons like me to migrate my development efforts to other platforms.

I’m specifically interested in the GTK# libraries - I know that the current BeOS GTK+ port is probably a bit dated at the moment, but a fresh port of GTK+, Mono, and GTK# could allow Haiku to have new cross-platform applications at it’s disposal.

Someone could even invest the time in a "HaikuForm"s library (similar to Microsoft’s WinForms and GTK#) to allow native GUI-bindings to Haiku’s interface kit components… that would be slick!

Ok, well I’m glad it’s not just me that would like to see this. I guess the question is still, is there anybody working on this yet? and if not whats the best way to go about advocating or starting up an effort in this direction? Of course there are always questions such as how, and thats where I’m definitly limited as I have no experience programming for BeOS and from what I can tell it’s not the easiest thing to set up and get started. .NET support or at least a C# compiler that allows code to be created that can access BeOS APIs would definitly be the one thing that gets me to hunt down an old BeOS copy, install, learn, and start programming.

kainhart wrote:
Ok, well I'm glad it's not just me that would like to see this. I guess the question is still, is there anybody working on this yet? and if not whats the best way to go about advocating or starting up an effort in this direction? Of course there are always questions such as how, and thats where I'm definitly limited as I have no experience programming for BeOS and from what I can tell it's not the easiest thing to set up and get started. .NET support or at least a C# compiler that allows code to be created that can access BeOS APIs would definitly be the one thing that gets me to hunt down an old BeOS copy, install, learn, and start programming.

It seems like a good project for BeUnited to host - someone should definitely contact the Mono guys and let them know the BeOS community wants a mono port, and how do we go about getting started, etc.

As for C# compiling to native code… I’m not sure - the language is designed with an assumption that automatic garbage collection exists similar to Java. I’ve heard of projects to hook up GCC to compile C# to CIL code (similar to how it can compile Java to java-byte-code) - but that still requires a CLR like Mono to run the binaries/assemblies … although I read that there are ways to compile java to native code using GCC… not sure how that works.

I was hoping to get involved with the mono project by downloading the source and eventually implement a few classes but I was overwhelmed with the content of the source code. Acutally I don’t know if it is a result of my inexperience with CVS or not but the source appears to be a big mess of everything except for code written in C#.

The plan is that I want to get to know mono and BeOS so I can at least start a movement for supporting .NET on Haiku. Since the mono development seems a little over my head right now, I’m taking it slow and hoping that somebody else can kickstart this project.

My understanding of Mono is that it relies on a lot of other stuff to work …

ie. Wine, GTK, etc

So, it anyone wants to work on porting GTK … that would be a step in the right direction.

Sikosis wrote:
My understanding of Mono is that it relies on a lot of other stuff to work ...

ie. Wine, GTK, etc

So, it anyone wants to work on porting GTK … that would be a step in the right direction.

I think Wine is specific to the Windows.Forms support, and GTK+ is required for the GKT# support… I wonder how platform-dependent the underlying CLR, CIL Interpreter, etc. are…

http://mt.begroovy.com/mt-comments.cgi?entry_id=550

Quote:
I am currently working on dotgnu potable.net I am 90% complete only pnetlib is giving trouble I have to build mscorlib manually wich is the only thing that needs to be done.Ilrun,cscc and the binaries are completed . I have Qt 3.3.2 ported for the front Qt # and Hbasic.NET.

By week end BeOS will have .NET fully running.
Posted by jeff at June 20, 2004 09:26 PM

jeff’s email is linked on the website if anyone wishes to contact him.

Cool!!!

Screenshot Demo of DotGNU Portable.NET on BeOS

jtorgers wrote:
Cool!!!!

Screenshot Demo of DotGNU Portable.NET on BeOS

Yup, that’s been there for a bit… but it’s still not mono – I suspect DotGNU is a bit easier to port as it’s a smaller subset of the .NET framework… but it’s certainly a step!

Hello. I’m really interested in developing a .NET runtime for Haiku. That’s a great an Idea and if anyonone is interested in ivolving my efforts to development process, I’m always ready!

Please do port of Mono to BeOS. I am currently learning C# 2K5 and it’s HOT!!! :oops:

i’ve seen that GTK+ is being ported to beos. it’s in alpha right now.

http://www.gtk.org/beos/

you should have looked at the date of these things… the latest snapshot is from 2000…

fanton wrote:
i've seen that GTK+ is being ported to beos. it's in alpha right now.

http://www.gtk.org/beos/

GTK 1.2, and was “being ported” from 1999->2000 and not since.

is this an old un-updated site?

they offer snapshots, and incldue gtk 2.0

ftp://ftp.gtk.org/pub/gtk/unstable/beos/

it migt be outdated :stuck_out_tongue:

so what do one has to do to port gtk. i would like to try it out. don’t we need the app_server to work first?

i would get gaim working, and many other useful tools. gaim has almost all networks you need.

To port it you dont really need the app_server, you could potentially just develop it as a wrapper. But if you really wanted it to be embedded deeply you would have to wait until app_server.

As for gaim, try http://eiman.tv/imkit/ for the im_kit. I’ve yet to try it properly, but it looks pretty damn cool to me. Everything is done “the BeOS way”.

the thing is, gtk could be implemented as a gtk_server, rather than run on top of X or on top of windows or on top of the app_serv as a regular app. in winxp gtk is slow. it takes twice as long to show a window.

same thing with java.

since beos and haiku rely on a microkernel architecture, we could build servers (and kits). for example java_server, which would be much faster than as an application running trough the app_serv.

please correct me if i’m wrong.

but back to gtk. i think I would wait for app_server to be complete. or help out with the app_server first. i’ve looked trough “our status” which i think might be a bit un-updated, and the most work remains to be done on the app_server.

kits are libraries right? include files to build programs.

eNGIMa wrote:
To port it you dont really need the app_server, you could potentially just develop it as a wrapper.

what to you mean by wrapper? i have a hint of what that is, but don’t know. i have to dig into that. it wraps around the gui part.

if we build gtk as a server, you woudn’t need to wait for the app_server, cause gtk would talk with the kernel directly. we could steal code from the app_server, the part that makes thigs appear, and combine it with gtk code, and done. and that is native gtk support.

take the load off server for applications, and make gtk independent. it will behave like an alternative app_server, except that most of the code must pe refitted. and you have an alternative look for haiku :stuck_out_tongue:

am i being dumb?

wrapper: In computer science, a wrapper is a piece of code which is combined with another piece of code to determine how that code is executed.

fanton wrote:
the thing is, gtk could be implemented as a gtk_server, rather than run on top of X or on top of windows or on top of the app_serv as a regular app. in winxp gtk is slow. it takes twice as long to show a window.

same thing with java.

since beos and haiku rely on a microkernel architecture, we could build servers (and kits). for example java_server, which would be much faster than as an application running trough the app_serv.

please correct me if i’m wrong.

but back to gtk. i think I would wait for app_server to be complete. or help out with the app_server first. i’ve looked trough “our status” which i think might be a bit un-updated, and the most work remains to be done on the app_server.

kits are libraries right? include files to build programs.

eNGIMa wrote:
To port it you dont really need the app_server, you could potentially just develop it as a wrapper.

what to you mean by wrapper? i have a hint of what that is, but don’t know. i have to dig into that. it wraps around the gui part.

if we build gtk as a server, you woudn’t need to wait for the app_server, cause gtk would talk with the kernel directly. we could steal code from the app_server, the part that makes thigs appear, and combine it with gtk code, and done. and that is native gtk support.

take the load off server for applications, and make gtk independent. it will behave like an alternative app_server, except that most of the code must pe refitted. and you have an alternative look for haiku :stuck_out_tongue:

am i being dumb?

wrapper: In computer science, a wrapper is a piece of code which is combined with another piece of code to determine how that code is executed.

eNGIMa wrote:
As for gaim, try http://eiman.tv/imkit/ for the im_kit. I've yet to try it properly, but it looks pretty damn cool to me. Everything is done "the BeOS way".

yeah but is missing the yahoo and msn bits, which i need. gaim is what i like. so i have to go there and add yahoo and msn support myself. which i have to dig into, research, or steal code from gaim :smiley:

Quote:
what to you mean by wrapper? i have a hint of what that is, but don't know. i have to dig into that. it wraps around the gui part.

Essentially a wrapper for gtk would mean that all the gtk code just called the BeOS equivalent. Basically re-routing the calls to native calls. It would run a bit slower, but as I see it a GTK library would only be a stopgap measure to fill a few application gaps.

Quote:
yeah but is missing the yahoo and msn bits, which i need. gaim is what i like. so i have to go there and add yahoo and msn support myself. which i have to dig into, research, or steal code from gaim

I just had a look at the CVS then and it appears to support AIM, ICQ, Jabber, MSN and Yahoo plugins. I tried to install the entire thing last night but I’ve borked something (and have some nonstandard extras on the system). YMMV.