![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrewduckerIf you don't care about my thoughts on the future of Windows, then don't read any further.
This was prompted by a conversation with Nathan, who's a consultant specialising in CRM, and is based on a fair amount of reading over the last couple of years.
Lots of people seem to be confused by Microsoft's .NET initiative. This is largely because it's actually several initiatives rolled into one. for the purpouses of this entry I'm going to ignore web services and passport authenticiation, which, while both interesting in their own right, aren't going to strongly affect Windows itself.
The .NET framework, on the other hand, will. For those of you who don't pay attention to these things, normally (and this is simplifying things greatly) you compile code from the actual text that is typed in straight to machine code that's specific to the chip you're working with (in the case of Windows, that's largely the 386, most x86 chips after that point basically working as 386 chips with addons, or at least imitating this). .NET is different because your code actually gets compiled into what's called the Intermediate Language (IL). It's only when this IL is first run that it actually gets converted to its final form, and it then runs on top of the .NET runtime. This .NET runtime acts as a layer insulating the code from the machine it's running on (in part, anyway).
There are two advantages to this. The first is talked about a lot. The second is talked about very little.
1) You can write code in any language you like and, so long as you have a compiler that produces IL code it can work with .NET. This means (for instance) that you can write code in C# (the .NET version of C) and then call it from code written in VB.NET, and then call that from code written in COBOL.NET (list of available languages here), and so on. You can kind of do that in windows already, but it not terribly well, and it wasn't at all seamless.
2) Any platform that has a .NET runtime can run your software. Big deal, you say, so I can run it on all the Microsoft platforms. Except that Microsoft has provided a minimal .NET for BSD Unix, there's a cut down version coming for PDAs and mobile phones and Mono is a GPL'd recreation designed to run on Linux (and supports Solaris and Windows too so far).
Now, you may not remember, but when Windows NT came out, it was touted as multiplatform because it also supported the DEC Alpha platform as well as the x86. The problem being that any software that you wanted to run on the Alpha had to be completely recompiled to run on it. Despite the Alpha being a great platform, if you couldn't get the software, it was hardly worth having. I know that some companies went to the effort, but the major advantage of Windows is that you can get everything for it, so why bother if you can't?
On top of this, we have the new Intel Itanium processors. These are Intel's next generation chips. They're backwardly compatible with x86 chips, but very badly. Any applications compiled for the x86 will run several times slower on them than on an x86. Code compiled for them, on the other hand, is apparently blindingly fast. In fact, the x86 line as a whole is creaking a lot. Recent AMD and Intel chips are both actually very different chips internally, that fake being an x86 on the outside, translate everything and then run very quickly internally. You can imagine that this isn't as efficient as it could be.
This has been a sticking point with graphics cards (and others) too, using the same chips just doesn't allow you to be as efficient and powerful as possible. Moving to new chips means the old software breaks (or has to have chunks written seperately for each card). This is solved by using "drivers" that conform to a standard. The drivers take the calls and convert them to a language that the card recognises. This allows the card makers to change their hardware as much as they like, so long as they write drivers that convert the standard calls to their own internal language.
I think you can see where I'm going with this - by moving software to .NET, Microsoft frees themselves from the x86 pit. They need to compile the .NET framework for each platform they want to support, and they need to write the final compiler stage that converts the IL to machine code, and bingo your code runs on the new platform!
Of course, it's not quite as simple as this - the Microsoft version of .NET is very Windows reliant, so they have to port Windows too. However, as I mentioned earlier, Windows was designed to be portable. They stopped selling the Alpha version a while back because it wasn't making enough money, but they certainly continued producing it internally for a while. Windows NT (and thus 2k and XP) were all based around the concept of a Hardware Abstraction Layer. Theoretically by rewriting that small piece, everything else in Windows "just worked" (after a recompile, of course). So if they've kept that ticking over in the background, you could suddenly see a profileration of Windows for different platforms.
Microsoft wins, because they can scale up to higher end computers without you losing all the lovely software you like. Intel wins because you can use their lovely new chips. You win because you'll be using a version of Windows designed for _your_ machine, not for one with a slightly different chip, because MS will be able to have the compiler be the efficient for the chip it's running on - so Athlons will have Athlon stuff enabled, P4s will have their speedups enabled, etc.
And this, I think, is the real reason for the .NET runtime.
This was prompted by a conversation with Nathan, who's a consultant specialising in CRM, and is based on a fair amount of reading over the last couple of years.
Lots of people seem to be confused by Microsoft's .NET initiative. This is largely because it's actually several initiatives rolled into one. for the purpouses of this entry I'm going to ignore web services and passport authenticiation, which, while both interesting in their own right, aren't going to strongly affect Windows itself.
The .NET framework, on the other hand, will. For those of you who don't pay attention to these things, normally (and this is simplifying things greatly) you compile code from the actual text that is typed in straight to machine code that's specific to the chip you're working with (in the case of Windows, that's largely the 386, most x86 chips after that point basically working as 386 chips with addons, or at least imitating this). .NET is different because your code actually gets compiled into what's called the Intermediate Language (IL). It's only when this IL is first run that it actually gets converted to its final form, and it then runs on top of the .NET runtime. This .NET runtime acts as a layer insulating the code from the machine it's running on (in part, anyway).
There are two advantages to this. The first is talked about a lot. The second is talked about very little.
1) You can write code in any language you like and, so long as you have a compiler that produces IL code it can work with .NET. This means (for instance) that you can write code in C# (the .NET version of C) and then call it from code written in VB.NET, and then call that from code written in COBOL.NET (list of available languages here), and so on. You can kind of do that in windows already, but it not terribly well, and it wasn't at all seamless.
2) Any platform that has a .NET runtime can run your software. Big deal, you say, so I can run it on all the Microsoft platforms. Except that Microsoft has provided a minimal .NET for BSD Unix, there's a cut down version coming for PDAs and mobile phones and Mono is a GPL'd recreation designed to run on Linux (and supports Solaris and Windows too so far).
Now, you may not remember, but when Windows NT came out, it was touted as multiplatform because it also supported the DEC Alpha platform as well as the x86. The problem being that any software that you wanted to run on the Alpha had to be completely recompiled to run on it. Despite the Alpha being a great platform, if you couldn't get the software, it was hardly worth having. I know that some companies went to the effort, but the major advantage of Windows is that you can get everything for it, so why bother if you can't?
On top of this, we have the new Intel Itanium processors. These are Intel's next generation chips. They're backwardly compatible with x86 chips, but very badly. Any applications compiled for the x86 will run several times slower on them than on an x86. Code compiled for them, on the other hand, is apparently blindingly fast. In fact, the x86 line as a whole is creaking a lot. Recent AMD and Intel chips are both actually very different chips internally, that fake being an x86 on the outside, translate everything and then run very quickly internally. You can imagine that this isn't as efficient as it could be.
This has been a sticking point with graphics cards (and others) too, using the same chips just doesn't allow you to be as efficient and powerful as possible. Moving to new chips means the old software breaks (or has to have chunks written seperately for each card). This is solved by using "drivers" that conform to a standard. The drivers take the calls and convert them to a language that the card recognises. This allows the card makers to change their hardware as much as they like, so long as they write drivers that convert the standard calls to their own internal language.
I think you can see where I'm going with this - by moving software to .NET, Microsoft frees themselves from the x86 pit. They need to compile the .NET framework for each platform they want to support, and they need to write the final compiler stage that converts the IL to machine code, and bingo your code runs on the new platform!
Of course, it's not quite as simple as this - the Microsoft version of .NET is very Windows reliant, so they have to port Windows too. However, as I mentioned earlier, Windows was designed to be portable. They stopped selling the Alpha version a while back because it wasn't making enough money, but they certainly continued producing it internally for a while. Windows NT (and thus 2k and XP) were all based around the concept of a Hardware Abstraction Layer. Theoretically by rewriting that small piece, everything else in Windows "just worked" (after a recompile, of course). So if they've kept that ticking over in the background, you could suddenly see a profileration of Windows for different platforms.
Microsoft wins, because they can scale up to higher end computers without you losing all the lovely software you like. Intel wins because you can use their lovely new chips. You win because you'll be using a version of Windows designed for _your_ machine, not for one with a slightly different chip, because MS will be able to have the compiler be the efficient for the chip it's running on - so Athlons will have Athlon stuff enabled, P4s will have their speedups enabled, etc.
And this, I think, is the real reason for the .NET runtime.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2002-10-01 01:04 pm (UTC)no subject
Date: 2002-10-01 01:38 pm (UTC)The problem with that is twofold -
1) Macs are great because they just work. If you suddenly have to worry about drivers for 65000 different graphics cards, sound cards, network cards, etc. then they might start looking as unreliable as Windows.
2) If they port to x86, then MS will possibly respond by porting to Mac hardware. I don't know if this worries them, but it might.
no subject
Date: 2002-10-01 03:24 pm (UTC)I doubt anyone would go to the trouble of buying a Mac, then run Windows on it--but people are strange.