Yes, compiling at install time makes installs slower. However, it also makes your system more stable overall because it eliminates library inconsistencies, given appropriately portable code (autoconf for windows anyone?)
However, this is not anything remotely similar to what is being proposed. Under the .NET scheme, you distribute BINARY code, compiled to IL. Each computer has an IL interpreter that runs all your BINARY applications.
The point is this. Suppose some chip company comes out with the Magic CPU of Godlike Speed. You, Joe Sixpack, want to put down $2000 cash on the barrel and receive a shiny new Office Depot MCGS PC. You want this because you will never have to wait for your computer again. Whatever you tell it to do, it will just do, instantly. Solve the halting problem, whatever.
Except you have all these Windows applications. You want to be able to run Age of Empires (American Imperialism Edition) and Warcraft VI and Quake IX. And of course you want to be up to date on all the latest pr0n standards like Super Ultra Extreme Video CD (SUX-VCD). Oh, and maybe you also want to install a pirated copy of Microsoft Office 2009 so you can vaguely think about maybe typing a resume when you lose your job.
When the MCGS PC got to your house, you discovered that only MS Office actually works in native mode, everything else requires you to run it in compatibility mode (whatever that is), and it's way slower than even your old, obsolete Athlon XP 3000+. You spent $2000 for nothing! MS Office is indeed a little faster (if you remember to disable Auto-Write-Essay-On-Unrelated-Topic), but you don't even notice that because you're too busy looking at the pr0n.
What Microsoft is trying to convince us all to do is start writing applications for IL instead of any real CPU. That way, *everything* runs in compatibility mode, *all the time* !!! That way, programmers don't have to write well-designed, portable code; application companies don't ever have to recompile; and nothing you ever do can actually run on bare metal any more! It's so obvious that this is a great idea that nobody can actually explain what's so great about it.
Oddly enough, it's the exact same plan that Sun wanted us to follow circa five years ago. If Microsoft had gone along with it then, we'd be there now. Why is it a good idea when Microsoft does it but a bad idea when Sun does it? Presumably because Microsoft sees owning the platform as in their strategic best interests.
If this really was the Ultimate Good Idea, then we would all be running on top of UCSD p-Code. The idea of a universal virtualization layer is one of those things that the computer industry re-invents every few years, like remotely accessing a computer, encrypting your disk files, or sending messages to other users. Perhaps having the full weight of Microsoft behind it means that this wave of the cycle will actually achieve dominance for a while. If so, then I predict a booming market in the 2010s for people selling "native instruction set accelerator cards" and the new buzzword will be NIS - golly, your code can run right on the bare metal! It's so fast it's hard to believe! Another amazing innovation brought to you by the power of the monopolistic free market!
Oh, and by the way - COM, which is a defining feature of Win32 and was introduced eight years ago, quite adequately solves the problem of DLL versioning. DLL versioning was a big issue on Win16. The only reason that DLL versioning has ever been a problem on Win32 is that applications vendors typically are apparently staffed by australopithicenes - a primate that walks upright like a human, but posesses the brain size and cognitive development of a great ape. "Nurg no like changing GUID when interface signature change. Nurg have to handle calls on prior version interfaces if Nurg have installed base of customers. That no fun. Nurg not remember what Nurg already sold, that a job for marketing. Nurg like develop new code but use same GUIDs. Nurg also like reboot when install stuff." But perhaps that's giving too much credit to applications vendors.
There's no need for .NET to solve DLL versioning, because COM already solves it; or conversely, there's no point for .NET to attempt to solve DLL versioning, because applications vendors will find a way to reintroduce it.
[ Parent ]