Linked by Thom Holwerda on Sun 11th Jan 2009 10:54 UTC, submitted by Hiev
Mono Project Arstechnica reports that Mono, an open source implementation of .NET runtime, is bringing Microsoft's development technologies to some unexpected places, including the iPhone, Android, and the Wii.
Order by: Score:
Nice
by danieldk on Sun 11th Jan 2009 11:32 UTC
danieldk
Member since:
2005-11-18

This is a very nice example of what a FLOSS implementation can bring to the table. Even Microsoft could/should be happy with this. If someone developed an iPhone-native game, it doesn't benefit Microsoft (or Nintendo) at all, while now they do. Additionally, it's relatively cheap for developers to make releases for multiple platforms. And in the end that seems something to strive for: applications that will seamlessly work on all major desktop, mobile, and gaming platforms.

Java and Android seem to be interesting in this respect as well. So, did anyone try creating native code for the iPhone through gcj? ;) (Edit: I know that there could be GPL problems wrt Apple's iPhone policies.)

Edited 2009-01-11 11:34 UTC

Reply Score: 4

adkilla
Member since:
2005-07-07

While I applaud the efforts of the Mono people, they attempts at bringing Microsoft platform technologies to other platforms seems odd as it tries to bring MS's concepts of an operating environment to other platforms.

I mean come on, don't you find it odd that your Mono apps compile to exe and dlls with the need for a Windows like registry on Linux/Mac? Why force MS's concept of an operating environment and application behavior in other OSes?

Java has done a much better job at keeping their platform agnostic of operating environments without having to force a Solaris-like operating environment into other platforms. My Java apps use plists on Macs and registry under Windows as expected by default, the same can't be said of Mono apps.

-Ad

Reply Score: 1

Toad Member since:
2005-11-27


I mean come on, don't you find it odd that your Mono apps compile to exe and dlls with the need for a Windows like registry on Linux/Mac? Why force MS's concept of an operating environment and application behavior in other OSes?


I am not aware that the .net is depended on the registry, in fact I have heard that .net was a way for microsoft of getting rid of dll/registry hell of COM/ACTIVEX. .net uses largly the GAC (global asembly Cash) for shared components, not the registry. For configuration it uses XML Configuration Files both on framework level as on application level.

The only useage of com/registry is that a few methods in the frameworks API is mapped against com method/win32 method in the windows OS that uses the registry, but that is only an implementation details;
So where is the dependency on the registry?

Reply Score: 3

Yuske Member since:
2005-07-28

Don't worry, he is just being ignorant. On porpose.

Reply Score: 3

adkilla Member since:
2005-07-07

Ignorant and annoying at the same time? You must be new here.

Mono provides an emulated Windows registry. There is even a tool that allows you to edit it on non-Windows platforms: http://www.mail-archive.com/mono-list@lists.ximian.com/msg21662.htm...

"They have also included a Mono migration analysis tool that will let you know if you are making calls that will work differently under Mono. Some .NET calls that access the Windows API mechanisms or low-level system calls will still work just fine, but the developer needs to keep in mind that the support is emulated or imitation -- it's not actually accessing the underlying mechanism. For example, accessing the registry is possible, but Mono creates a file-backed emulation of the registry and can only provide data that your application has stored in it to begin with. Something like trying to enumerate the NICs in the PC from the registry data will fail because those keys simply do not exist. You can also send the tool's output to Novell to get feedback on it."
http://www.builderau.com.au/program/dotnet/soa/Mono-2-0-NET-goes-no...

Reply Score: 1

Yuske Member since:
2005-07-28

don't you find it odd that your Mono apps compile to exe and dlls with the need for a Windows like registry on Linux/Mac?

Yes, that's being ignorant, because the .exe and dlls created by Mono indeed doesn't need the registry, is the for compatiblity for applications exported from windows to linux, is just there by choice and not by "need".

Reply Score: 4

adkilla Member since:
2005-07-07

You are not making sense, if the registry is optional then there would be no need to emulate it. Then developers could do without it since running on Mono would require porting anyway. Sheesh! Try running a few ASP.Net apps under Mono then come back and post here!

Also, how about creating standard ELF binaries on Linux instead of the windows PE junk?

Reply Score: 1

Yuske Member since:
2005-07-28

Sheesh! Try running a few ASP.Net apps under Mono then come back and post here!

Asp.Net applications use the Web.Config file, not the registry, wow, what an ignorant.

Reply Score: 4

maggot Member since:
2009-01-11

Actually he is partly right, I recall reading the Mono FAQ for ASP.Net warning devevelopers about the common porting problems and the registry was one of them.

Also you need to explicity use App.Config and Web.Config. Its not automatic.

Reply Score: 3

segedunum Member since:
2005-07-06

Yes, that's being ignorant, because the .exe and dlls created by Mono indeed doesn't need the registry, is the for compatiblity for applications exported from windows to linux

Speaking of ignorance..........

This is just something you lusers don't get and never will. I've been cool with that for a while. The vast, vast, vast majority of applications written for Mono are going to have been ported to Mono from Windows. Ergo, a great deal of applications use the registry for various reasons and if something compatible isn't available on Mono then Mono becomes useless because you can't port the application. I mean come on, why does Mono have its own registry implementation at all if it isn't 'needed'? Why is someone even talking about writing a GTK# registry editor?

I'm afraid all that happens is that rather than being a reasonable cross-platform way of getting applications up and running Mono is just going to be sucked into implementing ever more esoteric bits of Microsoft and Windows infrastructure in very imperfect ways.

Reply Score: 4

adkilla Member since:
2005-07-07

Thanks mate. For a moment there I thought I was alone among all these lamers that were voting this guy up.

-Ad

Reply Score: 1

Manuma Member since:
2005-07-28

wow, you are talking out of your ass already, in windows programming is not mandatory the use of the registry, in my almost 10 yeas of windows programing I've used the registry once, and then I rewrote the same funtion to use local .ini file. So, telling the best aproach for a windows application is to use the registry just show how ignorant you are, you are a vb6 wannabe programmer for Christ sake.

But since you are just the official anti mono troll, what could I spect?

Reply Score: 4

Yuske Member since:
2005-07-28

Well, you just said it all, no need for me to reply to his ignorance. You already did a good job.

Reply Score: 2

adkilla Member since:
2005-07-07

Hmm, besides the personal attacks any links to MS documentation to prove your so-called expertise? Hmm?

Or are you just as good as blowing hot air as the rest of the .Net developer posers?

-Ad

Reply Score: 0

t3RRa Member since:
2005-11-22

You are just ignorance as other people say and your quote proves that. Where in the quote says that you must use registry or so? It seems like Mono guys added emulation to that for completeness sake so to make mono compatible as much as possible. What is the matter with that?

Reply Score: 1

adkilla Member since:
2005-07-07

I am not aware that the .net is depended on the registry, in fact I have heard that .net was a way for microsoft of getting rid of dll/registry hell of COM/ACTIVEX. .net uses largly the GAC (global asembly Cash) for shared components, not the registry. For configuration it uses XML Configuration Files both on framework level as on application level.


First and foremost, the GAC is meant to cache NGENed assemblies and system components. It does not have any registry like functionality. So what are you trying to mean here? You may want to re-read your post.

The XML configuration files and MANIFESTs are mostly static and are meant to make it easy for editing by hand and are for setting configuration before the application loads. Application settings generated during runtime by a majority of .Net apps are stored in the registry.

-Ad

Reply Score: 2

Yuske Member since:
2005-07-28

Application settings generated during runtime by a majority of .Net apps are stored in the registry.

The .Net and Mono applicatios work with the App.config file(a XML file that store all the applicaitions settings), it doesn't nee the registry at all, even an amateur would know that.

Please, stop posting already, you are embarazing your self.

Reply Score: 3

segedunum Member since:
2005-07-06

The .Net and Mono applicatios work with the App.config file(a XML file that store all the applicaitions settings), it doesn't nee the registry at all, even an amateur would know that.

1. An amateur would actually have a clue what App.config is for which is why he wrote this:

"The XML configuration files and MANIFESTs are mostly static and are meant to make it easy for editing by hand and are for setting configuration before the application loads. Application settings generated during runtime by a majority of .Net apps are stored in the registry."


2. The vast majority of .Net applications are ported from the .Net world to Mono. Ergo, you are bound by what goes on in the Windows based .Net world no matter how many times you write "It only uses App.config you luzer!"

3. You have to explicitly use App.config, it isn't required and it is intended for static global application settings. I'm not even sure App.config can be edited programmatically either. It's certainly not well advertised.

4. App.config is something that only an administrator will have access to and shouldn't be written by the application directly. The registry is certainly the only way of reliably getting per-user settings or setting on the fly application settings, or bunging something in Application Data - which is Windows specific incidentally. A spectacular number of .Net apps do this, and Mono needs to handle it otherwise porting is a no-go.

Please, stop posting already, you are embarazing your self.

You're only embarrassing yourself, because if you think that .Net applications all explicitly use App.config for all of their settings (not what it is designed for incidentally) and there is no reason for registry usage in Mono (which there obviously is because you've even been given a link to someone talking of a GTK registry editor to Mono's already built-in registry) then you have no clue whatsoever. Anyone who gives a single thoroughly inciteful comment consisting only of 'Mono rocks' is a few rocks short of a quarry themselves.

Sorry, but porting .Net applications to Mono and other platforms is not as simple as you would so dearly love to make out.

Edited 2009-01-11 19:10 UTC

Reply Score: 1

google_ninja Member since:
2006-02-05

You should stop correcting people about things you know nothing about.

The registry is the old school way of doing configuration. App.config is the way that all .net apps are supposed to use. There is an entire namespace devoted to working with these files in System.Configuration. When using the .net configuration APIs, you specify whether you want to do application or user specific changes. If it is user specific, an app.config is generated in that users appdata folder.

You obviously know nothing about .net development, so why in the world would you jump in and correct the OP? I have been doing .net apps for about 3 years now and am very active in the .net open source community, and the only times I every see registry being used is when dealing with a legacy platform (like COM)

Edited 2009-01-11 21:50 UTC

Reply Score: 3

segedunum Member since:
2005-07-06

You should stop correcting people about things you know nothing about. The registry is the old school way of doing configuration. App.config is the way that all .net apps are supposed to use.

I've just explained to you what App.config is for and where it is used. It is not intended to be used for dynamic configuration settings that a great many applications have a need for. Persisting values to App.config when the application is running and using it in that way has never been advised. About all it's good for is connection strings to databases and application wide and user specific settings for configuring the app at startup that aren't going to change much. It's a command line switch replacement really.

For crying out loud. Why on Earth do you think it's called App.config? Because it is strictly for the app configuration. Developers have a wide need to store a great deal of persistable information beyond static application settings. You have to look at other methods such as the registry (well, it's already there) or isolated storage of come kind or roll your own. It gets even more complicated with thread safety.

