Microsoft Chairman Bill Gates has said that building the company’s .Net software architecture is more difficult than “getting to the moon or designing the 747. Read about it at News.com.
.Net Name Ties Microsoft in Knots
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I can see what he means. Often times Microsoft employees that are working on .NET travel to work under the possibility that they will never return home; just like astronauts who first flew to the moon.
Do you think monkeys will ever create the wheel?
Not to be mean spirited, but at least when you design a 747 or send people to the moon you have a clear set of design and functional goals.
And, furthermore, people *have* walked on the moon, and 747s routinely fly. .NET might work, and it might even work really well, but the best definitions I’ve read of it can’t seem to focus its intentions to anything more than a new API and runtime platform with some XML buzzwords thrown in.
When an architect designs a house, does (s)he say “it’s going to be made from bricks, steel and wood and be so cool it’s going to revoltutionize houses and house building forever, but I can’t tell you what it will look like, how much it will cost, or where it will reside. But it’s going to be super cool, someday, when its done. Trust me.”
I bet Mr. Gates never Build a 747 and he never were involved in the team that makes the moon landing. It is very arrogant to compare software development for home PCs with the task you have when your project deals direct with the life of other people. Like the passengers in a 747 or the astromauts in the luna module.
I wonder if Bill Gates was personally involved in the Apollo programme. I wonder if anyone died in the process of developing .NET. At least America’s position as a superpower won’t be affected either way with .NET’s success or lack of, unlike the Apollo programme.
“At least America’s position as a superpower won’t be affected either way with .NET’s success or lack of, unlike the Apollo programme.”
america’s superpower status is due in large part to is superior performance of its technology company.
back in the 80’s there was a fear the japanese would take over, and esp. take over the computer market. it was thought japanese semiconductors and processors would displace intel.
let’s not mention india, china, or the former soviet union.
it is america’s r&d companies that makes US a superpower.
China is not to be underestimated, leasurly American lifestyle as a whole has had an effect on the work and educational ethic of the people in this country.
I consider myself to be fairly tech-savvy and I still really don’t know what the hell .NET is. As far as I know, it’s:
* A collection of objects and classes (the ‘.NET Framework’) that serve as a wrapper around the Win32 API (at least on Windows anyway)
* A CLR that acts something similar to the Java virtual machine
* Some XML stuff that allows apps to communicate between each other
Other than that, I’m really not sure what else is involved.
This article explains it rather well:
http://arstechnica.com/paedia/n/net/net-1.html
> leasurly American lifestyle as a whole has had an effect
Unless you’re rich (which most people are not) or already professionally successful, you have to work 40 hours a week to survive in the US… Perhaps we have a more leisurely lifestyle than during the depression and ww2, but I don’t think a leisure/pleasure lifestyle is the norm in the US.
I hate to nitpick, but the message body contains an unterminated ”
I hope Bill Gates didn’t want people to actually read about it at news.com
The problem Java solved was not portability.
Lots of people knew how to write portable C/C++.
Sun even did that for Solaris SPARC/Intel.
The problem was that C++ was too complicated for mediocre programmers.
And Sun positioned Java as Luke’s X-wing gonna destroy the Microsoft Death Star.
What problem is .NET solving?
Portability?
Inter-language communication/compatbility?
Or did Microsoft create a giant swamp just to support their Java-clone, C#?
As I am not a fan of Java, I’m also not a fan of .NET. Neither one seems to support the creation of great applications that enable computers to do more for people.
#m
The more I see of things the more I suspect that the whole .NET Framework and CLR is partly a response to the comming end of the i386 architecture.
They would like to make chip makers subservant so they will not just bless one 64 bit architecture. And if you are going to have to support multiple 64 bit architectures and an aging 32 bit architecture then why not do that via a CLR, ala .NET.
Just my 2c
Kelvin
Sheesh, by 2006, there will be approximately 2 BILLION PC’s out there. That’s a hell of a lot of x86 automobiles driving around on the information lost highway.
So .NET is designed for all the PC’s they sell after that? Itaniums? Power6? Alpha-Phoenix? StrongARM? SPARC 5? FPGA Transputers? 😉
Doesn’t make sense to me. Microsoft already put in a lot of effort into teaching people how to write clean 64 bit C/C++ code that will work on XP64.
I cannot believe this whole contraption is to make it easy to port apps between a few different operating environments.
I suppose Microsoft has so much money, it doesn’t matter. Even if .NET is a flop, it won’t hurt them that much.
#m
“We still get people saying to us, ‘What is .Net?'”
Yeh … cos it’s a stupid name which doesn’t say anything.
.net is a domain suffix Bill.
The problem was that C++ was too complicated for mediocre programmers.
That’s a nice way of putting it, and I would tend to agree with you. I doubt that most Java programmers would; they tend to believe that a simpler language allows them to focus on more important things.
What problem is .NET solving?
Problems, as in plural. I don’t mean to sound like I’m nagging, but have you read the article I linked to in my previous post? It is quite clear and a welcome contrast from most of the media confusion and senseless hype that has become so commonplace.
As I am not a fan of Java, I’m also not a fan of .NET. Neither one seems to support the creation of great applications that enable computers to do more for people.
.NET is a bunch of great ideas all rolled into one package, but it has suffered the same fate as many such ideas: poor marketing. Or so it seems ATM. Personally I find it hard to believe that people would scoff at .NET from a technical standpoint; it is a remarkable achievement.
Sheesh, by 2006, there will be approximately 2 BILLION PC’s out there. That’s a hell of a lot of x86 automobiles driving around on the information lost highway.
So .NET is designed for all the PC’s they sell after that? Itaniums? Power6? Alpha-Phoenix? StrongARM? SPARC 5? FPGA Transputers? 😉
Doesn’t make sense to me. Microsoft already put in a lot of effort into teaching people how to write clean 64 bit C/C++ code that will work on XP64.
It makes perfect sense to me. Microsoft will need to support legacy applications when x86 does eventually go the way of the dodo, so the best way to ensure this is to start several years ahead; the applications of today will become of the legacy applications of tomorrow. Except they’ll be portable.
Most software should not be dependent upon a particular machine architecture. There should be no such thing as “64-bit C/C++ code,” and with .NET + good programming practices there isn’t. Well, with C++ anyway. C99 is a different story, but given the way it defines the basic types this isn’t exactly surprising. (I have no idea why anyone still uses C.)
The Win32 API is an aging API that should have been deprecated years ago. It is shackled with a mess of completely unnecessary macros and typedefs, a ridiculous naming convention, horrible error-handling, clunky Unicode support, etc. .NET fixes these things. I can’t say that I care for the capitalization in the API, but that’s a minor concern compared to Hungarian warts.
Yeh … cos it’s a stupid name which doesn’t say anything.
.net is a domain suffix Bill.
It’s catchy, though. At least they didn’t name their software with domain suffixes, like OpenOffice.org. That’s like naming my dog fido.com 😛
null-pointer-us:
But they ARE adding .NET to their product names, there is already Visual Studio.NET, and Windows.NET Server is forthcoming. I assume Windows Longhorn will also take on the .NET brand from Home, all the way up to Datacenter versions.
Many people don’t know this, but OpenOffice.org has “.org” in its name because of a trademark conflict. Look near the top of this page here.
http://www.openoffice.org/about_us/summary.html
I don’t know the exact details, but I am GUESSING that some computer related company has used and trademarked the words “Open Office” in that order for a product. This could pose a risk to OOo, so they tweaked the name and ENFORCED the tweaking. Also, the name is consistent since OpenOffice.org is NOT a commercial product and is administered by an organization and only sponsored by a corporation.
Also, I always thought that .NET may be part of MS’es master plan to go back to being a multi-platform software vendor. All this “portable bytecode” and “out Java-ing Java” stuff, and how they seem so remarkably tolerant of Mono and even dotGNU. I say that MS is more likely to start porting Windows off x86 again than Apple is to bring MacOS X to x86. My opinion, is all.
–JM
But they ARE adding .NET to their product names, there is already Visual Studio.NET, and Windows.NET Server is forthcoming. I assume Windows Longhorn will also take on the .NET brand from Home, all the way up to Datacenter versions.
That is only because the products’ primary job is to work with software called .NET. I don’t really like the .NET buzzword, in case I wasn’t too clear in my previous post. I simply meant that it IS a buzzword.
Many people don’t know this, but OpenOffice.org has “.org” in its name because of a trademark conflict.
Here’s a novel idea: choose a different name.
Also, the name is consistent since OpenOffice.org is NOT a commercial product and is administered by an organization and only sponsored by a corporation.
No, it’s just plain silly, Jahmal.edu. Or maybe we should ask Eugenia/index.html what she thinks of the naming?
I say that MS is more likely to start porting Windows off x86 again than Apple is to bring MacOS X to x86. My opinion, is all.
I agree with you there, but I think that neither is very likely. I do not share your view that .NET is really a swing towards cross-platform development; it seems much more like a simplification and redesign of the various Windows APIs. If you think about the features, some of them could really make cross-platform development easier, but all of them make Windows development easier.
Windows gets a much better, more unified API. Windows applications can be ported to other architectures. Windows developers can have seamless language interoperability. Windows business desktop and server operating systems can have better security controls. et cetera
Even other platforms acquire implementations like .NET, it isn’t quite correct to say that Microsoft will be left heading the project. Microsoft spent *way* too much time bringing in a lot of third parties to design .NET so that it would be useful for a lot more than just Microsoft software.
I do sense a change in Microsoft’s hard-nosed attituted toward all things open source and standard, even if only a little. Strange, isn’t it?
Bill Gates says “.NET is more complicated than getting to the moon or designing a 747. With the new design we implemented in our coming versions of windows, we believe that it will also be able to complete your work 300% faster than any compeditor’s product, be more attractive to nerds than most super models, and command a following greater than Jesus. .NET is this revolutionary folks.”
Bullocks. It is just another VM based framework which uses XML technologies extensively. I do not see any innovation in it.
MS created Web Services hype to promote .NET, such as, everybody was thinking web services is directly connected with .NET. That was because, it was the only viable way of promoting it. What else do they have? Couple of crippled and extended languages to fit into CLR, Java clone called C# with couple of improvements, just another VM implementation etc, in short, just another Windows only framework from MS. They did not give .NET’s all specs to ECMA. For instance, Winforms, ADO.NET, Enterprise Services framework etc to bash its cross platform implementations. Luckily, Web services hype is fading away after couple of years. In the end, people are starting to understand Web Services is an XML based B2B framework, which is more extensible, but less efficient (int terms of speed wtc.) than current frameworks such as CORBA, and thus have a small usage in the real world. And in the end, .NET also is loosing its momentum at its startup. Here, everybody is shiting to Linux and Java.
Why should I use .NET for the god’s sake? Me, for instance, don’t need .NET. Java is better, since it is cross platform already, and have lots of products to deal with web services.
Oh, also I think .NET is a very, very bad name.
It’s quite telling that even in a fairly tech-savvy audience such as OSNews, the majority of people are still asking, “What’s the point?”
Generally a large technological shift is accompanied by such feelings from people unfamiliar with the technology industry, because they are not “in the know” enough to understand the implications of said technological shift.
The fact that this shift is accompanied by such feelings even from those who are, presumably, “in the know,” is quite telling about the whole .NET strategy. I’m not against .NET, in fact, I think in many ways it is a good move for Microsoft. The simple fact that they are updating and unifying across the board their API’s is a great move. To know that, whether you are writing a quick app in VB, or a complex application in C++, you have access to the same APIs is great news for programmers. I remember the one project that I did on a Microsoft platform was an absolute nightmare, as there were numerous incompatible API’s for every step of the process.
As an aerospace engineering student, Mr. Gates overstepped his bounds in his comment concerning the difficulty of making his product. Putting a man on the moon is one of the most amazing engineering feats as of yet. Thousands of aspects and uncertainties had to be addressed that meant the life or death of our astronauts. To have hundreds of companies working together toward a singular goal is what made this country great at the time. Not just one company, but hundreds with relatively primitive forms of communication between. That is difficulty.
Nevertheless, Microsoft executives acknowledge that the company overused the .Net name.
I.NET don’t.NET know.NET what.NET they.NET mean.NET. Overused.NET? Microsoft.NET? 😉
I read the linked article and despite all the explanations and excuses they tried to use, when you boil it down .NET is simply Java reincarnate. If you want to nit-pick, then fine, but all that .NET does is allow write-once, run-(we’ll see)anywhere. There are slight differences and some improvements, but what they are doing is NOT revolutionary, it’s evolutionary.
Java didn’t reach the potential that it had (largely due to Microsoft’s shenanigans…but I digress) and it left something to be desired. Microsoft merely waited for somebody else to take the chance and innovate (Sun) and are building on somebody else’s hard work. The 2nd implementation is always better, so, naturally, .NET might seem like some great thing to some people.
Personally, I don’t care what they do. I think Microsoft is a criminal organization with no regard for its consumers and I will never knowingly use Microsoft products again, but I get annoyed when other people fall for the hype and follow along. You can paint .NET pretty colors and call it revolutionary, but you can also paint a turd and call it revolutionary, but it’s still a turd.
And as a side note, I don’t give that (the arsTechnica) article much credit anyway. Anybody that uses the word “Whilst” 3 times in one paragraph is just trying too hard to sound intelligent.
null_pointer_us:
Ok, ok, I get the point. I don’t know why they didn’t just pick a new name either, but I was merely attempting to see and defend their side. Honestly, I think they should have just called it “StarOffice LE” and then called the pay one with the extras “StarOffice: Professional”. I think Sun would have let them use the trademark. But OpenOffice.org is the name of the organization, and the software and the whole project outside of Sun, so they may have been better off with a new name.
I still think MS could start supporting multiple HARDWARE platforms, like they did in the NT4 days. They have already committed to supporting three: IA-64 (Itanium), x86-64 (AMD Hammer/Opteron), and IA-32 (i386 and up). Ok, IA-32 to IA-64 might be a relative no brainer, but Itanium is VERY different.
Anonymous:
Um, yeah, about that 747 and getting to the moon, comment. I must do agree, Gates may have tripped on his ego there. I don’t care if MS has spent over $2 billion, it’s not much compared to designing from scratch a new or better way to get hundreds of people 35,000 feet in the air safely. Not to mention getting people through empty space to an airless moon.
CroanoN:
I think Colin LeMahieu was joking. Calm down.
Bullocks. It is just another VM based framework which uses XML technologies extensively. I do not see any innovation in it.
It’s awfully hard to look for innovation while huddling in a dark room with your head between your knees.
Couple of crippled and extended languages to fit into CLR
Do you just make this stuff up out of thin air?
Java clone called C# with couple of improvements
C# is not a Java clone. J# is the Java clone.
just another VM implementation
.NET does not use a virtual machine. All .NET languages target the IL, and IL code can either be precompiled (a.k.a static compilation) or use a variety of JIT techniques. There is no .NET VM, and there is no bytecode. MSIL is fundamentally different from bytecode, and it was created for a different purpose.
They did not give .NET’s all specs to ECMA.
Microsoft did not give .NET’s specifications to ECMA because .NET has NO specifications. .NET is just an *implementation* of a *platform* that was submitted to ECMA.
For instance, Winforms, ADO.NET, Enterprise Services framework etc to bash its cross platform implementations.
Those are all Microsoft-specific technologies. If you are going to fault Microsoft for not making going all out to provide a complete cross-platform solution so that all Windows apps can be ported to competing platforms (i.e., MacOS X, Linux, etc.), then you may as well hate the fact that the sun comes up. Frankly, neither is worth reading about.
And in the end, .NET also is loosing its momentum at its startup. Here, everybody is shiting to Linux and Java.
People said that about light bulbs, too, but then candles just sort of died out.
Why should I use .NET for the god’s sake? Me, for instance, don’t need .NET. Java is better, since it is cross platform already, and have lots of products to deal with web services.
I do not recall anyone demanding that you use .NET.
Oh, also I think .NET is a very, very bad name.
Yeah, that proves that .NET has no technical innovations. 😛
Seriously, though, the real problem is a combination of poor marketing combined and massive media hype. If people in the media had the amount of integrity so many people credit them with, they would have researched their articles and explained it much more clearly. At present there is little more than mindless dribble in the media and a lot of angry, ignorant developers.
Thankfully, OSNews and Ars are beacons of light in this dark, foggy world, although I cannot help but wonder why Eugenia has been so silent on the subject lately.
Generally a large technological shift is accompanied by such feelings from people unfamiliar with the technology industry, because they are not “in the know” enough to understand the implications of said technological shift.
*sarcasm* Uh oh, you’ve been thinking…don’t you know that you’re supposed to be bashing M$?!
I think in many ways it is a good move for Microsoft. The simple fact that they are updating and unifying across the board their API’s is a great move. To know that, whether you are writing a quick app in VB, or a complex application in C++, you have access to the same APIs is great news for programmers. I remember the one project that I did on a Microsoft platform was an absolute nightmare, as there were numerous incompatible API’s for every step of the process.
Wow, someone who actually understands the *real* point of .NET!
As an aerospace engineering student, Mr. Gates overstepped his bounds in his comment concerning the difficulty of making his product.
Excellent point!
I read the linked article and despite all the explanations and excuses they tried to use, when you boil it down .NET is simply Java reincarnate. If you want to nit-pick, then fine, but all that .NET does is allow write-once, run-(we’ll see)anywhere. There are slight differences and some improvements, but what they are doing is NOT revolutionary, it’s evolutionary.
You really have no idea what you are talking about, do you? Evaluating .NET as a hypothetical “next Java” is pointless because the two products have very different goals. .NET was primarily intended to make life easier for both Microsoft as the maintainer of Windows API’s and Windows developers as the people who develop software for Windows. The fact that certain parts of the platform that .NET implements are standard is merely icing on the cake.
Java as a *desktop* development platform is not terribly important to Microsoft. No one writes important Windows desktop applications in Java, nor does Java lure many desktop developers away from Windows. You are severely overestimating your position if you believe that there is a Java desktop development market to be crushed.
And as a side note, I don’t give that (the arsTechnica) article much credit anyway. Anybody that uses the word “Whilst” 3 times in one paragraph is just trying too hard to sound intelligent.
You just cast aside the most intelligent piece about .NET that’s been linked to from any part of OSNews in the past few months. It’s very irritating to discuss a product with people who do not even care to understand what it is. Where I come from, we call such people trolls. Of course, this comments section is different. Here, we call them irate and slightly paranoid Java developers.
I still think MS could start supporting multiple HARDWARE platforms, like they did in the NT4 days. They have already committed to supporting three: IA-64 (Itanium), x86-64 (AMD Hammer/Opteron), and IA-32 (i386 and up). Ok, IA-32 to IA-64 might be a relative no brainer, but Itanium is VERY different.
My mistake. I thought you meant that MS went on an open-source binge (free as in beer, bad pun intended). I think that supporting multiple hardware platforms becomes significantly easier with .NET, so that is probably one of Microsoft’s goals.
I wonder if anyone died in the process of developing .NET.
There have been several deaths, quietly covered up, thus the inclusion in the new EULA that you agree to hold Microsoft harmless when it occurs.
I say that MS is more likely to start porting Windows off x86 again than Apple is to bring MacOS X to x86.
Except that large portions of Windows written since David Cutler left were done in Visual Basic, which isn’t portable. When Compaq found this out they realized that running Win2K on Alpha was basically impossible and immediately threw in the towel on the task.
Except that large portions of Windows written since David Cutler left were done in Visual Basic, which isn’t portable.
That’s not true. VB7 code is compiled to IL, which is portable to any architecture to which Microsoft decides to port its MSIL compiler. Ditto that with C, C++, C#, J#, Delphi, COBOL, and any other language with a compiler that can target MSIL.
That is one of the reasons why they call it an *intermediate* language – multiple languages get compiled into MSIL, which in turn is the only language the optimizer understands. An IL has certain advantages, and MSIL happens to be designed to handle many different types of languages on many different platforms.
america’s superpower status is due in large part to is superior performance of its technology company.
America’s superpower status is due to being the only country with an intact economy after the Second World War and by finishing the Cold War without collapsing. The Cold War was settled the way it always would have been: not by being right, but by being left.
NET does not use a virtual machine.
It does, it does’nt matter if it is JIT compiled or static compiled it is still executed in a virtual machine, the object model of .NET is not possible to implement with a simple runtime like a C/C++ programm.
“B” the predecessor of C was in fact quite similar in this aspect to a staticaly compiled .NET application, it was compiled to machine code but some things that C/C++ handles at compiletime was infact handled dynamicaly at runtime.
“…and there is no bytecode. MSIL is fundamentally different from bytecode, and it was created for a different purpose.”
In what way? Exept for the fact that MSIL is implemented in a way that makes it more or less impossible to use in any way exept JIT or static compilation? Dynamic agressive optimization like in HotSpot or Jrockit is eg. out of the question (but I might be wrong).
It does, it does’nt matter if it is JIT compiled or static compiled it is still executed in a virtual machine, the object model of .NET is not possible to implement with a simple runtime like a C/C++ programm.
No, it does not. .NET has no notion of a “virtual machine,” MSIL is not a virtual machine language, MSIL code does not execute in a virtual machine, and the common language runtime is, in fact, a runtime.
In what way? Exept for the fact that MSIL is implemented in a way that makes it more or less impossible to use in any way exept JIT or static compilation? Dynamic agressive optimization like in HotSpot or Jrockit is eg. out of the question (but I might be wrong).
In several ways. MSIL is an intermediate language (IL) which is a language specifically designed for easy translation from many different source languages (i.e., C#, C++, Delphi) so that compilers can use the same back end to process the code for many different source languages.
This approach has numerous advantages. First, it greatly lessens the work required to build the back end. The same optimizer and machine code generator can be used for many different source languages. Second, an IL makes it much easier for different source languages to interact with each other.
An intermediate language and a virtual machine language are two different concepts with different goals, but they can be made to do the same thing. Equating them, though, would be like saying that the poastal service and a computer are the same thing because they can both send mail.
MSIL was designed to provide cross-language compatibility and machine architecture independence. Java bytecode handles the second but not the first. But the first is of much more importance to Microsoft and Windows application programmers, while the second is merely the icing on the cake for Microsoft.
The most important feature of .NET is the fact that it provides virtually seamless cross-language compatibility. Microsoft writes an API once, and it can be easily used with any language that can target .NET. No more clunkly COM code, wierd API release schedules, or wacky exception rules.
This cross-language compatibility also enables Microsoft to unify its runtimes; instead of providing several different runtimes each catering to specific languages, Microsoft can use the *same* runtime across many languages. Hence the CLR.
This same language compatibility feature can also be very useful to software developers who typically use multiple languages because it provides them with the same seamless language interaction. A VB developer can join a C++ project and contribute code that uses and is used by C++ without the cludgy COM syntax and restrictions.
Microsoft’s only real interest in machine architecture independence is that it grants Microsoft the ability to port Windows itself to non-x86 platforms with relative ease. Not only will Windows work on the new platform but also all software targeting .NET.
Each .NET application includes its IL code, so you could pick up, say, Microsoft Office in 2004 and use the same disk to install it on an entirely new architecture in 2006 provided said architecture has a MSIL compiler.
It would be ridiculous to assume that Microsoft’s chief goal with .NET is the same as Sun’s goal with Java – to make all applications that target .NET automatically portable to other platforms (i.e., Linux, BSD, UNIX). Microsoft needs that about as much as they need their offices filled with thousands of drunk monkeys.
“MSIL is not a virtual machine language, MSIL code does not execute in a virtual machine, and the common language runtime is, in fact, a runtime.”
It is not, things like dynamic calling of interface methods, and fully accurate garbage collection cannot be done in a “pure” compiled language.
“In several ways. MSIL is an intermediate language — which is a language specifically designed for easy translation from many different source languages”
Intermediate language has nothing to do with cross-language support, even if it can be used for that purpose, an intermediate language is an intermediate form used in a compiler. The main purpose of an IL is to enable optimization that would be hard or impossible in source code or in machine code. A compiler may (and often do) use several differnet ILs on its way to compiled code. Cross platform support and cross language support is other important uses for IL but not the main purpose most one-language one-platform compilers use ILs too.
Most ILs is implemented as a virtual language implemented for some form of imagined virtual machine (there are exceptions), they usualy has some hig level features (like objects and variables) and some low-level features (like registers and stack access).
MSIL and java bytecode both can be considered as some kind of “out of compiler” IL. But the fact remains they differ rather significantly from most ILs, first they are implemlemented as bytecode for a virtual stack machine, wich is a very bad choice for a real IL as it realy complicates most optimizations, most bytecode instructions is heavily dependant of the previous instructions and cannot be moved easily. No one would implement an in compiler IL that way.
But a stack based IL (like java bytecode and MSIL) has other advantages, it alows fast (but not always effective) register allocation, fast bytecode to machincode translation and so on (that’s why MS uses it) and so on.
There realy isn’t that many real differences between java bytecode and MSIL, MSIL has some features to make it easier to implement (some) different langauages (parameter passing etc.), an other mayor differens is that MSIL bytecode does not specify data type in the instructions wich makes JIT compilation slightly faster but instead makes fast interpretation or dynamic compilation harder.
“It [CLR] is not [a runtime], things like dynamic calling of interface methods, and fully accurate garbage collection cannot be done in a “pure” compiled language.”
The CLR is just another fully compiled DLL that your fully compiled (formerly MSIL) executable calls to handle automatic garbage collection and everything else that the CLR is needed for. It is not a virtual machine.
Consider this, interpreted languages (like VB ‘Classic’ and Java) are not possible to create in the .NET architecture for the CLR. All code must be fully compiled before any execution or debugging can happen.
Read the first sentence under the word ‘Java’ on this page if you are unaware that Java is an interpreted language (and no CLR language ever will be):
http://java.sun.com/docs/overviews/java/java-overview-1.html
This is not a flame. You seem pretty knowledgable, but you are wrong about this particular point.
This website catalogs lots of them:
http://www.wsindex.org/
The CLR is just another fully compiled DLL that your fully compiled (formerly MSIL) executable calls to handle automatic garbage collection and everything else that the CLR is needed for. It is not a virtual machine.
You are wrong, there is no major differens between the MSIL and java bytecode is constructed they are both costructed as a language for a virtual machine. Even if it is true that early JVMs was interpreted but that is not true any more. Today all mayor JVMs are eather JIT compiled (like IBMs JVM), dynamically compiled (like SUN JVM), or natively compiled (like gcc).
MSIL certainly not as different in this aspect as you might think, the earliest beta versions of CLR was in fact interpreters, newer betas and the releases version uses a JIT compiler.
The fact that MSIL images is saved in EXE files and DLLs might seem like they are fully compiled but they are not, Microsoft just uses the EXEs and DLLs as containers for MSIL.
Not even when you compile a MSIL image staticaly it works in any way similiar to a C/C++ compiled program, there is just to much things that must bee done at runtime like calling interface methods must be done dynamicaly.
It seems to me that the only point worth making regarding the differences between the Java JVM and .NET CLR is that the .NET CLR ultimately executes what is called “Managed Native Code”. This means that the code is indeed ‘native’ to the processor, but it is also managed. A CLR on x86 executes “managed native x86” code and a CLR on SPARC would execute “managed native SPARC” code, (and so on for MIPS, Alpha, etc.). Most of the code does get completely natively compiled, just like in C/C++, and that is why you won’t ever see interpreted environments in .NET.
This diagram explains this a little more:
http://safari.oreilly.com/main.asp?bookname=dotnetfrmess2&snode=23
Java JVM, on the other hand, is always compiled to Java bytecode, AFAIK, and is the same on all hardware platforms (x86, SPARC, MIPS) which is non-native to the processor and inherits various performance drawbacks as a result that CLR does not have (because it optimizes compilation further to the target hardware than Java does).
So, you may be right that, strictly speaking, the CLR is technically a VM, but it is not a VM that is anything like the Java VM because the CLR’s code is mostly (80-90%+) natively compiled before it is executed (although not quite 100% like C/C++ is).
CLR’s code is mostly (80-90%+) natively compiled before it is executed
That is exactly what a java JIT compiler does, no difference.
It might be of interest for folks to know that the C++ compiler that comes with the .NET SDK is capable of creating either C++ (100%) native code or CLR (less than 100%) native code based simply on a /CLR command-line switch:
http://safari.oreilly.com/main.asp?bookname=dotnetfrmess2&snode=18
“…Given this simple program, compile it using the new C++ command-line compiler shipped with the .NET SDK:
cl hello.cpp /CLR /link /entry:main
The /CLR command-line option is extremely important, because it tells the C++ compiler to generate a .NET PE [Portable Executable] file instead of a normal Windows PE file.
When this statement is executed, the C++ compiler generates an executable called hello.exe. When you run hello.exe, the CLR loads, verifies, and executes it.”
This illustrates how closely CLR native code is related to standard C++ native code – the same C++ compiler can create either. Can the same be said of any C++ compiler out there and any Java VM? I am very doubtful.
This illustrates how closely CLR native code is related to standard C++ native code
It does not what you have created is a managed C++ application, not a real C++ application. Managed C++ is a subset of the C++ language, with some additions to fit into the managed world of CLR.
As for C++ compiler for JVM, i have seen a few (there is eg. a LCC backend that generates JVM) but they more or less stymped.
If you use a pair of special delimiters within your ‘managed’ C++ code, you can co-compile and execute encapsulated blocks of standard ‘pure’ C++ statements that use pointers or assembly language or any other non-CLR C++ capabilities. The two types of code can be mixed together freely in a single EXE or DLL (fully compiled by the same compiler) and this again shows how closely tied they are in some fundamental ways.
More than likely, Microsoft’s debugger will let you trace through an execution path that combines these two separate types of code with no problems whatsoever – they are good at stuff like that.
Combining managed/unmanaged C++ is actually pretty slick and potentially very powerful and useful (or just dangerous, depending on your point-of-view), and the Java world doesn’t seem to have anything like this capability of mixing C++ and Java VM code together – correct me if I’m wrong.
…you can co-compile and execute encapsulated blocks of standard ‘pure’ C++ statements that use pointers or assembly language or any other non-CLR C++ capabilities.
One of the most important goals in the design of java was to achive the higest possible platform independence and the ability to encapsulate pure C++ statements into java would obviously be a violation of that goal.
As .NET does not have the same goal of high plattform independence interfacing with pure C++ is simpler from the ordinary programmers point of view.
The standard java to C/C++ interface JNI is not exactly seamless, but from my own experience with it I can say that it is not in any way as complicated assome people may make you think. But .NETs way is simpler beacuse of the reasons stated above.
The two types of code can be mixed together freely in a single EXE or DLL (fully compiled by the same compiler) and this again shows how closely tied they are in some fundamental ways.
From the ordinary programmer POV yes, but technicaly they are not.
… the Java world doesn’t seem to have anything like this capability of mixing C++ and Java VM code together
when you compare .NET with Java you realy compare one particular product (made by Microsoft) with a whole branche of products (made by many different manufacturers).
I am aware of at least one product that can mix C++ and Java, compile it with the same compiler and debug them in the same debuger:
With the GNU Compiler Collection (GCC), you can compile C++ code with the C++ compiler backend and compile java sourcecode or bytecode with the java backend (gcj), with CNI (cygnus native interface) you can sew the pices
together almost seamlessly and you can debug the java and C++ code together in GDB.