But regarding platform independence, I have to disagree. It's still the .NET platform. The framework MUST EXIST on the target platform before the IL code will run. Is it possible to compile a .NET application to WIN32 or even WIN64, similar to the way you could statically link an MFC application? If so, then you speed up the application because all of the IL emulation would theoretically be translated to native code. I'm sorry, your never going to get away with the platform independence issue because for every new platform that surfaces, a new IL compiler will have to be written unless of course the target system is already backwards compatible with a supported platform. It's essentially a very elaborate way of recompiling your applications for a new platform. The only difference is a new IL compiler will have to be developed, instead of a new version of the WIN32/64/Whatever APIs being ported over to the new platform. Six in one hand, half a dozen in the other.
That's absolutely correct. Currently, on the windows platform, IL compilers exist for 32-bit, 64-bit and pocket PC. Even more platforms exist if you count Mono (though Mono doesn't compile the entire .Net framework)
The point I was making here is that once the JIT compiler(s) are written, all applications utilizing IL can leverage it. It's akin to writing a C++ compiler for each new platform (which, as you know, is one of the first languages typically targetted). The difference here is that the binaries aren't coded to a particular system's native code. That happens later, and code specific to and optimized to the target environment is ejected.
That's a big *IF* there. A good API should always be backwards compatible. I've always thought that way. If you're going to change the API, then quit calling it the same API. Yeah with a legacy-supportive API your going to have some bloat there, but it's gonna be chewing up disk space, not RAM and CPU cycles. Besides, if the API did not force an incompatibility in the first place, then their would be no need to more elegantly handle the versioning of installed components.
In my experience, backward compability breaks very frequently. DirectX sort of takes the way that you describe, and ships all previous versions with the latest version of the library. (that's why the install size gets larger with every release)
Unfortunately, that isn't the case for every component out there.
It's not nearly as painful with .Net, but any COM library that changes versions and establishes itself in the registry with a new GUID will break applications that expect that previous version. It was a classic idea of good idea (for some things), bad execution (for most things)
The frameworks don't replace previous versions anyway... 1.0,1.1,2.0,3.0... They all coexist and run based on the program calling them.
And they generally do for backward compatibility reasons.
Somehow, I suspect there is a co-incidental thing happening here, and .Net just seems to appear to be the smoking gun.
Don't want you guys to think I'm running away from this topic or anything, but I've got a project to hash out now, so I'll pick this up later after I upgrade to Vista, or at least .NET 3.0.
Good luck with your project. It was nice bantering with you. :)