When using the .net configuration APIs, you specify whether you want to do application or user specific changes.

For quite a while Microsoft hadn't even thought of application settings for particular users! It's really only useful in the development process for testing more than anything else so you don't end up with a proliferation of various settings in source control for different environments. That's why it is a text file after all, as it makes this easier. For other things, it's not the right solution.

You obviously know nothing about .net development, so why in the world would you jump in and correct the OP? I have been doing .net apps for about 3 years now and am very active in the .net open source community..........

ROTFL.

Well, I hope your applications aren't doing anything terribly complex and you obviously missed the memo on how App.config is used and what it is intended for for someone so active in the .Net community, that's all I've got to say.

....and the only times I every see registry being used is when dealing with a legacy platform (like COM)

You need to get out a lot more. Once again, if it was that easy Mono wouldn't have to deal with the registry in ported apps. It quite clearly does.

Reply Score: 2

lsls Member since:
2006-11-13

"When using the .net configuration APIs, you specify whether you want to do application or user specific changes.

For quite a while Microsoft hadn't even thought of application settings for particular users!
"

FYI, since version 2.0, .NET supports per-user application settings. Those are not stored in app.config, but in a user.config file in the user's app data dir.

Reply Score: 1

Manuma Member since:
2005-07-28

WTF? dude, stfu already, what a clueles troll. The app.config file is part of the domain of the application, and since all .NET applications run in a sandbox the .exe and the app.config run in the same domain.

The manifest is just to let know vista that it will need admin. priviledges, but this is in general, even Java apps. would need a manifest for the same porpose, because is a requirement of the OS, and is for all the applications, cross platform or not.

Im really getting tired of your clueless none sense trollish, so please, DON'T TALL ABOUT THINGS YOU DON'T KNOW JUST FOR TROLLING.

Reply Score: 4

segedunum Member since:
2005-07-06

WTF? dude, stfu already, what a clueles troll. The app.config file is part of the domain of the application, and since all .NET applications run in a sandbox the .exe and the app.config run in the same domain. The manifest is just to let know vista that it will need admin. priviledges..............

The issue here is how application developers are dealing with persistable storage of settings, perhaps on a per-user basis, that are amended and used on-the-fly by the application, with all the issues that entails.

Since you clearly didn't understand what App.config is actually for I'm moderately interested in what this meaningless load of claptrap has to do with that?

Reply Score: 2

adkilla Member since:
2005-07-07

Then both of you noobs are welcome to point out to segedunum and me with links from MS documentation, that what you claim is the new way of doing things.

-Ad

Reply Score: 0

google_ninja Member since:
2006-02-05

Look at *anything* in all of system.configuration. There are a few hundred classes, all of which have to do with app.config and user.config, not the registry

http://msdn.microsoft.com/en-us/library/system.configuration.aspx

a google of "configuration .net" would have led you to about 37 million pages all talking about it, again, nothing to do with the registry

http://www.google.ca/search?hl=en&rlz=1C1GGLS_enCA309CA309&sa=X&oi=...

If you don't want to wade through millions of blog posts, here is a pretty good tutorial on codeproject, complete with examples on how to use the configuration api. Again, nothing to do with the registry

http://www.codeproject.com/KB/cs/SystemConfiguration.aspx

Reply Score: 2

adkilla Member since:
2005-07-07

These links do not state that app.config and user.config are meant replace storage of configuration that is handled by the registry in .Net applications.

