The Wayback Machine - http://web.archive.org/web/20040413003247/http://www.oreillynet.com:80/pub/wlg/4438
O'Reilly Developer Weblogs
O'Reilly Network oreilly.com Safari Bookshelf Conferences
Sign In/My Account | View Cart   
Articles Weblogs Newsletters Meerkat Learning Lab News

 
LinuxDevCenter.com
MacDevCenter.com
WindowsDevCenter.com
ONDotnet.com
ONJava.com
ONLamp.com
OpenP2P.com
Perl.com
WebServices.XML.com
XML.com


Developer Resources Partner

Perl
Java
Python
C/C++
Scripting
Web
Web Services
XML
Oracle
Networking
Security
Databases
Linux/Unix
Macintosh/OS X
Windows
.NET
Open Source
Wireless
Bioinformatics
The Missing Manuals


Traveling to
a tech show?

Canada Hotels
Discount Hotels
Hotel Search
California Hotels
Chicago Hotels
Hotel Discounts
Myrtle Beach Hotels



Atom Feed
RSS Feed
O'Reilly Open Source Convention: July 26-30, Portland, OR.

Most Recent | Webloggers | Topics | Top Weblogs   
Monthly Archives:    
Is .Net Microsoft's Exit Strategy for Windows?
chromatic

chromatic
RSS 1.0 feed for  chromatic. Atom feed for  chromatic.
Feb. 13, 2004 05:58 PM
Permalink

   Print.Print
Email.Email weblog link
Discuss.Discuss
Blog this.Blog this

URL: http://www.theregister.co.uk/content/4/35481.html

Neil Davidson's analysis of Mono and .GNU is flawed, but it's a good springboard for a more interesting question. Is .NET Microsoft's exit strategy for Windows as we know it?

There's fair evidence that the next version of Windows will have — or be — the CLR at its heart. Apart from some drivers and a few pieces of unmanaged code no one can quite escape, the rest of the OS will be CLR components.

That's positive in a few ways. I most appreciate that it will finally add credibility to something besides C and C++ as system programming languages. (As a side benefit, Microsoft might finally escape buffer overruns.) Further, if their developers really embrace the idea of well-designed components, it'll make Windows even easier to script. Admittedly, you'll have to use some flavor of C# to do it, but at least it's an intrinsic goal. You can port any language to the CLR as long as it's C#. (Before you send me angry e-mail, I know that you can add layers and layers of code to add nice things like dynamic typing, but I don't consider that a port. Deal with it.)

To convince the "I overclock to run the idle loop faster" crowd that CLR components can run fast, or at least, fast enough on the average new machine of 2006, Microsoft has to brag about aggressive JITting. (That's more or less a runtime optimization step that produces raw machine code from opcodes. While it seems like this would be slower than producing raw code from the start, it can actually be faster in cases where the additional information at available at runtime allows better optimizations. This is all an oversimplification, but it should be true enough to make the point.) Since the JITter is necessarily bound to a specific processer (it's machine-dependent code), the CLR will only JIT on officially blessed targets. Then again, Java's "platform independence" meant "some flavors of Win32, Solaris, and, in a few years, an old version will run on Linux" for quite some time too.

There's another important part of .Net here. Microsoft's strategy has included distributed components for years. This also shows up in .Net. It's conceivable that a .Net Office suite will consist of small, downloadable stubs that connect to an Office server online to do the real work. Expect to pay a license fee.

What are the implications? It's pretty simple, if a little subtle. If I'm right, Windows will become a virtual machine that allows you to rent applications. Because the CLR isn't tied to any specific platform — Rotor runs on FreeBSD and Mac OS X, for example — it's possible that this most of this new version of "Windows" will run on any complete enough Rotor port, though perhaps not as fast as on the blessed version. Hey, it worked for J++.

It'll run okay on Mono too. I'll get to that in a moment.

Microsoft could give up its whole operating system monopoly by shifting it into a CLR monopoly. It may seem like a stupid strategy, but add in the renting of software and it's not so bad. Think about handheld computers, cell phones, and PDAs and how well they'll run the CLR in a couple of years and it's more and more likely.

Now again, the JIT is important. I'm not sure if Microsoft's really publicly concerned about anything much more than x86 and its successor. (If Intel's and AMD's 64-bit lines emulate x86 instructions, they may not have to care for a while.) While I've run NT on an Alpha, way back when, Microsoft hasn't shown much of a history of portability. If you want code that runs on multiple architectures, look at the open source and free software folks.

That's where Mono comes in. Runs on Linux? Yep. Has JIT for PPC? Yep. Goes places and does things that Rotor doesn't? Yep. Sure, Microsoft loses no love on the GPL, but they could overcome their institutional view that Windows is the crown jewel to make the argument that renting applications in perpetuity is valuable even if you don't use the official CLR. (Alternately, they could claim patent infringement and try to grab rights to the Mono source that way, but that seems extraordinarily risky.)

Why port Office to Linux when you can port Windows to .Net?

Is it farfetched? Maybe a little bit. Microsoft has the opportunity to bet the company on a big shift in the desktop market. By making anything-but-.Net a dead end for Windows development and redefining the platform, they have yet another shot at their grail: complete control over your data and applications.

I can't quite fit DRM into these schemes though, so there may be more (or less) to the story than this idea. Still, there's a possibility that free software fans should keep in mind. What if the desktop turns out not to be the right goal after all?

chromatic is the Technical Editor of the O'Reilly Network.

Return to weblogs.oreilly.com.




Sponsored by:

Creative Commons License This work is licensed under a Creative Commons License.
For problems or assistance with this site, email help@oreillynet.com