or aliens or robots from the future... whatever, fuck you! You'll watch it anyway.

How can that be true? If Steve Jobs is living tissue over metal endoskeleton, he should last 120 years with his existing power cell...

How about the same thing the factory worker does when he's replaced by automation or his job is outsourced to cheaper labor markets. Survive. Adapt. Why is it so unthinkable that highly educated people would be put out of work by progress, instead of simply the low wage laborers?

"This article is based on a prerelease version of the .NET Framework 2.0"

Can I recommend that you find a slightly newer source?

"Mono can't run .NET apps."

Wow, that's funny. I must be on acid, because I thought I just compiled a .NET app in Visual Studio, copied it to Linux, and literally ran the Portable Executable file (.EXE) with Mono.

"Probably you would have to code in a subset of Mono, this coupled with the fact that Mono will always play catch up to .NET means that developing cross-platform apps in Mono will always place severe restrictions on you."

Let's see how true this is:

http://mono-project.com/Compatibility

So here's what's missing:

CodeContracts - API complete, partial tooling
EntityFrameworks - Not available.
Server-side OData - Depends on Entity Framework.
WCF - silverlight 2.0 subset completed
WPF - no plans to implement
WF - Will implement WF 4 instead on future versions of Mono.
System.Management - does not map to Linux
System.EnterpriseServices - deprecated

So other than the above Microsoft specific technology plus Entity Framework (use NHibernate instead), the entire C# 4.0, .NET 4.0, and ASP.NET 4.0 platforms are supported. Oh, and what really matters is ISO/IEC 23271:2006 and ISO/IEC 23270:2006... you know the ISO standards that Mono implements.

So basically, your entire point against Mono as a multi-platform solution for ISO standards based .NET development is bullshit. The few libraries that are limited on Mono aren't that critical for applications, web, or backend development. WinForms is supported, ASP.NET is supported, and services (as console apps) are supported.

Yeah those Mono license fees are expensive. Almost wiped out my company with those fees. It's not like they have .NET 2 through .NET 4 implemented in Mono for free, which you can run on Linux or Windows. Idiot.

Are you serious? We abandoned C++ Builder for Visual Studio and C# .NET and every other developer meeting we're praising the flying spaghetti monster that we did. The massive reduction in defects and the massive improvement in productivity were huge for our team. C++ Builder is great for breaking compatibility with every release (we owned literally every version up to XE), the IDE and/or compiler crashing at random intervals or producing broken code that itself crashes at random intervals. Plus you're serious about real code when you're talking about writing software that's based on the VCL?

Oh and by the way, a base class library that requires you to *new* every BCL object but doesn't have garbage collection, simply begs for access violations and memory leaks. Simply idiotic. You couldn't pay us to switch back.

As a bonus, we can compile our .NET binaries to native code with one drop down box selection, rather than code that pushes all of our data through a Delphi interface and back and beats the hell out of a shitty heap implementation. At least they switched to a 3rd party C++ STL implementation rather than their own buggy garbage.

Microsoft hasn't abandoned DOS or Win16???? Have you tried running a DOS program or a Windows 3.x program in Windows 7? I think you'll find that your information is more than a little out of date.

And NT was a complete and total abandonment of the Windows 9x codebase. The entire OS was rewritten from scratch in C, an entire NT API exists under the hood that powers that OS, and then the Win32 API/ABI was added as a compatibility layer on top of that OS. As was their POSIX and OS/2 compatibility layer.

I know you probably can't be bothered to validate what you're saying before you say it, but perhaps a little bit of Google is in order before you spout off? Or try running a DOS app. Or something. Or let the grown ups talk.

I hate having to explain this to non-.NET developers over and over again. Try to follow along.

In Visual Studio, if you select x86 or x64 or Itanium as your target instruction set, CIL (formerly MSIL) is not generated. NATIVE machine language is generated, doing the job that the JIT would normally do. You with me so far? You can target native platforms, and produce native code.

Beyond that, if you do choose to generate an "Any CPU" binary, .NET caches all of its JIT compiles in the GAC. Thus for a particular platform, the CIL is only compiled into native code ONCE. The second time the code is executed, even between shutdowns and reboots, the native code is executed. You can read more about the GAC here:

http://en.wikipedia.org/wiki/Global_Assembly_Cache

Your argument is like saying, because you have to run a tarball of source through ./configure && make once on a particular platform, the code is interpreted. That's ridiculous. Interpreted code is read by an interpreter AT runtime. Deferring final compilation to 0.01 seconds before the program entrypoint is executed doesn't mean a program is interpreted. What actually executes at runtime is native x86 or x64 or Itanium assembly language, generated exactly once.

Again, *know* what you're talking about. We're not talking about just any generic theoretical JIT. We're talking about the .NET CLR which *does* cache all of the JIT compiles in the GAC. Here, let me help you know more about what you're talking about: http://en.wikipedia.org/wiki/Global_Assembly_Cache

.NET is a great platform, and C# is a great language. All of this .NET hate from anti-Microsoft types with no knowledge of the platform is just about as useful as all of the patent fear-mongering associated with Mono. Anything Microsoft invents, these people are going to try to tear down, whether it's a good innovation or a bad one.

Except AJAX of course. They just pretend Microsoft didn't invent XMLHttpRequest or iframe.

How exactly is .NET interpreted? CIL (formerly MSIL) is JIT compiled, just like Java is. The JIT compiles of assemblies are cached in the GAC, so it only happens once. After that it's native code for the platform you're running on, whether that's 32bit Intel, 64bit Intel, or Itanium. Or you can choose a specific platform in Visual Studio and compile directly to that platform and avoid the intermediate language altogether. From your description of .NET it seems like you have no knowledge of the platform.

Insightful? Come on mods, do better.

No, as you can see from the following, the standard Win32 message pump isn't an infinite loop...

while(GetMessage(&Msg, NULL, 0, 0) > 0)
{
        TranslateMessage(&Msg);
        DispatchMessage(&Msg);
}

Non-Affected Software
Windows 7 for 32-bit Systems
Windows 7 for x64-based Systems
Windows Server 2008 R2 for x64-based Systems
Windows Server 2008 R2 for Itanium-based Systems

Direct2D and Direct3D are a part of the "hardware graphics calls in Windows". The fact that it's not in the GDI/GDI+ libraries doesn't change that. DirectX ships with the OS, is required for the OS to function, and thus DirectX IS literally one of the OS APIs for rendering graphics.