I have posted in this thread about those APIs and are nothing new to me. What you still haven't proven is that MS expects .Net developers to use these classes and not the registry! Get it?

-Ad

Reply Score: 0

segedunum Member since:
2005-07-06

This is null and void on a few levels:

a google of "configuration .net" would have led you to about 37 million pages all talking about it, again, nothing to do with the registry

Great, except this has absolutely nothing to do with configuration of the application. It is about persistable settings and data that needs to be read and written by the application in a reasonably fluid way (short of using a database). App.config does not fit this use case and Microsoft will disown you if you try. If you'd read any of those pages you would have found that out.

Again, nothing to do with the registry

You keep writing 'nothing to do with the registry' as if that will somehow magicallymake every .Net application ported to Mono Ok, but it doesn't as has been consistently pointed out in this thread, explain why Mono has had to engineer registry support in if .Net applications have 'nothing to do with the registry'. The above use case that I have described, I would hazard a very good guess, is exactly why.

Reply Score: 2

Toad Member since:
2005-11-27


First and foremost, the GAC is meant to cache NGENed assemblies and system components. It does not have any registry like functionality. So what are you trying to mean here? You may want to re-read your post.

Stop implying things, its obvious what I mean - reread what I wrote in that paragraph, I challenge you to find any factual error (here is the paragraph).

I am not aware that the .net is depended on the registry, in fact I have heard that .net was a way for microsoft of getting rid of dll/registry hell of COM/ACTIVEX. .net uses largly the GAC (global asembly Cash) for shared components, not the registry. For configuration it uses XML Configuration Files both on framework level as on application level.



The XML configuration files and MANIFESTs are mostly static and are meant to make it easy for editing by hand and are for setting configuration before the application loads.

You are not truthful, XML configuration files in .net are not limited to static data. Infact there are API to generate events when data is changed in configuration files.

And why are you talking about the MANIFEST? Its usage is for meta-information containing information about the binnary code, and is stored in inside the .exe and .dll, it has nothing to do with Application settings, infact the MANIFEST was invented by microsoft to remove the dependency of the registry, before .net microsoft stored this type of information in the registry (COM/ACTIVEX).

Application settings generated during runtime by a majority of .Net apps are stored in the registry.

Of course you can access/use the Registry from .net, as I am sure you can from JAVA too. And if you do that, your application is limited to Windows regardless if you use Java or .net. I manage a programming group developing in .net. None of our application use the Registry, or needs to use the registry. And if you read what Microsoft recomends, you will see that they recomends that application should NOT use the registry, and in fact allow XCOPY installation.

I was factual in what I wrote, and I acknowledged that some of microsoft implementation of .net depended on the registry and win32. You on the other side have been vague, and some of what you have written has been outright wrong.

Reply Score: 3

Yuske Member since:
2005-07-28

We've had this experience before when attempting to modify the configuration file. But because the user had no permission to write to "Program Files" directory this was not recommended. You cannot assume the user will always be administrator when using your app!

If a user doens't have priviledge to write to the program files directory then you use a manifest, the manifest will allow to the user to read tge app.config file, you need to do more investigation, or you are a very bad programmer.

"Charlatan" is a spanish word tha mean
something like scammer, I can write some words in spanish too, "Usted señor es un troll ignorante".

Reply Score: 2

adkilla Member since:
2005-07-07

Sheesh, I guess you have a lot to learn besides .Net. The word charlatan I've used is an English word:
http://www.merriam-webster.com/dictionary/Charlatan

You are welcome to rebuke my post with actual references to MS documentation to support your claims.

-Ad

Reply Score: 2

Toad Member since:
2005-11-27

I see you couldn't find anything wrong in what I wrote...

If you are really a pro like you fictitiously claim to be then you would provide some links that back your claim. You have yet to explain why you brought up the GAC which has little to nothing to do with the registry.

If you had any knowledge, you should know that COM that preceded .net used registry to enable COM components (.exe,.dll). It stored information about version, interfaces clasid progid and much more in the registry, metadata that in .net is stored either in .net assembly or GAC, to register .dll in GAC is optional in .net, but is used to share componets, and manage version.
I just showed you that with .net microsoft HAS REMOVED the dependency from the registry. This is basic knowledge.


FYI the configuration files accessible by System.Configuration have the following drawbacks:
[i]"You use one of the Save methods to write configuration information. Note that the user or process that writes must have the following permissions: ....

Of course files must have right permission, this is basic both in Windows as in Linux...

Instead an MVP advised us to use the registry as MS has recommended here...

I would suggest that you shoose better advisors in the future. Registry is the OLD way of storing application data.

If you do not have any legitimate links to back up your so called facts, then you sir are a charlatan.

I see that I hit a nerve somewhere...
I won't spend any of mine time for you, I dislike fanboys that let their libido gets in their way. You are welcome to post any inaccuracy on what I have written.
[/q]

Reply Score: 2

adkilla Member since:
2005-07-07

You are welcome to back up your claims with actual references to MS documentation. Until then what you post here is either inaccurate or fraudulent.

Oh, just because I expose you for the charlatan you are I am a fanboy? Try supporting your claims buddy, your blind MS fanboism doesn't bode well you.

Reply Score: 0

lsls Member since:
2006-11-13

The origin of this whole discussion is this ambiguous sentence:

I mean come on, don't you find it odd that your Mono apps compile to exe and dlls with the need for a Windows like registry on Linux/Mac?


