Slashdot Mirror
Microsoft's CLR - Providing a Break from HW Vendors?
"It seems to me that once the CLR has matured enough, there won't be a need for Microsoft to wait for others to innovate on the hardware front and start offering its own hardware (and charge whatever it wants for it) to go with future versions of Windows.Net. Worst still, 99.99% of the population will not be able to say no to this strategy since they'll have no choice but continue using the Windows monopoly in order to run their favorite apps."
Jamie comments: I don't think it's about hardware innovation, or beating Java. It's about absolute control.
The big money over the next decade will be in transforming the computer into an entertainment device. AOL Time-Warner sees a computer as a revenue producer, with the unfortunate ability to copy digital works. They and the other five media giants want to put a stop to it; Microsoft and Intel will find it very profitable to help them.
One good step along the way is to give the computer a common interpreted language to run everything. We're there already. And when developers have to code to a virtual machine, not the actual bare iron, then whoever writes the virtual machine holds all the cards. And since the authors of the virtual machine will make a lot of money by enforcing intellectual property rights, the arms races are all over: copy protection is absolute, DeCSS won't compile, unauthorized MP3s won't play.
Of course developers rarely write on the bare metal anyway: we write to APIs, we write scripts, we write code that doesn't (need to) run in the CPU's supervisor mode. We're used to surrendering the ultimate control over the machine to the operating system, or to be more precise, to the BIOS that decides how and which operating system to run.
If we surrender this control, though, we'll find ourselves with a monopoly operating system that makes it impossible freely to write code for. (And it's not hard to cut off Linux and every other rogue free OS at the knees. The day that every motherboard's BIOS uses strong crypto to demand the master boot record be signed with a secret key known only to Microsoft is the day that Linux becomes a thing of the past.)
Naturally, to prevent you from firing up GCC and doing a rogue compilation of DeCSS or Lame or other unauthorized code, the operating system will have to stop you from running anything that isn't written in its language for its virtual machine. Requiring code to be signed by a central authority will make its first appearance as virus-prevention but its real purpose too will be control. Universities will be able to buy special licensed exemptions, at least until corporations decide universities are hotbeds of piracy and theft. At which point your alma mater begins teaching Computer Science 101 (and 201, and 301, and 401) in C#.
My prediction is that, unless antitrust legislation in the U.S. gets some teeth between now and then, the PC will become a Gameboy within fifteen years. Enjoy computers while they last.
all CIL code is _always_ compiled to native
Normally CLI is compiled to native machine code rather than interpreted. CLI bytecode also carries a lot more useful information for optimization than JVM bytecode does (as well as placing some restrictions on code generation that make it easier than JVM to compile efficiently).
DNA just wants to be free...
I agree that statement "write once, debug everywhere". Here is one example, on Solaris, if one thread is doing a blocking read and another thread interrupts the first thread, it will succeed. On NT, the second thread appear to succeed in interrupting the thread but in fact it doesn't. So, don't always assume that your Java app running on one platform will run on other platforms. There are bound to be surprises.
Neromancer,
;-)
p la yer/Utility/20/WIN98MeXP/EN-US/Episode020.exe
;-)
a ns cripttext.asp
Why bother? You will only get called a troll and Microsoft apologist. The fact is a lot of people that read Slashdot get off on finding evil intent in everything they do.
If you really want to find out what the CLR is about, take time to either watch this (Windows required
http://msdn.microsoft.com/theshow/Episode020/
and download this 65Mb executable:
http://download.microsoft.com/download/winmedia
which is a 1.5Hr show/video that talks about
what the CLR is and does. YES, I did say 1.5Hrs.
PS: The Babe that reads the news is quite tasty - this is not a joke
or read this transcript:
http://msdn.microsoft.com/theshow/Episode020/Tr
Thanks for reading this far.
- Penguin Kicka
The CLR also incorporates some other innovative features - the ability link packages based on the signature of that package, not the package name, allowing side by side execution.
Also, the CLR is closely tied to the .Net framework, which is far ahead of the Java class library as you may mix and match classes across various languages. Note this does not mean you can just compile different languages to the CLR, but reuse code at runtime from code written in other languages.
Frankly the rest of the comments here are rants, I don't think many readers here understand the .Net platform.
With clever packaging and moving the compile stage into a two-step process, the same result could be rather duplicated, I imagine. The Win32 api has been shown on all the mentioned architectures, with the only real difference being a crappy monolithic executable format.
± 29 dB
What does their lack of backwards compatibility have to do with anything?
Is it a ploy to make money? Of course it is.
Does it really matter? No, you can set Word to save to Word 95 format and you won't lose anything important. You can even download a free 2000 viewer if you want, and cut and paste into Word 95.
Would MS provide these things if they were a crazy, unrestricted monopoly that would do anything to grab cash? No, they'd encrypt
MS is like some inkblot where everyone can project their own little "gotta stand up to the man", "slippery slope" fantasy world view.
Want to fight MS? Help make Linux good. Quit whining.
.
Let's not stir that bag of worms...
My prediction is that, unless antitrust legislation in the U.S. gets some teeth between now and then, the PC will become a Gameboy within fifteen years. Enjoy computers while they last.
Game Boy is a bad example. The Game Boy Advance is an open system, fully documented to the point that anybody with GCC can write software and run it on the GBA without taking a vow of silence or paying the big N. The only things the GBA checks before running your code are 1. the very simple checksum on the header and 2. a bit pattern that produces the Nintendo logo but is legal to copy under the Sega v. Accolade precedent. So go get GCC for ARM and an MBV2 cable from lik-sang.com and get hacking.
$article =~ s/become a Gameboy/become an XBox/; and it becomes more accurate.
Will I retire or break 10K?
Putting aside the interesting philosophical question of whether a corporation can be evil for a moment, the following can be asserted with a degree of confidence:
.NET Remote. While SOAP cannot pass object references around, or serialize objects like RMI, .NET Remote removes both of these restrictions, making it much more attractive than straight SOAP, which doesn't even provide object-level access in its standard form.
1. The interoperability aspect the article is concerned with is that between platforms, not between languages. The latter is interesting, if overstated, but irrelevant here.
2. CLR may be specified, but other APIs and services are not, therefore it is trivially easy to lock in developers, just as was attempted with the proprietary GUI API MS provided for J++.
3. For some reason, it is not yet widely appreciated that the public SOAP specification already has a proprietary MS extension called
Well... It turns out that NT was actually developed on MIPS, not x86. The x86 is an actual port from the original MIPS R4000 kernel. The reference platform for NT was supposed to be RISC and the x86 machines were relegated to Win16 OSs. When NT was developed in the early 90s it was supposed to be the OS for the ARC consortium, that was going to make PCs based on EISA and MIPS to fight IBM and Intel respectively.
This is why no HW vendor should ever trust M$.
1. Consumers, that's a retarded question. 2/3s of the US economy is consumption. Capitalist economies typically devote more resources to consumer goods than capital goods. Business computers are capital goods.
To grow a command economy, you push capital goods to excess. Hence the aggrarian Russia become a major superpower from the time of the Russian revolution (1917) to rival the western world by the end of WW II and remained competitive until its economic collapse in the early 90s. Despite the ability to keep up militarily (technically consumer goods, as weapons and munitions aren't used to produce other goods) and in factories, they had bread lines and 10 year waits for autos. Why? If the rest of the world wants to destroy you, you spend on military first, keeping up second, and goods for the people 3rd.
Businesses spend money differently. Demand for capital goods is different from demand for consumer goods. Businesses will buy capital goods (like computers) at higher prices because they get a good ROI on them, and the opportunity cost of downtime and tech support is higher.
Consumers are willing to spend differently. They are more likely to be willing to spend 1-2 hours on tech support then spend $100 to avoid those waits.
Its about two things: market segmentation, money.
If Microsoft can get themselves 1% of the consumer non-food, non-rent economy (essentially becoming a government and enacting a tax), they will become MUCH larger than now.
If they can better split the business buyers from the consumers, they can maximize prices and therefore profits.
Alex
The funny thing is that Microsoft has already patented exactly this
I don't understand what you (or Microsoft) are talking about when making that claim.
I regularly mix Python and Java objects. Python is a dynamically typed language with multiple inheritance and Java is a statically typed language with single inheritance. I can subclass Java objects in Python and use Java objects in Python and vice versa. If this is possible for languages as different as Java and Python, it would seem to be possible for many other languages as well (and many other languages implemented on top of the JVM claim to provide the same level of integration--I just haven't used them). The Java native code interfaces also allow for similar levels of integration with native code.
The CLR does clean up some idiosyncracies and minor messes in the JVM and JVM spec. Mostly, those cleanups give a bit more handholding to less experienced language implementors to figure out what to do. But that doesn't seem to give the CLR significantly more functionality or performance overall.
If you claim CLR is "demonstrably better", maybe you can be a little more concrete in your "demonstration"? Where specifically are these demonstrable advantages, and how specifically can you not achieve the same functionality in the JVM?
http://www.cygnus.com/~bothner/kawa.htm
So does Java. Java provides sufficient introspection into the structure of its own classes, such that any language wishing to integrate on the object level with Java would have no trouble doing so using standard APIs. It's pretty much a matter of how well you code the environment for the target language. It's not like Perl and Python integrate instantly with CLR out-of-the-box, the language implementations had to be rewritten with CLR in mind. Java is no different.
For a good Java implementation of Scheme with the ability to integrate with classes and objects written in Java, check out: http://www.cygnus.com/~bothner/kawa.htm
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Some points:
.Net. It's the mother of the battle between IE and Netscape.
.Net strategy is all about supporting the Windows price tag and wiping out other platforms. .Net is pitting itself against J2EE in the enterprise layer and continues to fight Linux and open source at the lower layers.
1. A JVM (or CLR) is needed to allow the creation of applications (as opposed to applets/ActiveX) that run in a security sandbox (as opposed to on the bare machine) with dynamic classloading and garbage collection. These things are indispensible.
Without a JVM (er CLR) Microsoft's developer base would continue its trend and dwindle to nothing except developers who couldn't adapt to Java -- i.e., lousy developers. I'll bet there is already a lot of that effect already. There has been a giant sucking sound in PowerBuilder, Visual Basic, and Visual C++ development as most of the prime developers scooted over to Java to see what was going on. I'll bet there are a lot of Microsoft developers out there working in Java who are now a version or two behind in their Microsoft development platforms.
Microsoft needs them back.
2. The CLR and C# are not about supporting platform independence, either at the OS or hardware layer. Please. It's ridiculous to think that Microsoft is going to do anything to undermine Windows. And Windows is not going to depart from Intel.
Anyone remember a little thing called the Alpha? What a catastrophe NT on Alpha was for poor DEC (now poor Compaq). Lots of businesses bought those cross-platform "Windows Alphas" too and they now regret it.
Nope. It's Wintel all the way for Microsoft for the foreseeable future.
Listen up Linux people. This is the same old trick.
Microsoft mouths the words "platform independent" and "open standard" to counteract their sales vulnerability to fears of vendor lock-in. Then the platform independent version just never shows up. It's always "in development by some third party" and never sees the light of day. Are you still waiting for the non-Windows version of DCOM and DNA?
This time, the chumps are the Linux community. Miguel De Icaza blew it with Gnome and now he's about to (help) blow it for all of Linux.
3. Java is an "open specification" but not an "open standard." That's a distinction that only matters to propagandists. Most people don't know the difference, so they complain noisily about the Java platform not being a standard.
In essence, with an open specification, anyone can write an implementation, they just can't change the specification. Sun's open specifications are extremely open to change though -- through the extremely open Java Community Process. The specifications are open to change but not hijacking.
Sun was very wise not to give up control of the Java specification. Had they ceded control to a standards body, Java would have been slowed down, absorbed, and fragmented by Microsoft.
Look at what has happened to HTML, the other major non-Microsoft platform. The W3C is now begging to get back in the game on HTML -- and it's their own game. Without Mozilla, the W3C would now be completely irrelevant. Microsoft would own the only meaningful definition of HTML (like they don't already).
4. Where's the source code?
With Java, you can look at the source code of all of the standard API implementations. It's gorgeous code that you can step into with your debugger. That will never, ever happen with Microsoft. It would undermine their ability to exploit hidden API capabilities to leverage their OS mononopoly against third party software vendors.
5. In the final analysis, the battle is between the J2EE and
Like Netscape, J2EE is in the driver's seat. It is hands down the most widely adopted, most diversely implemented platform to date.
This is not about religion. It's about money. The main thing people like about Linux is its price tag. Microsofts
.Net is not going to be on any other platforms or OSes any time soon. Please snap out of it. Linux people who fight Java and J2EE should reconsider.
JBoss on Linux is the open source platform of the future in my opinion.
For a long time now, you could buy a x86 board for an AS/400 which allows you to run NT or OS/2 on the 400. Perhaps that's what's confusing the parent poster.