Why Microsoft Will Never Make .NET Truly Portable

Michelle Meyers writes "Just days before Microsoft claimed to be making parts of the .NET CLR "available" to other platforms, NeoSmart Technologies had published an article bemoaning and blasting Microsoft's abuse of it's developers by pretending .NET was a true cross-platform framework when they're doing everything in their power to stop it from being just that. Of interest is NeoSmart's analysis of how Microsoft has no problem making certain portions of .NET available to Mac users — just so long as its distributed under an "open source" license that forbids any and all use of the code except for educational purposes — yet are terrified of the very thought of .NET being available to *nix users, even if that's to the benefit of .NET developers everywhere. Even more interesting is one of the comments on that article linking to legal documents in which Microsoft employees discuss the (im)possibility of creating a cross-platform code and UI framework, years before the .NET project even started!"

Comments

.Net Framework Portability

[Wharper]

It does seem M$ is making some effort to take at least some portions of the .net framework to other systems:

http://msdn2.microsoft.com/en-us/embedded/bb278106 .aspx

It even looks as if some companies are making dev boards with it:

http://www.embeddedfusion.com/default.aspx?id=76

In talking with them (M$) it seems that you pay to port this framework to whatever platform you would like to take the framework to. This is with or without an operating system.

Cheers,
    Bill

STOP whinging silverlight is coming to Linux!

[wwmedia]

http://news.com.com/8301-10784_3-9714669-7.html?pa rt=rss&subj=news&tag=2547-1_3-0-5

Re:So C# is .Net?

[digitig]

No. As I see it (and there's more than one way to see it) .NET is essentially an API and virtual machine offering that API. C# happens to be a high level language that maps very closely onto the virtual machine language, but in theory any language can compile to that machine language (and many do -- C++, Java, VB, Python, Ada, Eiffel, and so on). I like it as an API (at least at version 2.x), the VM makes multi-language programming a cinch, its memory manager really does seem to eliminate a lot of classic memory bugs, and its deployment model moves away from huge, centralised registries. But it comes at the expense of bloat and the speed penalty of an extra layer between the code and the metal. IMHO that's a reasonable design choice to have to make. If you're developing for MS Windows I reckon .NET is a decent design choice as long as you're not particularly size or speed constrained. If you're developing for anything else -- well, try starting here: http://it.slashdot.org/article.pl?sid=07/05/02/133 6216&from=rss.

Re: Why Microsoft Will Never Make .NET Truly Port

[nametaken]

I care. I maintain, and develop for, windows systems all day... then come home to all linux systems with the exception of an XP Pro VM I keep tucked away for emergencies. I'm not switching frameworks, and the business is not switching platforms. What's more, like most .net developers, I like the framework and the dev environment. They're the sort of things that MS actually got right.

It seems to me that the popularity of .Net should be obvious to those who frequent slashdot.

Re:Java

[Jarnis]

It may be preinstalled in Windows *Vista*, but it sure as hell is not preinstalled on XP.

Instructing end users to install this and that .NET framework is a common problem. As is explaining the fact 'WTF why do I have to install .NET 1.1, I already have 2.0!' - most users don't understand that the two can (and in some cases should) coexist.

MS has made .NET very end-user unfriendly in XP.

Re:So C# is .Net?

[shutdown -p now]

I like it as an API (at least at version 2.x), the VM makes multi-language programming a cinch, its memory manager really does seem to eliminate a lot of classic memory bugs, and its deployment model moves away from huge, centralised registries. But it comes at the expense of bloat and the speed penalty of an extra layer between the code and the metal. IMHO that's a reasonable design choice to have to make.

Actually, it's faster than many think. Remember that the bytecode was optimized to be JITed rather than interpreted from the very beginning. The easiest way to check on it is to run your .NET program from within Visual Studio, set a breakpoint, and then go into "Disassembly" mode. You'll see what the JIT compiler made out of your code. I've found that for math, pointer operations, and method calls, it's pretty much the same as the output of a C++ compiler, except that you can't avoid checks for null reference on method calls (though it does not check for that repeatedly if one check is enough). Well, there's still the penalty from GC, and that one is harder to account for - but still, there really isn't much reason to pick C++ over C# for speed, unless you really really need that 3-5% extra.

Re: Why Microsoft Will Never Make .NET Truly Port

[deathy_epl ccs]

When you say dev environment is better, do you mean VS.net is better than Eclipse? Eclipse has come to a point that it is way better than many development IDE.

I use both currently, and I can say that Eclipse may be way better than many IDEs, but Visual Studio.net isn't one of them.