I think everybody is interpreting this sentence as "Mono compiles to exe/dll, and due to this fact, it needs a Windows like registry". Interpreted in this way, the sentence is obviously wrong, since Mono nor .NET require the registry to locate and load exe/dlls (and that's why the GAC was introduced in the discussion).

After reading your replies, I think you were using exe/dll and the registry as two independent examples of Windows technology brought to Linux/Mac. Interpreted in this way, the validity of the sentence is also debatable.

I personally don't find anything odd about using dll/exe in Linux. At least not odder than using .class or other extensions tied to languages or frameworks. Exe/dll files are based on the Portable Executable (PE) format, which is used by Windows, but not deeply tied to it (in fact, it is based on a modified version of the Unix COFF file format).

About the registry, if you want to imply that you need the registry to write .net applications, that's not true. The .NET framework includes classes for accessing the registry, but you don't need to use them. The System.Configuration api provides all you need for reading/writing application settings, and you are not forced to read/write configuration files from "Program Files". The settings infrastructure stores user specific settings into the users directory. Visual Studio even has a visual designer for managing application settings. In any case, the settings infrastructure is fully pluggable and could use a database backed if you wanted. You'll find more info here: http://msdn.microsoft.com/en-us/library/8eyb2ct1(VS.80).aspx

Reply Score: 2

issvb Member since:
2009-01-12

We've had this experience before when attempting to modify the configuration file. But because the user had no permission to write to "Program Files" directory this was not recommended. You cannot assume the user will always be administrator when using your app!

If a non-administrator user should be able to edit the configuration file, maybe you shouldn't store this file in the Program Files directory? Maybe you could use the AppData directory for this ;)

Reply Score: 1

anarxia Member since:
2006-06-02

It's actually very hard to access the registry from Java. You need JNI to do that.

Reply Score: 1

pantheraleo Member since:
2007-03-07

It's actually very hard to access the registry from Java. You need JNI to do that.


Not true. The Java Preferences API in Windows uses the Windows registry as its default backing store. So using the Java Preferences API, you can read and write to the Windows registry just fine. No JNI required.

Edited 2009-01-13 13:48 UTC

Reply Score: 1

v ...
by Yuske on Sun 11th Jan 2009 16:27 UTC
Comment by satan666
by satan666 on Sun 11th Jan 2009 19:47 UTC
satan666
Member since:
2008-04-18

Java is a better choice than C# in many ways.
1. Java is a more capable and more portable programming language.
2. Java is Open Source, C# is not.
3. By using C# applications, by programming in C# (especially on platforms other than Windows) you actually help Microsoft dominate the world.

Avoid Mono, Moonlight, Novell and Microsoft and maybe there is still hope for a better world.

Edited 2009-01-11 19:57 UTC

Reply Score: 0

RE: Comment by satan666
by Nelson on Sun 11th Jan 2009 20:15 UTC in reply to "Comment by satan666"
Nelson Member since:
2005-11-29

Java is a better choice than C# in many ways.
1. Java is a more capable and more portable programming language.


What? How? That's certainly not what I've taken away from it in my years of using C#.


2. Java is Open Source, C# is not.


ECMA-334 is the C# Language Specification.


3. By using C# applications, by programming in C# (especially on platforms other than Windows) you actually help Microsoft dominate the world.


Lol.

Reply Score: 6

v RE[2]: Comment by satan666
by adkilla on Sun 11th Jan 2009 21:19 UTC in reply to "RE: Comment by satan666"
RE[3]: Comment by satan666
by Manuma on Sun 11th Jan 2009 22:45 UTC in reply to "RE[2]: Comment by satan666"
Manuma Member since:
2005-07-28

So, firsth the "registry api" and now the API, dude, admit you don't like mono because it comes from a MS idea, nobody will put a gun in your head to use it, and let the people who really know enjoy it.

Reply Score: 3

RE[3]: Comment by satan666
by Nelson on Sun 11th Jan 2009 23:52 UTC in reply to "RE[2]: Comment by satan666"
Nelson Member since:
2005-11-29



None of which are required for the .NET Framework to run. It is perfectly fine for other operating systems to implement their own equivalent of those libraries.

A language and framework being cross platform does not inherently mean that everything written for that language and framework is platform independent.

Just like I do not expect every application I compile with GCC to be write-once, run-anywhere, I do not expect this with 100% of .NET Applications.

Are you done spreading FUD?

Reply Score: 3

RE[4]: Comment by satan666
by adkilla on Mon 12th Jan 2009 05:38 UTC in reply to "RE[3]: Comment by satan666"
adkilla Member since:
2005-07-07

Those APIs are part of the .Net framework. The contents of those links are real, they are not FUD!

-Ad

Reply Score: 1

RE[5]: Comment by satan666
by t3RRa on Mon 12th Jan 2009 09:38 UTC in reply to "RE[4]: Comment by satan666"
t3RRa Member since:
2005-11-22

Mono is just an implementation of .NET created by <Microsoft> which is developed on <Windows>. And therefore it is quite sensible that Microsoft implemented classes to access registry to make .NET to cooperate with its native applications. So to make Mono compatible with .NET as much as possible, they better implement anything that Microsoft implemented. There is no big deal. I don't really get what is the problem with you. So do you want a crippled implementation which wouldn't work near 100% because you don't like some part of it? Then why not just fork Mono, remove unwanted stuff from it and use it in your own sake? Not everyone thinks the same way as you do. Please..

Reply Score: 1

RE[6]: Comment by satan666
by adkilla on Mon 12th Jan 2009 10:04 UTC in reply to "RE[5]: Comment by satan666"
adkilla Member since:
2005-07-07

Now you are claiming Mono is near 100%? Have you actually even tried to use Mono for development or are you just delusional? Mono has always been implementing an incomplete .Net framework since v1.0.

The following .Net technologies are unsupported and are unlikely to be completed in Mono:
* Windows Presentation Foundation (.NET 3.0).
* Windows Workflow Foundation (.NET 3.0).
* Code Access Security (.NET 1.0).
* System.Management (All Versions)

Read about it here:
http://mono-project.com/Roadmap

-Ad

Reply Score: 2

RE[7]: Comment by satan666
by t3RRa on Wed 14th Jan 2009 03:37 UTC in reply to "RE[6]: Comment by satan666"
t3RRa Member since:
2005-11-22

I was saying general stuff not Mono specific. And also I meant that dropping a part of it is also sacrificing compatibility. It wasn't the point of my post either. Do you have a kind of problem getting the point? Sacrificing compatibility because you don't want a part of it? doesn't matter other people might need that part of it? Great! not.

Reply Score: 1

v RE: Comment by satan666
by diegoviola on Sun 11th Jan 2009 21:16 UTC in reply to "Comment by satan666"
v RE[2]: Comment by satan666
by lsls on Sun 11th Jan 2009 23:38 UTC in reply to "RE: Comment by satan666"
RE[2]: Comment by satan666
by Nelson on Sun 11th Jan 2009 23:57 UTC in reply to "RE: Comment by satan666"
Nelson Member since:
2005-11-29

I do not get this unnecessary demonizing of the Mono community. They do Linux an immense favor by adding such a powerful language and framework to the platform.

I get it, some people are scared/hate Microsoft and proprietary platforms, but this is none of the sort. While I don't agree with Mono implementing patented and proprietary APIs (Outside those Microsoft has extended their OSP to), I do see nothing wrong with providing a clean implementation with OSS platforms built on top (See GTK# and MonoDevelop for awesome results of the Mono team's hard work).

I applaud them for their tireless efforts, and I wish some people could be more open minded.

Reply Score: 4

RE[3]: Comment by satan666
by adkilla on Mon 12th Jan 2009 05:35 UTC in reply to "RE[2]: Comment by satan666"
adkilla Member since:
2005-07-07

If you go back to my original post:

While I applaud the efforts of the Mono people, they attempts at bringing Microsoft platform technologies to other platforms seems odd as it tries to bring MS's concepts of an operating environment to other platforms.

I mean come on, don't you find it odd that your Mono apps compile to exe and dlls with the need for a Windows like registry on Linux/Mac? Why force MS's concept of an operating environment and application behavior in other OSes?


I was pointing out that Mono should develop their own way or doing things that are platform agnostic instead of merely copying MS onto other platforms. What's wrong with that? Why let the future of Mono be determined by MS alone? Why can't developers have a true cross-platform framework that isn't "Windows everywhere"?

-Ad

Reply Score: 2

RE: Comment by satan666
by BallmerKnowsBest on Mon 12th Jan 2009 15:49 UTC in reply to "Comment by satan666"
BallmerKnowsBest Member since:
2008-06-02

Avoid Mono, Moonlight, Novell and Microsoft and maybe there is still hope for a better world.


So basically, you're jealous of Microsoft's success and you think they should be held back - since the Open Sores eunuchs clearly aren't capable of competing on a level playing field.

