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.
Yep, it's speculation. Do you have evidence pro or con? Let me know!
You must be logged in to the O'Reilly Network to post a comment.
Showing messages 1 through 5 of 5.
-
What's the point of the article
2004-02-18 01:38:15 musnat
[Reply | View]
I couldn't see the point of the article or what it exactly tries to say. Here and there we have some Microsoft bashing which probably done to make the article more valuable to some zealots out there, but what is the author trying to say to the rest of us?
-
Plausible
2004-02-17 05:28:17 kowenswp
[Reply | View]
Why not? The next move may be to "give away" the operating system; sowewhat like the manner in which MS "gave away" the browser. The OS would become the substrate on which the CLR runs. It would provide essential interface services such as Network, Disk IO, memory handling, etc.: a glorified BIOS, if you will. The software market could then migrate to value-added applications, quite possibly leased or rented rather than purchased outright. The CLR running on any OS would constitute a potential host for MS's desktop and productivity software (server based with code injection). DRM is terribly important here: it would serve to protect both the applications and the productions of those applications; a kind of "the document is the computer" mentality. Mono, Rotor et al actually give MS immense flexibility for the future. If Linux make headway in the enterprise, then MS can distribute Windows OS for free (or a nominal fee) and market their software to both Linux and Windows users. If handhelds become the machine of choice then MS is covered there too - SOA's with light-weight client interface hosting and application\service leasing can be handled within the same CLR paradigm.
-
Bizzare and unlikely
2004-02-16 03:36:27 simon_hibbs
[Reply | View]
For a start, why would Microsoft be at all interested in running Windows on Mono? Rotor proves that the CLR engine is portable, so porting it to Linux should be a piece of cake should they so wish. Mono is irrelevent to them.Secondly, why on earth would the Mono crowd care if Windows runs on Mono? Its a common missconception that they're trying to create a cross-platform dev environment. That's merely an incidental benefit, the real reason for developing Mono is to make desktop software development on Linux easier. They like C# and the CLR managed environemnt and want a slice of it for themselves to make GNOME development easier. The idea that Windows is going to become a thin client OS is laugable. Just look at Media Centre, WinFS, etc. Windows is getting fatter by the minute, with no diet plan in sight. Simon Hibbs
-
Seems farfetched
2004-02-15 17:53:56 dumky
[Reply | View]
Isn't Microsoft pushing for Longhorn and a bunch of OS-level functionality (think winFS)? Of course all these can be programmed in .Net, but try to run that new Outlook application on MacOSXI and all these features will be found to be serverly lacking... This kind of problem already appears with say the Registry classes in .Net. This part of the framework isn't being ported to Mono and therefore needs to be avoided for cross-platform apps.
- Trackback from TeledyN
Dot Network is Dare Computer
2004-02-13 20:11:23
[Reply | View]
I blog on from the deep rural wilderness woods, he's the nameless technical editor of a leading geek publishing company, I look out across the snow through the thin wireless, he's sent...
Showing messages 1 through 5 of 5.
|
Return to weblogs.oreilly.com.
|