Hi, I've left some comments inline. Also, sorry about the double email, forgot to CC the list first.
In other words, I have thought from the beginning that the Microsoft
philosophy is wrong. In fact knowing the weakness of accommodating unknown, interoperable objects well has permitted me on several systems to survive -- without ever deploying anti-viral ware -- literally probably more than a million Windows viruses, with none ever unleashing. The trick to this has been wholly disabling ActiveX -- whereas Microsoft's interests in .Net are making that more impossible every day.
But .NET has built in security measures which prevent malware of any kind from taking over your system. Silverlight, the new browser plugin, contains a new simplified security system which makes it very difficult for anything to overtly install itself. You can't even access a file on the hardrive without going through a trusted path which (i believe) means popping up a file selection dialog for the user to select the file in. My Firefox installations for instance are always configured not to run
JavaScript. Even as I occasionally approve some JavaScript manually, I regularly object to much of its usage. It's plain unnecessary. But it is others' business if they do these things, and I do expect browsers to remain available which continue to provide means of eliminating potentially unwanted executability of any kind.
Lots of things are unneccessary. Coloured text is unneccesary. Hyperlinks are unneccessary. Colour images on web pages are unnecessary. However all three are very useful. I have found particularly that even relatively straightforward graphics
processes are extremely poorly performant compared to the tools I recently left behind.
I hope you weren't accessing the pixels one by one using GetPixel and SetPixel. They are known to be very slow and are the reason why the unsafe LockBits() method is offered which allows you to directly access the bytes of the image and write c-style code which is every bit as fast (or at least has the potential to be). Theoretically however, the C# (reference/handle based) approach is an
equally advantageous way of building applications, if compiled into native executables.
C# is compiled into a native executable when it is launched. There are also tools out there which generate native executables from CIL code. Sometimes these tools generate code that runs slower than if the code were just JIT'ed. So technically speaking, CIL code *always* runs "natively" on your platform of choice. As a result, i don't think your proposition has actually proposed *anything* that mono doesn't already do. Unless of course you were actually proposing that the whole Mono framework is rewritten in C or C++ or whatever non-CIL language of your choice and a thin c# wrapper is placed over that to provide interoperability with existing .NET libraries. If that's what you're suggesting, you obviously have completely missed the benefits gained when writing in a managed language. Alan.
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