Maybe all Microsoft employees should be given forcible lobotomies, Harrison Bergeron-style. The GNU/Freetards might actually stand a chance of catching up (not likely, though).

Reply Score: 1

wow, i mean just wow....
by karl on Mon 12th Jan 2009 14:09 UTC
karl
Member since:
2005-07-06

I come to this thread expecting a little bit of discussion about Mono being used for cross-platform app development and the obligatory anti-mono trolls who inevitably show up in such threads. Instead I am treated to a half-dozen individuals who are obviously somewhat knowledgable about .Net coding and Mono's implementation of .Net bashing each other left and right arguing about things which only .Net developers even have a clue about.

If it were not for the vitriol I might even think some of what was being said was informative. But alas whatever informative value was burried by deliberate misunderstanding, name calling, and continuous bashing.

I must admit however that this thread went far beyond the normal anti-mono trolling which is par course for such threads. Perhaps the trolls are getting more sophisticated.

Now to try to add something constructive:

Getting upset about .exe and .dlls's, being windows-specific things brought into Linux(and other platforms)-seems on the surface to be really, really silly. The comments about the registry seem to indicate that all platforms supported by mono are "invaded" by the Evil(TM) MS-Windows registry. How preposterous.

The fact is that one of the first and foremost goals of Mono-as stated by Miguel- was to make it easier for windows .Net apps to be ported to other platforms and to offer an attractive alternative to .Net to get .Net devs who hitherto have only written for Windows to write their apps so that via Mono they can become cross-platform. To this end Mono by neccessity must have some number of kludges (taken from Windows) to ease this process-which means taking into account that some .Net devs indeed did use the registry.

This stuff is there for those devs who used that functionality-not because it is necessary, not because Miguel wants to faithfully replicate each and every MS tech in Mono-but because if a .Net dev did use the registry in their app they would not be faced with something completely insurmountable when first attempting to port it to mono. Seems quite reasonable to me. Miguel wants Mono to be an attractive alternative to .Net, Mono has been written with this mind since day one. Some devs will complain that not Mono is not absolutely identitical to .Net. Others will complain that Mono is way too much like .Net (including evil conspiracies of MS to overtake free software). Give me a break- no matter what Mono does some devs are going to be upset-given that the devs encompasses a large population of people comming from remarkably different backgrounds with different goals and different values. Surprise, Surprise.

Adkilla if I understand you correctly you are lamenting at once a) the fact that Mono has implemented a bunch of MS only kludges which have no bearing in a cross platform world and b) the fact that mono has not completely implemented each and every specific .Net tech. To be honest with ou I have no idea how Mono could not be guilty of a) if they do a good job at b). Seems to me like it is a no-win situation for Mono from your perspective. (If I misunderstood you please correct me)

Now how could Mono address your concerns ? If Mono were to become significantly attractive enough to .Net devs in the Windows world(the only place where .Net as such works) that devs were inclined to start coding in Mono and not for MS-exclusive .Net then Mono would have to start addressing a range of issues and could set themselves as the standard-ie. they could develop their own tech for each and every platform they support and apps would be written from the beginning to be cross-platform and only if the app dev only wanted their app to run on one platform (ie. windows) would they then convert their Mono app to the specific MS-exclusive tech in question (ie.registry).


If this were to come to pass then Mono would not contain a bunch of kludges for compatibility with apps written exclusively for Windows. Yet Mono is probably still a long way from attaining this goal-so far away that it is probably completely ridiculous to judge Mono according to it. On Windows Mono is really only an alternative to .Net for those devs and those projects where cross-platform compatibilty is an value-add to said projects. Mono is not a superior .Net implementation for apps written exclusively for windows. There may be some specific point where Mono is superior to .Net on windows, but .Net on windows encompasses much more than Mono. Yet the moment one considers other platforms Mono is the only answer because .Net only exists for windows. This is where Mono encompasses far much more than .Net. Last i remember .Net did not offer me a Gtk# implementation, or a cocoa#, did not offer me POSIX integration etc.

If I was a windows dev who wrote .Net apps exclusively for windows I would find Mono quite deficient-I would lament that this that and the other thing were not completely implemented in Mono and that I had to do a bunch of extra stuff, some quite tedious, to get my app up and running. But then again I would not be the primary target of Mono- it was not written for me. If I were a dev who was tasked to write an app leveraging .Net code for multiple different platforms I would probably be praising Mono from the left and the right and extolling its features -because without Mono it would be impossible to leverage my .Net code in a cross-platform app.

As is the case now-more and more apps are being written for Mono to take .Net cross-platform-for the ever growing number of devs who are writting such apps the superiority of .Net (ie. it's specifc tech which is not present or only partially implemented in Mono) is starting to fade in constrast to the advantages which Mono offers. In time there will be devs who look at .Net and see it as something quite deficient because it is not cross-platform, because it does not tie into other OS'S/toolkits etc. The number of devs who look at things this way now is probably quite small in contrast to the untold legions of .Net programmers programming away in utter oblivion to the existence of anything other than MS. But there are more and more of them each day-and Mono is bootstrapping a small industry -more and more companies leveraging Mono to carve out markets which hitherto simply did not exist.

This article started off by pointing out all of the apps written in Mono which run on the iphone. All I can say is wow-when Miguel started Mono Apple had just released OS X 1.0 and intel-macs were not even being specuated on and noone ever even imagined Apple producing phones. Now these phones from Apple run Mono apps using tech originally written exclusively for windows which have successfully been made cross-platform by Mono. I find that insanely cool. I wonder how many of those who originally created .Net ever thought that their tech would find it's way (via Mono) on Apples then non-existant iphones. Hats off to the Mono guys.

Reply Score: 5

RE: wow, i mean just wow....
by adkilla on Mon 12th Jan 2009 15:25 UTC in reply to "wow, i mean just wow...."
adkilla Member since:
2005-07-07

Getting upset about .exe and .dlls's, being windows-specific things brought into Linux(and other platforms)-seems on the surface to be really, really silly.

You might want to read my post here before jumping to that conclusion:
http://osnews.com/thread?343134

Adkilla if I understand you correctly you are lamenting at once a) the fact that Mono has implemented a bunch of MS only kludges which have no bearing in a cross platform world and b) the fact that mono has not completely implemented each and every specific .Net tech. To be honest with ou I have no idea how Mono could not be guilty of a) if they do a good job at b). Seems to me like it is a no-win situation for Mono from your perspective. (If I misunderstood you please correct me)

Mono was never a complete implementation of .Net and will never be. They are constantly playing catch up with MS while trying to fit .Net cross platform.

Instead of cherry-picking .Net functionality that works well cross-platform and innovating the rest on their own, they have decided to be a incomplete copy-cat. I strongly believe that Miguel and his talented team are capable of innovating away from MS to provide a better alternative that works as well if not better. I also believe that Mono would be much more attractive if it were to promote itself as cross-platform CLR with a well designed framework, than a mere .Net copycat with a sub-par cross-platform design.

