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.
Thread beginning with comment 343103
To view parent comment, click here.
To read all comments associated with this story, please click here.
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 Parent 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 Parent Score: 2

adkilla Member since:
2005-07-07

I meant 2 things:
1. Mono/.Net apps compile to EXE/DLLs.
2. The above mentioned apps tend to expect the existence of a Windows registry.

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).


The Java .class files are bytcode files. They do not contain ELF sections or headers. They are only executable by the command-line java utility and jvm programatically. Similar concepts are used by Python, TCL, etc.

Now PE files are different from the above. PE files for example contain a RES section that is not useable elsewhere except on Windows. PE files also include a header that is used by Windows to determine how to execute it. On Mono this is not supported, you need to use ilrun to execute your apps. I can't for example execute a Mono app on Linux like this: ./mono_app.exe
So why bring this format to other platforms with little to no benefit? Why can't the Mono folks create them as ELF (when targeting Linux) and other executable formats for other platforms? Wouldn't this be more natural? Or at least settle on a cross-platform format that does not bring the PE baggage to other platforms.

...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...


I was rebuking a poser that suggested to use App.Config to store configuration info. Doing what he/she suggested requires access to "Program Files". Which I described would be a problem for non admin users.

What you seem to be referring to here is User.Config. This configuration is accessible through the LocalFileSettingsProvider class. This class did not exist prior to .Net 2.0 and apps written using Mono prior to 2.0 did not have this interface either. So guess what most .Net apps were using all this while to store their configurations? ;-)

Here are my references:
http://www.go-mono.org/docs/index.aspx?link=T%3ASystem.Configur...
http://msdn.microsoft.com/en-us/library/system.configuration.localf...).aspx

Also, I do not see any KB/MSDN articles from MS stating that using the registry for .Net apps is discouraged and that the System.Configuration API is the better way that should be used instead. Care to provide some official pointers on this?

-Ad

Reply Parent Score: 1