James Gosling has called Microsoft’s decision to support C and C++ in the common language runtime in .NET one of the “biggest and most offensive mistakes that they could have made“.
Huge security hole in .NET?
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
the important part in this article IMHO is,
“Sterling also gave the debate a reality check when asked of his personal knowledge of .NET developers actually implementing C or C++ code under a .NET framework. Of the approximately one thousand developers that Sterling knows, he could only recall one directly developing under the C++ code. Whether this indicates an unwillingness on the part of developers to utilise code that is unsafe is not clear.”
this explains a lot.
What do you expect…Gosling is the creator of a competing platform. And one that has its share of offensive mistakes.
-G
<quote>James Gosling, who is currently CTO of Sun’s Developer Products group and the father of the Java programming language…</quote>
Pure and simple. Doesnt take a developer to read that and know it is spin.
whenever I tried to program c++ on .Net, I found that the overhead of running an app compared to a c# app was not tolerable. The debugger barely worked in c++ .Net and the speed was just horrible. Click a c++ .Net button on a form and wait 2-3 seconds for the event to be registered and sent to the debugger. Any programmer intending to program .Net quickly decided c++ was not ready for anything except even greater pain and suffering.
umm.. it is managed code so you do not get buffer overflow problems…..
my whole thing about it is why would you even try to relate the languages to C and C++? they basically made up a new language that tried to marry the safety of Ada and flexibility of C/C+… unfortunately you get a semi safe language that is a muddle to work with.
Author of article (intentionally?) doesn’t say a word about why allowing “old” unmanaged code in .net is extremely important [for Microsoft].
Not every piece of .net software will be developed from scratch, I think mostly it is used to advance existing applications. Considering that neither C# nor VB.net are compatible with their predcessors (C++ and VB6/5), many companies just won’t port their application source code to .net platform.
Well, VB6 code is somewhat easier to port to .net; VB6 has managed code/runtime already. Should have, actually – complicated VB6 apps include handful of unmanaged tweaks and hacks to make application look better and run faster; porting these hacks is real nightmare.
For C/C++ code things appear worse. Much code originates from C times, often many coders with different coding style have modified existing code and so on. Porting these apps to managed C# usually needs two major stages – changing language (C/C++ to C#) AND redesigning some/big part of code internal logic. The latest is harder and tends cause bugs.
Using unmanaged code (not necessary for entire application) second step is mostly avoided. Some little syntax changes do not break you application, time to port is short.
In short – allowing unmanaged C/C++ code in .net applications favours more developers switching to .net. As a little bonus for Microsoft, these applications will remain single-platform too (vendor lock-in).
Of course this creates problem – those unmanaged .net apps will remain unmanaged, nobody will recode them second time. IMHO this problem isn’t “security hole” though – otherwise almost all current OS and single-platform (and much of cross-platform) code can be considered “security hole”
i think he means expensive mistake. damaging to MS in the long run (or short run). “offensive mistake” makes no sense to me. perhaps this is just the latest management buzzword.
Probably “offensive” to people who try to code with it, or use the resulting code? They might end up having to make so many compromises that it’s hardly C++ anymore
.
That’s all fine but in Java, I can use the JNI to:
– Pin an object into a single location in memory so it isn’t garbage collected.
– Call private methods.
– Use the memory image of one type as another type (using magic such as Ljava.lang.String.
– Avoid all the type and memory safety.
At this point the argument is ‘oh but only trusted code can call this stuff’. This is true thanks to the SecurityManager, but I’d be surprised if this restriction was implemented in the .NET VM. In fact I’d imagine that in some cases untrusted code will need to call such native APIs, Java allows this too using the javax extension mechanism. Again, I’m the moral equivalent of this will be in .NET.
All in all, it sounds like both VMs can be safe if you stick solely to code that runs inside them – both can be subverted if you call native code.
If you look at CLR it all about IL. There are two kinds of IL code: verifiable and not. You can write both. If you want verifiable IL you must deal with some restrictions (example, almost no pointers). In Java you can do less then with verifiable IL in .NET. On C++ you can write verifiable code the same way as in C# (do not use pointers, …). But with C++ you get templates, preprocessor and other stuff which is unaccessable in C# and Java languages. In VC++ 2005 you have STL and still get verifiable code. Another cool feature is that you just add /CLR too complipe old C++ application as .NET application and then extend it with code on C# or VB.NET (of course it will be with unverifiable IL). So .NET gives some nice opportunities beyond whose Java provides.
James Gosling has nothing to tell. And by the way C# is a better language than Java.
“But with C++ you get templates, preprocessor and other stuff which is unaccessable in C# and Java languages.”
Have you looked at Java 1.5 friend? It has support for generics as one of its many improvements.
Another thing is that I go to school where Bjarne Stroustrup is a professor and one of the faculty working with him has said that CLR has terrible overhead and that they would never have even considered doing what Microsoft has done.
Java’s templates are no where near C++’s templates in terms of functionality. Use C++’s templates and then go back to Java. You’ll see a big difference.
I do program on Java 1.5 every day. Generics implementation in Java weaker then in .NET (but I may be like language support of generics in Java more). Generics and templates are very different things (that is why they are called differently
). Templates are just very powerful syntaxic templates while generics are generalized types (in C++ List<T> is not a type but List<int> is a type). Just look at generics and templates in detail.
1. no ref parameters (I think that is a JVM limitation)
2. checked exceptions (see below)
2. no structs (much more pain to tune code for better pref)
3. no delegates (Swing app soucre code is ugly)
4. no properties and indexers (it make my code more ugly)
Checked exceptions. They just broke the concept of exceptions when an intermediate layer code only deals with exceptions it can handle.
Example: there is an interface DataResource and an algorithm in methods void doSmthWithResourceMethod{k}(DataResource resource) which manipulate with the resource using some methods of DataResources. Now trace the changes in the code you have to make when you add an implementation of DataResources using Stream IO, then add an implementation using Database,… Why should I add all this exception to my methods. Upper layer code is the only place I want handle them.
Today in Java I have the only one option to leave interfaces (such as DataResources in the example) without lots of specific exceptions. I can wrap these specific exceptions with RuntimeException. But then I have some problems in my upper layer code.
it has been said above, but to be concise:
1) both .Net and Java have the ability to determine if code is safe before executing it
2) both .Net and Java have the ability to call unsafe code
3) .Net can block unsafe code from running. For example, much like Java applets, in the future .Net will allow users to run applications loaded from remote sources (all part of the Avalon framework) – in this example .Net will not allow insafe code to run.
James is talking FUD. When and where it counts, .Net will implement security and enforce safety. Where security doesn’t count, .Net can use unsafe code.
Why does anyone feel the need to bash .Net or Java? Is this some sort of Ford vs Chevy kind of mentality? Do we men really need to have such irrational brand loyalities?
Well, since you brought the subject of checked exceptions, i must say that i really cannot understand how such a bad idea still exists in Java!
When i learned Delphi, one of the most pleasing features the language had were exceptions! If there is some error, i just raise (throw) an exception and forget about it. Somewhere else i handle the exceptions, either with a generic handler or with specific handlers. I don’t care how much stack will be unwinded!! But with Java, every function must explicitely tell the compiler it will let an exception pass… It’s almost like C, where you must check the return code and return another (or the same) error code until a function can handle the error…
Oh, and i can’t see how some people say Java is fast if it uses 100MB of memory for very simple things… It will cause swapping and swapping is not fast… Windows XP likes to swap background programs to disk if they are not used for a while (most likely to leave more physical memory to the foreground app), and this approach becomes terrible with 100MB apps!!!
DonQ made the important point about existing code. Reengineering existing software is largely considered a waste of time, money, effort, and everything inbetween unless the alternative presents an insurmountable problem. Witness the volume of Carbon applications, and the fact that new ones continue to be created, despite Cocoa being the “native” language of Mac OS X. The differences don’t relate to managed/unmanaged code, but the central point – of swapping one language for another and one set of APIs for another – remains.
The central argument supporting conversion to managed code is that, as new applications are created using managed code and existing applications are re-engineered using managed methods exposed in .NET (if there are any of these), this will lead to a lower number of possible exploits and thus a lower number of actual exploits. While that’s probably true, it assumes that no additional exploits become possible through the use of the .NET framework, which is a silly assumption. It also assumes a widespread takeup of managed code, presumably through developers upgrading to the latest VS and then just happily using whatever Microsoft gives them. Experienced developers can attest to development packages being standardised on and used for many years beyond the point that they become inconvenient for the vendor that created them.
However, I have to question Gosling’s position. I believe Sterling’s anecdote about the number of developers actually doing this, and I believe his implication that this is true across the broader .NET development community. As DonQ stated, this is a tactical move by Microsoft to make .NET more attractive to existing Windows developers, and particularly those who are existing VS customers. It means they have the option to upgrade on their own timetable, and not lose out their existing code in the process.
unsafe code is the same as JNI code in Java.
The difference is, that .NET makes using JNI a lot easier..
And that’s a good thing for some people.
If you don’t want to handle checked exceptions, you could always just enclose any code that throws exceptions in a try block and then rethrow any exceptions that occur as a RuntimeException. That way, any changes are pretty much localized.
Checked exceptions are there to force you to do something about the errors. I do think that the Java designers got carried away with the implementation though :-).
1. no ref parameters (I think that is a JVM limitation)
This makes Java a more clear language..
2. checked exceptions (see below)
Altough I understand people don’t like checked exceptions, I think they’re a very nice thing to have.. It forces you to handle error
2. no structs (much more pain to tune code for better pref)
There’s no diff.
3. no delegates (Swing app soucre code is ugly)
True..
4. no properties and indexers (it make my code more ugly)
True, but in .NET properties are just syntax sugar.. The compiler will just generate getters/setters for the properties.. This could be done in Java with minor adjustments, and I think they should…
It’s just annoying to have so much lines of code that does nothing…
I’ve been learning the additions to C++ that make up the C++/CLI standard, in which you code your managed applications in VS2005. The compiler was several /clr options. The old one that mixes native and managed code, one that spits out managed but unsafe code, and one that spits out verifiable managed code. So you can output safe code, at least in VS2005. I don’t know who’d use the underscore madness of old Managed C++ in VS2003 though.
I am compiling my test code into verifiable managed code. I chose to tinker with C++/CLI because I get templates and a preprocessor, things I miss in C#. So I can’t await the release of it.
And what that guy earlier said about C++ in .NET being dog slow, that sounds like complete bull to me. I didn’t encounter performance issues like he claims to have seen, no with C++/CLI, nor with Managed C++.
he has a right to hate, because MS simply copied java, to kill java and tries to take the shine.. look at those guys trying to copy every single good open source java project to the .Net, without a real reason not to use java..
> It’s just annoying to have so much lines of
> code that does nothing…
It means that Java is not an expressive language. The reasons it’s not expressive are the reasons that “make Java a clear language” (haha, irony). But the programs you write aren’t clear, because you have to write boilerplate code. Let’s see if Java 1.6 (6.0?) keeps improving…
Java is much more open than .Net .. There’s both open source implementationf of .Net and Java but M$ thinks they can sue those while sun just lets you license ’em
Managed C/C++ are managed languages. Which means they run within a sandbox. You can’t create buffer overflows in these langugages. Likewise, if you force an invalid cast of one object type to another, it won’t crash the CLR. It will simply cause an exception to be thrown. This is no different than any other kind of application exception.
Gosling seems either willfully ignorant of these issues — or he’s trying to hype other people’s ignorance to promote FUD. I have a difficult time believing that Gosling is a stupid man. So, my only conclusion is that he’s being dishonest here.
Face it, Jim: I like Java — but it’s lost its luster in recent years. .NET has proven itself as a stable and robust dev platform. I realize that that threatens Sun. But a threat to Sun doesn’t justify out-and-out lies about .NET and Managed C/C++.