I will give an example where there were initiatives to make Mono more than .Net. The #WT initiative was a good example. But the insistence of Mono stay the course with System.Windows.Forms killed it. Failing to make S.W.F useable with native L&F on platforms other than Windows, they decided to take the Cocoa#/GTK# course instead. If they were to stick with #WT, it would have been a real cross-platform contender GUI wise. But no, they decided to take the half-baked approach instead. Till this day they do not have unified cross-platform GUI frameworks that Java enjoys.

From my involvement with many experienced .Net developers, I've learnt that they are aware of Mono but consider it an inferior copy that attempts to bring .Net to Linux. Some (like me) have expressed that they would switch to Mono in a heartbeat if Mono would steer their own course. Heck, we would even switch fully to Mono and dump .Net (even on Windows), if Mono would try be an elegant framework and runtime (that is compatible with MS CLR) that works cross-platform as its goal. Some of us took the attempt to share this with the Mono team over IRC to only be shot down. We could understand that Novell has now put themselves in a licensing situation with MS over .Net patents that would make it hard for them to back down. Also providing a much better framework than .Net that is also cross-platform could be implied as turning the tables against MS in its own game.

Thus we are stuck with the Mono it is today.
Now after hearing mine, what are your thoughts?

-Ad

Edited 2009-01-12 15:43 UTC

Reply Score: 0

RE[2]: wow, i mean just wow....
by karl on Mon 12th Jan 2009 17:13 UTC in reply to "RE: wow, i mean just wow...."
karl Member since:
2005-07-06

Adkilla,


I would be lying to you if I told you I was privy to the rational behind Monos choices regarding exe/dll and S.W.F. Over the years I have seen many bitterly complain about both and these two items have been often cited as reasons against Mono. But from my vantage point I think that harping on these decisions detracts from the concrete benefits that have been realized by the Mono project. In other words: one is left comparing what-if's with the reality at hand-and frankly I do not think the reality at hand is all that bad.

Although far from optimal from the total cross-platform perspective I whole heartedly appreciate the work that was done to create Gtk#/cocoa#. Right now I have at least a dozen applications installed on my machine which make use of Gtk#- good applications which I enjoy using and which provide me with tangible benefits. The availability of Gtk# means that some of the brightest devs who support Linux are using this toolset to create applications which I enjoy using.

To be honest is it really any surprise that Miguel chose to poor more effort into bringing Mono to the GNOME desktop than to focusing on SWF? After all who was it who started the GNOME project ? Right, it was Miguel. Surely you have heard the endless tirade against Miguel because of his having supposedly "sold out" to the Evil(TM) MS world. You cannot make everyone happy: You cannot be everyones friend. With each decision you make you will gain some friends and lose some-such is life.

In Miguels estimation Linux was lacking in a comprehensive framework for rapid application development-he saw Mono as a solution to this problem: bringing the ease of app development of .Net to the Linux GNOME desktop. And for some non-insignificant number of GNOME hackers he was right-they embraced this tech and started making desktop apps which many user enjoy using. Furthermore I believe Mono was instrumental in Vala being so aggresively pursued-a lot of hackers these days do not want to break their heads on code written in C.

Gtk# illustrated an alternative way to create modern Linux desktop apps and if anything spurred more and more devs to invest energy in trying to bring the advantages of the programming styles present in .Net to Linux-and I believe that Vala is but one example of this-not that there is a direct link between Mono and Vala but that both are outlets for programmers wishing to have easier and better tools for creating applications which easens the burden of writing and maintaing applications. There have been calls from all quarters for years for GNOME to adopt a higher level language for app development-the political controversy about licensing pitted Gtk# versus Java, Vala is emerging as a 3rd alternative which has none of this baggage.

That Miguel would have wanted to see the fruits of his labor in creating Mono be available and immediately usable for GNOME hackers is hardly surprising-this is the community he came from, and he and others worked hard at creating a really good implementation of .Net custom-tailored to the Linux GNOME desktop, despite being attacked from the left and right continuously.

To a lesser extent Mono then extended this focus to cocoa#. From what I understand there are now a number of Mac apps written in cocoa#. Both Gtk# and cocoa# are targetting current devs in these respective communities offering them tools which have proven quite valuable to them. When we talk about devs we are talking for the most part about devs who are already committed to one OS/platform-only some of those devs are working on projects which are designed for cross-platform functionality. Cross-platform functionality is frequently an add-on, ie. once the initial app is completed and runs on *a* platform devs wish to extend it to other platforms (ie. google chrome). The number of devs working on projects which from conception are designed to be multi-platform is dwarfed by those working on apps for one platform which are then extended to become cross-platform. Mono made a strategic decision in choosing to focus on Gtk# and cocoa#. The Mono team also is fully cognisant of the conundrum where at once people want multi-platform apps and at the same time constantly bitch and moan about the lack of platform-specific integration(ie. trully multi-platform apps tend to be "at home" nowhere).

From the vantage point of those who wish to see Mono as a purely multi-platform framework surely many are greatly disappointed in Mono. But Mono is an alternative implementation of .Net which at once is custom-tailored to both Linux (via Gtk#) and Mac (via cocoa#) and which on these platform provides very "native" applications(at least this is true for Linux and probably to a lesser extent for Mac-I don't have a Mac so I can't say much about the degree of Mono's success in making itself "native" on Mac) AND at the same time Mono is generic enough to make it cross-platform for a wide range of apps (server(Second Life) and client) on a trully impressive range of platforms (Wii, iphone, Android, Maemo etc.). You could fault them for trying to much, but not for not trying hard enough.

I suspect that the decision against SWF had a bunch of factors. I think Mainsoft and the agreements between Mainsoft and Mono probably played a role in this. It is also possible that there were more patent concerns in this area and that MS had told them not to pursue this. And Miguel and his team have been privy to the planning of .Net far beyond what most .Net devs are and may have seen SWF as being but a short-lived tech which Microsoft itself would be leaving behind( I am not a .Net coder and no remarkably little about all the ins and outs but wasn't Avalon supposed to superced SWF ?-could be totally wrong but IIRC Miguel even mentioned this 2-3 years ago). At any rate I sill question the extent to which Mono could have created a multi-platform GUI which would not have been subject to derision by those who lament platform-specific integration. Java is only now becomming viable in this regard -people have bitched and moaned about Java being alien everywhere for so long-Java was practically forked for SWT to address this issue. Toolkits like Wx have only succeeded in addressing this issue to the extent that they have been successful and from my POV that success has been marginal. Qt seems to have the best cross-platform support-but there are issues there as well (licensing, costs, c++).

As regards the exe/dll: I simply do not see this as being such a big issue. Firstly I suspect if Mono was ever to reach the point that people considered Mono before considering .Net (ie. Mono became the standard) that this could be changed-perhaps it should-but not when the number of Mono developers is dwarfed 100 to 1 by .Net developers. Secondly I have no clue as to what would be involved in creating a format which ran natively (ie. without ilrun and other mechanisms)-is such even doable? Now making Mono target ELF for Linux apps would make a lot of sense-but I suspect that lot of Mono development still takes place in MS Visual Studio-perhaps this plays a role in this decision-I really don't know-but you know I have never cringed seeing a dll file in my file system, and I have not gotten a rash due to seeing exe files. Mono apps are usually started with a bash script -big friggin deal-do you *really* care so much about whether Linux can make use of the RES chunk of the exe/dll file? I just don't get why this is a *deal-breaker*.

I guess my last question is this: you seem to be quite competent in .Net programming- what is preventing *you* from offering your skills to implement the things you so wish to see ? I am not currently an active programmer and I would need to invest an awful lot of time and energy to be able to even be able to code something more than hello-world in c#, but then again I am not lambasting Mono for it's shortcommings -au contraire I thank the Mono team and devs for their work.

Reply Score: 1

RE[3]: wow, i mean just wow....
by adkilla on Mon 12th Jan 2009 18:37 UTC in reply to "RE[2]: wow, i mean just wow...."
adkilla Member since:
2005-07-07

From the vantage point of those who wish to see Mono as a purely multi-platform framework surely many are greatly disappointed in Mono. But Mono is an alternative implementation of .Net which at once is custom-tailored to both Linux (via Gtk#) and Mac (via cocoa#) and which on these platform provides very "native" applications(at least this is true for Linux and probably to a lesser extent for Mac-I don't have a Mac so I can't say much about the degree of Mono's success in making itself "native" on Mac) AND at the same time Mono is generic enough to make it cross-platform for a wide range of apps (server(Second Life) and client) on a trully impressive range of platforms (Wii, iphone, Android, Maemo etc.). You could fault them for trying to much, but not for not trying hard enough.


Some key points about Mono that I'll pull from from their FAQ to clear some misconceptions:
What is Mono™ exactly?

The Mono Project is an open development initiative sponsored by Novell to develop an open source, UNIX version of the Microsoft .NET development platform. Its objective is to enable UNIX developers to build and deploy cross-platform .NET Applications. The project implements various technologies developed by Microsoft that have now been submitted to the ECMA for standardization.

What is the difference between Mono and the .NET Initiative?

The ".NET Initiative" is a somewhat nebulous company-wide effort by Microsoft, one part of which is a cross-platform development framework. Mono is an implementation of the development framework, but not an implementation of anything else related to the .NET Initiative, such as Passport or software-as-a-service.

Aren't you just copying someone else's work?

We are interested in providing the best tools for programmers to develop applications for Free Operating Systems. We also want to help provide the interoperability that will allow those systems to fit in with other standards. For more background, read the Mono Project white paper.


More is available here:
http://mono-project.com/FAQ:_General

I suspect that the decision against SWF had a bunch of factors. I think Mainsoft and the agreements between Mainsoft and Mono probably played a role in this. It is also possible that there were more patent concerns in this area and that MS had told them not to pursue this. And Miguel and his team have been privy to the planning of .Net far beyond what most .Net devs are and may have seen SWF as being but a short-lived tech which Microsoft itself would be leaving behind( I am not a .Net coder and no remarkably little about all the ins and outs but wasn't Avalon supposed to superced SWF ?-could be totally wrong but IIRC Miguel even mentioned this 2-3 years ago). At any rate I sill question the extent to which Mono could have created a multi-platform GUI which would not have been subject to derision by those who lament platform-specific integration. Java is only now becomming viable in this regard -people have bitched and moaned about Java being alien everywhere for so long-Java was practically forked for SWT to address this issue. Toolkits like Wx have only succeeded in addressing this issue to the extent that they have been successful and from my POV that success has been marginal. Qt seems to have the best cross-platform support-but there are issues there as well (licensing, costs, c++).


The #WT I mentioned earlier is a derivative of SWT. It did not require development completely from scratch.
If you have tracked the evolution of GUI toolkits, you may have noticed they have over time matured to fit in with the platform. Qt in its earlier incarnations was out of placed outside of Windows. But over time it has made design improvements and adapt itself even to GTK/GNOME L&F to better integrate with the DE. Qt has also improved so much on the Mac that an end-user of ours was hard pressed to weed it out as a non-Cocoa/Carbon app.
We've had the same experience with SWT. There is even a port of SWT underway for Cocoa64. Win64 support has been around for a long time.
While I agree there are GUI toolkit/frameworks that still have long ways to go (GTK on Windows/Mac and Swing on Windows), there are mature technologies to derive from.

As regards the exe/dll: I simply do not see this as being such a big issue. Firstly I suspect if Mono was ever to reach the point that people considered Mono before considering .Net (ie. Mono became the standard) that this could be changed-perhaps it should-but not when the number of Mono developers is dwarfed 100 to 1 by .Net developers. Secondly I have no clue as to what would be involved in creating a format which ran natively (ie. without ilrun and other mechanisms)-is such even doable? Now making Mono target ELF for Linux apps would make a lot of sense-but I suspect that lot of Mono development still takes place in MS Visual Studio-perhaps this plays a role in this decision-I really don't know-but you know I have never cringed seeing a dll file in my file system, and I have not gotten a rash due to seeing exe files. Mono apps are usually started with a bash script -big friggin deal-do you *really* care so much about whether Linux can make use of the RES chunk of the exe/dll file? I just don't get why this is a *deal-breaker*.


I am not disgusted by the sight of EXE/DLL, though I've had Linux admins that were confused that I sent them a Windows program for testing because of the EXE/DLL.

I was trying to point out that Mono applications could benefit more from native formats. For example, standard system tools like ldd are especially beneficial in cases where trouble shooting runtime dependencies are needed. This is doable just not done currently. Under Windows the Dependency Viewer provides similar functionality for Win32/Win64 native binaries. This includes .Net apps and assemblies as well. Using ldd in this manner could not happen under Linux unless the ELF binary is used.

I guess my last question is this: you seem to be quite competent in .Net programming- what is preventing *you* from offering your skills to implement the things you so wish to see ? I am not currently an active programmer and I would need to invest an awful lot of time and energy to be able to even be able to code something more than hello-world in c#, but then again I am not lambasting Mono for it's shortcommings -au contraire I thank the Mono team and devs for their work


From past experiences in OSS projects, I've learnt that it is key for a project to have firm supporters and stick with a clear goal. #WT was one of the biggest disappointment for me personally as I saw my contributions fall to wayside and the direction the Mono folks took instead. The original SharpDevelop team that sparked of #WT decided it was best to lay the project to rest and instead focus on consuming S.W.F. Lessons were learnt and I moved on to alternatives.

-Ad

Reply Score: 1

RE[2]: wow, i mean just wow....
by lsls on Mon 12th Jan 2009 20:32 UTC in reply to "RE: wow, i mean just wow...."
lsls Member since:
2006-11-13

Mono was never a complete implementation of .Net and will never be. They are constantly playing catch up with MS while trying to fit .Net cross platform.

Instead of cherry-picking .Net functionality that works well cross-platform and innovating the rest on their own, they have decided to be a incomplete copy-cat. I strongly believe that Miguel and his talented team are capable of innovating away from MS to provide a better alternative that works as well if not better. I also believe that Mono would be much more attractive if it were to promote itself as cross-platform CLR with a well designed framework, than a mere .Net copycat with a sub-par cross-platform design.


I think that Mono can be useful in many ways, and it is up to the community to make it evolve in different ways. I believe that the focus of the mono project has been adapted over time to the needs of the users.

See for example this interview to Miguel: http://news.netcraft.com/archives/2004/04/28/interview_with_miguel_...

In this interview Miguel says that Ximian was initially focused only on the core and, he says "what we wanted was to empower regular users to build applications for Linux".

also:

"the people who came and contributed software to the project were interested in Windows Forms, or ASP.Net or Web services or databases, which were part of the Microsoft stack"

I think that over the years, the Mono project has evolved from a focus on Linux development towards a focus on .NET portability, and that this shift has been due to user demand. This is understandable since there are thousands of developers and companies out there using .NET for developing their applications, and they see Mono as a fast path for migrating their applications to Linux. Beware that a big chunk of those applications are web applications, and in this area Mono can be a perfect replacement of MS's .NET.

Whatever is the focus, I think that what matters to Miguel is what better benefits Linux. Building a stack of libraries for easing Linux development is obviously good for Linux. Building a framework which eases the portability of applications from Windows to Linux is also good for Linux.

Yes, Mono is not a complete implementation of .NET and will always be playing catch up with MS. So, there will always be .NET applications which won't run on Mono. Is that a big issue? no, because there will still be many others which do run on Mono and Linux will be benefiting from it.


I will give an example where there were initiatives to make Mono more than .Net. The #WT initiative was a good example. But the insistence of Mono stay the course with System.Windows.Forms killed it.


You can't accuse Mono of killing WT#, that's not fair. It is true that the Mono team was focused on SWF and did not work on WT#, but that's probably because there was a lot of demand for SWF and very little for WT#.


Failing to make S.W.F useable with native L&F on platforms other than Windows, they decided to take the Cocoa#/GTK# course instead.


The development of GTK# started long before SWF or WT#.
See the ChangeLog (http://anonsvn.mono-project.com/viewvc/trunk/gtk-sharp/ChangeLog?re...). It started only a few months after Mono was announced.


If they were to stick with #WT, it would have been a real cross-platform contender GUI wise. But no, they decided to take the half-baked approach instead. Till this day they do not have unified cross-platform GUI frameworks that Java enjoys.


I understand that this is an interesting goal for you and other people, but I don't think this is a goal of the Mono team. Building a cross-platform GUI framework like Java would be a lot of work and would not benefit Linux as much as e.g. a complete ASP.NET implementation would.


From my involvement with many experienced .Net developers, I've learnt that they are aware of Mono but consider it an inferior copy that attempts to bring .Net to Linux. Some (like me) have expressed that they would switch to Mono in a heartbeat if Mono would steer their own course. Heck, we would even switch fully to Mono and dump .Net (even on Windows), if Mono would try be an elegant framework and runtime (that is compatible with MS CLR) that works cross-platform as its goal. Some of us took the attempt to share this with the Mono team over IRC to only be shot down.


I don't know how you could be shut down. Mono is free software, and anybody is free to build a new framework on top of it and pursue different goals. The Mono team can't avoid that.


We could understand that Novell has now put themselves in a licensing situation with MS over .Net patents that would make it hard for them to back down. Also providing a much better framework than .Net that is also cross-platform could be implied as turning the tables against MS in its own game.


I don't think that the relation of Novell with MS has much to do with the goals of the Mono project. As I said, I think it has more to do with user demand.

I understand that the current goal of Mono does not fit your needs, but you must understand that it does fit the needs of many other developers and companies. I don't think it is fair to bash Mono for having a different goal than yours, especially taking into account that you are free to take mono and built whatever framework you want on top of it.

Reply Score: 1

Oh Boy
by aesiamun on Mon 12th Jan 2009 15:09 UTC
aesiamun
Member since:
2005-06-29

The anti-ms fanbois are out today.

Reply Score: 2

Wow
by JeffS on Mon 12th Jan 2009 17:39 UTC
JeffS
Member since:
2005-07-12

Shame that most of this thread has been juvenile name calling and trolling.

I say this because the linked article is talking about some pretty fantastic technology.

All philosophical and licensing debates asside, I've always been impressed with Mono as a technology.

First Microsoft tried to embrace and extend Java directly, by adding their own extensions to their own implementation of Java that tied it to Windows. Sun sued them for that.

So Microsoft then embraced and extended Java by creating their own runtime/language that was very simimilar, but added their own cool goodies. The result was .Net CLR, Assemblies, and C#. No matter what camp you're from, these are simply great technology. And I'm saying that as a big Java/cross platform guy.

But MS did submit the CLI and C# to ECMA for standardization. Door open for someone to take it and run with it.

Enter Miguel and crew, and the creation of Mono. Mono, in my opinion, embraces and extendes MS .Net/C#, by adding cross platform capability, GTK#, and other goodies.

Enter really nice Mono GTK#/Gnome apps like Banshee, F-Spot, Blam, Gnome-Do, and MonoDevelop.

Enter stuff like MainSoft's product that adds ability to run ASP.Net stuff on JEE app servers.

Enter Moonlight, giving the ability to run Silverlight stuff on Linux.

Enter Untity, a Mono based games engine, which is obviously giving the ability to use Mono to build iPhone apps, as well as Wii and Xbox.

Enter Static linking and ahead of time compilation.

All great, great stuff.

And the ability to build apps and games for iPhone using Mono is truly a "killer app" for Mono. Let's face it, iPhone is one of the, if the, fastest growning platforms right now, along with other smart phone environments.

And there is aleady an impressive list of apps written in Mono for the iPhone.

Reply Score: 2

RE: Wow
by pantheraleo on Tue 13th Jan 2009 05:38 UTC in reply to "Wow"
pantheraleo Member since:
2007-03-07

> First Microsoft tried to embrace and extend
> Java directly, by adding their own extensions
> to their own implementation of Java that tied it
> to Windows. Sun sued them for that.

It was proven in a court of law that Microsoft intentionally introduced incompatibilities into their version of Java in an attempt to undermine Java. That's why Sun sued them. It was part of the whole laundry list of anti-trust claims against Microsoft from multiple other companies..

> But MS did submit the CLI and C# to ECMA
> for standardization. Door open for someone to
> take it and run with it.

The problem is that until Microsoft open sources the official .NET implementation, mono is always going to lag seriously behind .Net. And also, keep in mind that only the CLI and C# are standardized. Most of the .Net APIs are not. There are many features in .Net 3.5 for example, that, mono doesn't support, and probably never will. Porting .Net applications to mono often requires a significant amount of changes. And if you don't have the source code for the app, porting may also be impossible.

Mono is an interesting effort, sure. But right now, it comes NO where near the cross-platform capabilities of Java. And until Microsoft open sources the official .Net implementation, I doubt that it will ever compete with Java when it comes to truly cross-platform applications.

Edited 2009-01-13 05:39 UTC

Reply Score: 1

Porting .NET apps to mono...
by pantheraleo on Tue 13th Jan 2009 05:27 UTC
pantheraleo
Member since:
2007-03-07

Is not nearly as easy as some to think it is. Part of the problem is that mono always lags at least one full version behind the official .NET implementation from Microsoft. Furthermore, there are features of the official .NET implementation (particularly when it comes to GUI stuff) that are not supported in mono, and probably never will be.

Porting .NET apps to mono can be extremely frustrating and often requires major portions of code to be rewritten.

Reply Score: 1