Slashdot Mirror
Bill Joy's Takes on C#
f00zbll writes: "Cnet is running an article by Bill Joy on security and how it relates to C# and Microsoft at large. BJ quotes verbatim: 'C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth.'"
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Sure, it'd be great (for Sun) for everybody to rewrite the world in Java, but in reality nobody can justify requiring 50% higher CPU usage in exchange for the ability to let programmers be careless.
I'm not saying Java is a bad thing at all, merely that C# isn't any worse than C, C++, perl or python. It's a shame when a press release manages to get linked from slashdot's main page, but that's all this is. Sorry Joy, but I'm not buying it.
At best it would be C double flat
Take on the C
"Bill Joy, co-founder and chief scientist of Sun Microsystems, is the principal designer of the Berkeley version of the Unix operating system (BSD) and a co-author of "The Java Language Specification."
.NET. What a shock. he's usually so balanced and objective.
So he doesn't like
Ah well, when he gets stomped flat again he can always sue, that seems to be sun's primary strategy these days.
--> Fight tyranny and repression.... read
You can use C# to write "Unsafe" code, but it's the runtime that ultimately decides whether or not to let it run. For example, if the VM that the browser creates tries to launch a C# app downloaded from the Internet, and it's "Unsafe", the CLR will refuse to run it.
Difference between C# and ActiveX in this case is that in ActiveX, everything is "Unsafe" and you either take it or leave it. In Java, of course, everything is "safe". C# can go either way.
I really hope that Microsoft simply makes it impossible to run "Unsafe" CLR code in the browser. Not even an option.
- Steve
Yes, C# makes programs written by stupid programmers a tad most secure.
But I wonder why MOST of all the secure code is written in unsecure C or C++. I think it all boils down to coding practices and priorities. MS priorities are very different from that that has, traditionally, produced safe code.
Now if MS gets itself together with this 'secure' software initiative open source and linux is going to face a big challenge. My XP computer has not crashed in 3 monthes, and I use it 10, 15 hours every day in what I consider a heavy load. It's still bloatware in many aspects, but it is good.
NOT!
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
It is possible to write unsafe code in any language that gives you access to the OS. This is called "power" as in "C is a very powerful language".
The alternative is "safe" code as in "Java is a very safe language because you can't step outside its sandbox".
C# is what happens when Java developers grow beyond the sandbox.
The joys of MS programming languages.
Btw the open and close blockquote cause auto-indentation unless you force a [p] (substitute) on the line being blockquoted.
There's a gorilla from Manilla whose a fella that stinks of vanilla and has salmonella.
This sounds like FUD. He didn't really post any examples about what kind of problems C# has for security, that would have been helpful.
.NET common language runtime?
I think a lot of people are upset because MS has actually come out with something that can compare with Java finally.. The ability to write unsafe (unmanaged is what that really means, meaning the garbage collector and built in memory management features of the CLR won't touch it) is an added bonus to Java.
I think the real question is- how secure is the
What they describe sounds like an increase in flexibility for the programmer.
The objection to what C# lets you do reminds me of the time old codenazis who scream and shout about using "Goto"
The same mindset is found with those who say that M$ should get rid of the Start button in Windows. Not replace it with something better and leave it still there: just get rid of it altogether.
Wow, so Sun doesn't like MS technologies. What's next, Microsoft spreading FUD about Open Source?
"In unsafe code it is possible to declare and operate on pointers"
I'm not a computer scientist, just a unix admin. My question is: Since when has operating on pointers been considered unsafe? Pardon my lack of understanding, but with that definition, wouldn't 99.9% of all code then be considered unsafe? And does't JAAVA use pointers too? Honestly I duno..
It isn't a lie if you belive it.
Almost any tool can be used unsafely if you try hard enough. No language is going to be perfect. Hell, C++ makes C# look like Underwriters' Laboratory for safety and yet most commercial software is written using it.
We as developers are (as usual) the unsafe element in any program. Cars are not unsafe in themselves just because they kill people. It's the drivers.
Good programming practices is the key to good code. If we expect to rely on a language or environment to protect us from writing unsafe code we are shirking our responsibility to become good developers and instead breeding a whole new generation of lazy ones.
Dozens of other languages. Slashdot needs to filter out anti-Microsoft propaganda, particularly via a virtual press release from the paid hack of another would-be monopolist, and instead report on serious science and technology issues.
I still don't understand what's so evil about C#. If you don't want to use it, you don't have to. But personally, I find that not using C# leaves a sizable gap in several different keys, meaning a lot of stuff comes out just sounding wrong.
"What's so random about flipping a coin? Ever heard of the I Ching?"
There is no C-Flat. Occasionally it is written on a piece of music, but it refers to a B. Lowering a C half a step gives you a B-Natural. Someone suggested C-Double-Falt. That would be a B-Flat.
The reason for this is on the piano, the player needs to be able to look down and determine where their hands are based on the missing black keys between the notes B,C and F,E.
Although, calling C# "B" might be interesting. But then again, there was a language B by K&R that preceded C.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
to a certain degree, the more unsafe code a language allows yuo to write, the more powerful the language is. there is always opportunity for mistakes and scurity breeches, but sometimes that has to sacrificed for features. not bugs, features...
QED
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
Well no shit.
And this brings me to my point: Security is the job of the developer, not the language. The language can make it easier on the developer, but it really shouldn't be the end all / be all of secure code. For example, one way you can prevent buffer over-runs in C/C++ is by using strncpy() instead of strcpy().. As far as adding security to an insecure system as Joy writes, I have to wonder: Has Bill Joy ever written any kind of serious application? Does he know the first thing about programming? Is he *truly* advocating using "safe" languages for everything when secure programs can be written in other languages? Or is he truly willing to ban all "unsafe" languages like C, C++, Assembler, hell, it's still technically possibly to write machine code. Maybe he isn't going far enough - maybe all processors should be capable of only running Java BYTECODE natively. And yes, I am illustrating absurdity by being absurd. Joy needs to buy a clue here. I'll say it again - as developers writing secure applications is *OUR* job, not the job of the language we choose to develop in.
C# does allow pointers and pointer manipulation. This is mostly for programmers seeking extra performance. Like a cast in Java, declaring code as "unsafe" is equivalent to saying to the VM, "Hey, I know what I'm doing." C# pointers are definitely not as liberal as C ones (just like casts in Java are not as liberal as casts in C).
For those sincerely seeking an intelligent discussion of pointers in the CLR, see Gough, J. "Compiling for the .NET Common Language Runtime (CLR)" Prentice Hall, NJ 2002.
Bill Joy has not been a programmer for a very very long time - he is "a visionary" who also talks about a race of robots taking over the earth from time to time. His comments have to be taken with a LARGE grain of salt - he is far from objective - he owns millions of shares of Sun Micro - therefore he prefers Java. A couple years back he pocketed tens of millions from the sale of some of his stock. Now, what was he saying about C#?
I think Joy missed the point (intentionally?) on this.
C#, while it will be used in place of Java I'm sure, is also intended for typical application programming. Just because the language supports *clearly marked* "unsafe" (as in, the programmer is able to shoot-himself-in-foot) coding practices, does not mean that IE will allow controls that require that feature to run.
Furthermore, From what I read of C#, it is not intended to run purely by VM,and that it is -always- compiled before executing to avoid Java's slowness. Just because SOME features of Java were taken (of which, Java took most from C++!), that does not mean it has the same intention.
Last I knew, Solaris was written in C and assembly, both of which require pointer use to get very far. Is he implying that those are unsafe and insecure?
Would know that right after he quoted from C# specification about unsafe code, he quoted again
""Unsafe code is in fact a 'safe' feature," the C# specification continues, "from the perspective of both developers and users. Unsafe code must be clearly marked with the modifier 'unsafe,' so developers can't possibly use unsafe features accidentally, and the execution engine works to ensure that unsafe code cannot be executed in an untrusted environment.""
Seems like a good idea to me, whats wrong with that?
Uhh, and the problem with this is ???????
.NET Visual Studio is written in C# itself , it should be pretty thouroughly debugged before its released.
All lll allow this, C3 may not be a lll but theyre trying to appeal to the uper end of that segment.
C# allows you to write managed, OR unmanaged code as well, This is an option. As well as the coders ability to write "unsafe" code. YOU MUST INTENTIONALLY flag the code to be written as UNSAFE !
If you dont know what you are doing and choose to do this so frigging what ???
C# has the fundementals of a good language, forget its from MS, if it where from GNU, you;d be eating it up saying look how much better it is. I am looking forward to working with it, the
Play with it for a week , if youre a beggining C programmer youll love it, if youre experienced, youll love it for the same reasons, My bet is most of the people bitching havent read or written a single line of C#, if have and dont like it Id like to know explicity WHY ?, Ms bashing aside.......
Sig went tro...aahemmm.....fishing........
A language can be both 'safe' and 'unsafe'. Take a look at Perl. You can do a lot of insecure things with it. But as soon as you launch with the -T switch, your script will run in a special mode. Values coming from an insecure source will be refused by potentially dangerous functions, unless you explicitely mangle them before the call. This is extremely powerful and prevents a lot of classical security flaws.
I don't know much about C#. But a taint mode for it would make the language pretty safe, despite the presence of pointers.
{{.sig}}
.. write a C# compiler in Java!
Since it was written in C. Last i checked C has all those nasty 'unsafe' features like pointers,direct memory access,inline asm etc etc.
For crying out loud. Just because most of today's "learn java in 30 seconds" ITI kind of programmers are not properly equiped to write decent code it doesn't mean that the whole programming community just turned DUMB from one day to the other.Or that those programmers are for that matter.
Don't forget that most of today's applications that require decent performance levels are written in either C or C++. NOT java OR C#.Somehow cutting my performance in half to allow a sub-par programmer to write "safe" code with java does not sound like a good idea to me. Neither business-wise, or otherwise.
* Haskell is the programming tool of choice for discriminating hackers.
* Dylan is a fine programming tool for many applications.
* C# is for implementing slow, unsafe programs slowly
There's been alot of controversy lately over security holes in programming languages. There is one language that has stood the test of time and proven to be the most secure language of all, with a record zero (0) reported security holes.
Here is the link if you want to learn more.
I Heart Sorting Networks
And in other news, scientists after an exhuastive study have determined that bears really do poop in the woods.
Developing.....
Pope may be Catholic!
Yep, I think the guy's getting quite jealous of MS. Love or hate these people, the .net programming specification look very powerful, and coupled with the hard-as-nails win2k/xp combination, they will be quite hard to compete against.
.net services are basically going to be the same as before - just with a .net after them, and maybe re-written in C# now.
What Sun should really do is get off there behinds and match C# for features. From what I understand (not much admittedly), the Java VM just has to be extended to give it the breadth of additional languages that the CLI has (in terms of being able to use unsafe methods if the programmer wishes, so allowing C to work through it). The problem with Java has MS has the dominant desktop (and a good one it is now - really this is fact if you have to use them all day long), and they have the "standard" tools for programming. This will generate massive mindshare, and might get everyone from VB to C# (at least being "safe" might be good for programs knocked up at home).
On an unrelated topic, I think cloning the fundamentals of C# to a open-source basis is a very good idea. I might not agree how ximian are going about it, but at least the FSF has a parallel project that can bring the new language to the world - it could persuade casual safe programming, while allowing the breadth of accessing the OS directly.
When it comes to web services, I honestly can't see the difference between Java and C# (apart from the fact everyone will use C# as the MS-sponsored dominant language). It's all down to FUD: the
Java is great, but Bill Joy think he should go get it optimised - working faster, able to compete effectively with C#.
I stopped reading after this line:
-
"So Microsoft built ActiveX, a technique within Windows for automatically downloading and executing arbitrary programs"
Maybe Mr. Joy should read up some more:Anonymous posts are filtered.
This just in:
Geek writes software that crashes, film at 11.
Sun wants you to remember, C# is not Java, and is not a Java replacement.
It's just a programming language that looks like C++ but has many of the benifits that Java has. It's designed to let you migrate all that code in C and C++ without much problem...
Wait, tell me again why this is bad?
Security in .NET has been built into the foundations of the CLR, not added as an afterthought as Bill Joy implies. Read more about it at the .NET Framework Security Overview. The reason Microsoft seems so cocky about their new "trustworthy computing" crusade is because they know their new framework makes it a lot easier to follow through on their promises. Although there is still room for programmer error, that room is now the size of a broom closet, not a stadium.
Java was a step in the right direction. C# may be promoted by Microsoft heavily, but the prospect of "unsafe" code is only going to send up red flags with the average users. The average desktop user doesn't want to have to worry about safe/unsafe code - they just want to be able to browse the web safely - which is what Java already provides. Sorry, Microsoft, but Java already does better what C# was intended to do.
The society for a thought-free internet welcomes you.
"the programmer never [h]as to see or deal with those pointers" RIIIGHT
Does the programmer have to deal with...
... null object references? YES
... surprises and/or logic errors when two objrefs happen to refer to the same object? YES
... dead objects that need to be released by explicitly niling out objrefs? YES
Obviously Bill Joy knows a lot more about this stuff than I do; but I think he, and many of Microsoft's critics as well as supporters, are missing a crucial piece of the puzzle.
/. posters have make comments to the effect that MS isn't capable of delivering technically. It used to be the conventional wisdom here, for example, that any MS OS was destined to crash repeatedly.
.NET and C# are technologies that predate this new ordering of MS's priorities, and that they probably won't be very secure. Passport, the most important .NET application yet written, coded by people who ought to know the technology best, has been hacked (and patched, it's only fair to point out). If MS's people don't write secure apps with .NET, are the low end VB coders the platform is designed for going to do a better job?
/., work for one of those companies.
Many of the features that have contributed to MS's insecurity were there not because MS's engineers were too dumb to think clearly about security, but because other people decided that there was an overriding business interest that the features would serve.
Specifically, these features usually tend to be part of the MS strategy of leveraging success in one sector into another. If you use office, it makes sense to choose VB as your scripting language. If you know VB, it makes sense to run IIS. That's why there's a VB interpreter inside every office app.
I think that what we've seen from MS is an official change in policy -- they're saying that business considerations now suggest that security should be the #1 priority. They're admitting that the market will punish them for security holes, and that they can't sacrifice security to establish leverage from one sector to another.
MS has always put business concerns over technical ones. For that reason, a lot of
It turned out that when MS saw Unix and Linux as a threat, and when they decided that reliability was one of the biggest advantages that Unix/Linux offered, they took reliability seriously and made enormous progress in a relatively short period of time. This suggest that Windows crashed not because MS *couldn't* make it reliable, but because it wasn't a *priority* for them to do so. As soon as they saw a change in the business climate on the edge of their radar screen, they changed their behavior.
Windows and its applications haven't been secure because MS hasn't felt it was worth making security a priority until now. There is no evidence that they couldn't cover a lot of ground very quickly in security if that's what they decided to do. And it seems as if they've decided to do just that.
I do agree that
But the problem that Sun faces is that MS has proven time and time again that they're willing to spend lots of money and go through lots of iterations to take a market. They're relentless. They usually don't get it right the first time, but they usually do get it right after four attempts or so.
I'll say something else that will probably get me modded down. After the recent flirtation between AOL and RedHat, I'm not sure that the moralistic arguments against MS hold up so well. Linux has been at the center of some pretty slimey stock swindles -- our gracious hosts, here at
Meanwhile, the Bill and Melinda Gates foundation is giving extraordinary sums of money to real nuts and bolts making the world a better place kinds of causes. Gates could literally turn out to be the most significant philanthropist in the history of the world. They're giving so much money that you can almost see a chunk of what you spend on MS going to a good cause.
All of which suggests to me that politics and the morality play that have always clouded the linux vs. windows debate should probably be put to rest.
Windows is horribly insecure -- viruses do incredible damage in the real world, especially among the least sophisticated users. That's not political, that's a fact.
But they're saying they're trying to clean up the mess. Sure, it's a big mess, and sure it's going to be a big job to clean it up. I give them credit for admitting it, and to taking on the task.
Before Java, poor programming on web pages would merely mean that some pages looked ugly. Now after Java, browsing has become a matter of traipsing through a minefield of bad code causing script errors all over the place.
Time to try something else....
Really??? What gives you this idea? Java + VM is relatively equivalent to C# + CLR (as mentioned in my article that appeared on Slashdot a while ago). Code can be downloaded from the Internet and run just like with Java applets or RMI applications but this is far from the primary design of the platform .
Of all the people in the world I'd expect to criticize a technology without adequately reading up on it first, Bill Joy would have beemn one of the last I'd expect to do such a thing.
Bill Joy (and your post) go on and on about the vulnerability of network programming then ends with the reference to unsafe code which aims at giving the impression that downloaded
Sorry bill, you can cry all you want but until you can lay down the evidence of C#'s insecurities, you'll get no following.
When pointers are outlawed, only outlaws will have pointers.
I sentence you, Bill, to sit in the corner and read Kernighan's "Why Pascal Is Not My Favorite Programming Langauge".
What it boils down to is that he is complaining that C# is more powerful and less crippled.
I mean this guy is the chief scientist of Sun Microsystems and the co-author of "The Java language specification", what exactly do you expect him to say about C# ?
BJ quotes verbatim: 'C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth.'
First of all (go ahead and call me a troll, like I give a fuck): it's not nice to call someone BJ, even if their initials are in fact B. J.
"Unsafe code" has no meaning to Microsoft. I'll put it this way, code monkeys are spewing out of Devry and ITT tech (and 4 year institutions under the mask of "computer information systems" majors) daily, with no real understanding of what makes good software development, and they want a language that will be as easy as possible and will fulfill all the buzzwords like "object oriented" and "self-specification." C# will provide this, and Microsoft will support it.
~ now you know
Java has both built in safety and security. You can defeat security by using certificate or running java code as local application. however, its safety features like jvc checking bytecode, no use of pointers etc cannot be defeated in bug-free jvm implementations. c# allows you to defeat these safety features and that is the point of Bill Joy.
If you don't like it, don't use it. Your commentary is shit.
Since he's the only one who got the point, despite being an AC.
;)
:)
The whole point of a safe language is to prevent a program from accessing memory it shouldn't. This means not only buffer overruns, but the ability to fabricate a pointer itself. Which means that trusted code won't compromise security with a buffer overrun, and untrusted code can't get a pointer to anything it might want (like, say, a capability descriptor it doesn't own).
And the dynamic aspect is critical. Static guarantees are useless, because in the untrusted code case you weren't there to see it compile. But if you can run code from someone else, and be assured that the VM is going to prevent the program from doing anything it shouldn't, then running untrusted code becomes feasible.
Assuming you believe the VM itself can be trusted.
This is all from memory of a lecture I had in Adv. Op Sys almost 2 years ago, so take that as you will.
The enemies of Democracy are
Don't feel bad Bill. It's not like you had anything to do with inventing Java anyway. Go home and write a new white paper on Jxxx. It will make you feel much better.
Looking at the big picture, Microsoft is involved in very regressive politics as well. They are a big supporter of censorship (see the DMCA for example.
If you like the philanthropy of the B&M Gates Foundation, contribute to it directly and don't buy Windows.
Could someone provide a nice bit of Karma Whoreing and point to a resource about how this works?
.Net and #Unsafe are compile time "sandboxes" if you will. If your intermeadiate code violates the principles of the sandbox, its marked unsafe. All unmanaged pointers would have to go in unsafe then I am guessing.
.Net security manager, say, checks the header of a downloaded program this could be a security hole (headers can be modified). If it rescans the code/binary to make sure it matches security paramaters there is no problem with this.
From the people who seem to know how this works, it seems like
Implementation gotachas are the big deal here. If the
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
...even English. To try it, go into a biker bar and tell the toughest looking guy you liked his mother. If that doesn't do it, ask him if he has a sister. Make sure to call 911 before you do ;-)
:-)
Yes, C# has an unsafe mode. So does Perl, Python, Java Script, and guess what--Java.
The only difference is that C# lets you write unsafe code in C#. In Perl, Python, etc.. you would write a shared library (or link extensions into the language executable). And then of course you have to trust that the shared library is "safe."
Yes, there are going to be security holes in programs written in C#. Only careful programming, and as much peer review as possible can reduce those mistakes. In the end, only time will tell if an application has holes.
Long live the Department of FUD! Let's go scare some suits
--AM
Bill makes a lot of sniping little attacks on C# that really amount to very little. So what if C# looks a lot like Java? That's what all the C++ people said about Java back in the day.
.Net uses for code access security, but he plays it off with the FUD statement that the security was tacked on to the framework after the C# language was built. That statement utterly fragments once you have taken a close look at the security infrastructure in the .Net framework. It isn't perfect, but from what I've seen, the tools are there to allow the clueful to secure the box with a fine degree of granularity.
Then, he confuses the C language and it's inherent propensity for buffer overruns and various other pointer-math related problems with the C syntax - which is about all C# really inherits from C.
C# executes in a runtime context, just like Java does. You have several means for controlling things like "do I let downloaded code execute file I/O?" or "do I allow unverified code to execute?"
The crucial point here is the term unverified. The C# compiler can, and by default does, generate verifiably type-safe code. It has a compiler switch (oddly enough, "/unsafe") that enables unsafe code generation that includes unverifiable code. You have to use this switch when you use a unsafe directive in your code, and you have to use that directive to employ the pointer methods that Joy references. You might even take this a step further and think that, in an config file somewhere, there is a setting to disallow unsafe code that originated from the internet.
Bill even hints at this, and I hate to think that he is disingenuous to the point that he's failed to actually follow up and look at the mechanisms
meh.
More people sounding off that know nothing of the technology. I've built several C# apps already and I haven't had to use "unsafe" code once. He makes it seem like you can't write a C# program without using unsafe code. That's a flat out lie. Plus, he doesn't even give specifics as to why it's unsafe in the article, he just says that because Microsoft screwed up before (and they obviously did), they must have screwed up now. Unbelieveable. I wish I could get a column where I could flame anything I didn't like without understanding it.
MS Creates a language that is similar to Java, and even though it has been left unsaid by MS, they would like to lure Java programmers away fron Sun and towards .NET.
MS Creates ads in DDJ and other tech publications with benchmarks that show C# trouncing Java J2EE.
This is almost certianly a FUD tactic in retaliation to MS trying to lure developers away from the Java platform.
This is the same guy that gave key note speeches at various trade shows and symposiums about how machines will soon be smarter than people and will take over the world and kill all of us. He is a lunatic and should be regarded as such. He is clearly reaching pretty far with his argument. Instead of showing any kind of technical example of anything or any real world situation he just speculates based on a large number of assumptions.
Do the following search and replace in this article:
s/C#/Java/
s/unsafe/native/
And it still is true. Java has it's own "native" methods, which have all the same problems that C#'s unsafe methods have. In C#'s case it's a bit easier to work with because you don't have to change languages, (Java native methods can't be written in Java).
Man, I hope someone calls Joy on his hypocracy.
sigs are a waste of space
According to my copy of the C# specification, you can write "unsafe" code (pointers, etc) - but only as long as you explicity specify "unsafe" when you declare your method. In my view, this actually makes it harder to screw up than it is in C or other languages. Besides, a bad programmer can screw up in any language, pretty much regardless of the precautions that have been taken.
Every piece of code that targets the .NET CLR has to go through a verifier. Before a program is run the verifier looks at the IL to determine whether it is safe to execute in the current context.
Code which is marked as unsafe can only be used a fully trusted envoirnment. Currently, if a part of program is marked as unsafe the the entire program (called assembly) is marked as unsafe. So the entire assembly will not execute if it uses unsafe code.
There is a second level of safety defined by the CLR which requires the programmer to 'demand' permissions to do certain opertaions. When your code demands permissions by using the Demand method, the common language runtime verifies that all code calling your code has the appropriate permissions. Without these permissions, the request fails. Verification of permissions is determined by performing a stack-walk.
Demanding permissions is necessary if you are accessing protected resources or perform security-sensitive operations.
There are a number of important/useful things you need pointers for in
/* some stuff snipped */
.NET. If you look at
.NET is meant for more than
Win32.
For example, if you try to write a port monitor, you absolutely
need the fine-level control that pointers give you. A port monitor is the
way you can extend the windows printing system to use a new network protocol
for printing. All it does is basically read data and shove it over a
network, taking care of the protocol (whether it be IPP, LPR, PAP, etc), in
addition to some simple administrative things (keeping track of what
printers are using the port monitor via the registry, etc).
Now a couple of the functions for writing this require you to allocate a
struct and pass that struct to another win32 function. These structs
contain strings within them.
The catch? The strings must be allocated exactly after the struct.
Like this:
struct foo {
char *s;
};
...
struct foo *f = malloc(sizeof(struct foo) + 30);
f->s = (char *)(&f[1]);
_snprintf(f->s, 30, "blahblah");
...
If you think this is insane, I agree with you.
If you try to allocate the string separately from the struct, the printing
subsystem crashes. I have no idea what the hell the Microsoft programmer
who came up with this was doing, but that's how it works.
Win32 (even the nicer implementations of win32 like on Windows 2000) is full
of crap like this. You won't see this if you're writing a "business
application" that just does file io, network access, GUI stuff, etc, but if
you try to do anything close to "systems" programming, this is all over the
place.
What is "systems" programming in Win32? It's not just writing device
drivers. That port monitor only does file and network io. It ends up being
"systems" programming because some of Microsoft's port monitors actually
talk to hardware directly - so the basic problem is that MS got the
abstraction level wrong and windows still has a lot of legacy code that
makes bad assumptions, has poor interfaces, and generally makes programming
win32 a pain.
Of course, you could encapsulate the bad MS interface in some sort of
wrapper. That's what MS did with MFC and now with
MFC's development, you'll see that it has baloonned in size. Why? Because
more and more stuff was "wrapped", ie, MFC was extended to allow access to
more obscure parts of the win32 API. And it still doesn't cover all of
win32, so people have to extend it themselves. For instance, if you want
your application to use the system tray, you have to deal directly with the
C SDK interfaces, which are none too friendly for "managed" languages." So
you either wait for someone to make win32 friendly for your language, or you
take time away from your real work to write your own abstractions.
The way I see it,
just your simple "business applications"
where your program logic, not dealing with
someone else's interfaces, are the hard part.
Yes, java has the JNI, but that still means I have
to write C code in order to write a port monitor.
With C#, you don't have to program in multiple
languages just to get some simple task done.
The ideal solution would be to allow the "port
monitor" to be a shell script, like I can do with
LPRng. However, this is Windows, and the beauty
and simplicity of Unix is nowhere to be found.
Quotes like this one from the article:
.doc's for all my word processing needs is bad why isn't Bill allowing me to write code the way that best fits my programming needs A Good Thing?
Section 25 of the C# specification says (I quote verbatim): "C# provides the ability to write unsafe code. In unsafe code it is possible to declare and operate on pointers, to perform conversions between pointers and integral types, to take the address of variables, and so forth."
========
... make me wonder if this guy uses C on a daily basis. He seems to have succumbed to the somewhat unconscious connection between two meanings of the word "unsafe". One is that applications that allow for buffer overflows are unsafe. Another is that code that stores a few vars on the stack where nobody's watching is "unsafe" [from the point of view that it could get overwritten]. The fact that you often find you've done the first having tried to perform the second without "proper Jedi training" seems to have strengthened his otherwise unconscious connection between the uses of the word.
Sometimes it's more efficient to write unsafe code. If he hasn't seen those needs, even if the author does use C, he probably could have gotten by just about as easily using VB. To take away the ability to write 0s & 1s however you want when you *do* need to is to, as another poster put it, is a bit pedantic on the part of the people who created the programming language.
Do I want people doing VB tasks to have the ability to write unsafe code, in either sense of the word? Stereotypically speaking probably not. But if you're using C#, I don't see why not.
If Bill telling me to use
It's all 0s and 1s. Or it's not.
C# is just Microsoft's imitation of Db. Once again, they take something that's been around since the equally tempered scale and claim it's an innovation.
Only baby programmers and script kiddies and VB wienies are afraid to handle pointers.
The entire notion that pointer manipulation is unsafe is only because they let idiots write code.
Anyone with half a brain can manipulate a pointer and not fsck it up. It isn't the LANGUAGE that's insecure, it's the fscking programmers using it.
C# is crap anyway - an unholy joining of Java, VB and C++.
I don't have a solution, but I certainly admire the problem.
...before unveiling its secret weapon in the language wars:
COBOL#!
Yes, with the power of COBOL# Sun will be able to monopolize the huge untapped market of legacy COBOL code that could be easily modified and brought up to cross-platform, bytecode standards.
Since there is so much more legacy COBOL code than C/C++ (75-80% of all existing code in businesses is still COBOL), Sun will one-up Microsoft, and along with Java will be able to win over developers with its advanced security features like a rigid sandbox and no direct memory manipulation.
Next up for Sun, Java++... it's rumored that Sun's pulling out all the stops with this one, and even including a full-fledged graphical developing environment with the J++DK, complete with an intelligent "Programming Assistant" that will warn you when you're writing unsafe code! Dancing Bill Joy or paper clip graphics optional.
Light a fire for a man and he'll be warm for a day. Light a man on fire and he'll be warm for the rest of his life.
Languages that use direct memory manipulation do have drawbacks in the safe/secure area.
I don't care how good a C/C++ programmer you are, you WILL create buffer overrun situations in your code. Period. End of story.
All it takes is one program running as a priveleged user to have a buffer overrun and bam, compromised system.
Thats not to say Java doesn't have the same problem. All it takes is one buffer overrun situation in the VM and boom, compromised system. It is probably safer though, you only have one large c/c++ program that many folks are looking at.
Anyhow, my opinion.
Barjam
The safe/unsafe markings in C# simply stop a programmer from using specific memory references. It has nothing to do with security, in the way that Joy seems to imply.
A virus writer can still send a script or write a component that can be marked as 'safe', but will delete every file on the hard drive. After all, you don't need to mess with pointers to delete files.
Of course, you might need to allow the component/executable access to the filesystem, but if someone sees, "This component has no unsafe code, do you want to allow it to run?", then they're going to click 'OK'.
Sam
The article says that typically a C program failing to check for buffer overflow
.NET includes a new feature that helps mitigate some kinds of exploitable buffer overruns. There is a new /GS option in Visual C++ .NET. This new option inserts special code into the application or DLL startup code, as well as special code into certain functions' prolog and epilog code. The option is enabled by default for all new C++ projects. However, the option catches only stack-based buffer overruns that overwrite the function return address. It does not detect heap-based buffer overruns, nor does it detect buffer overruns that do not overwrite the return address.
It would be kind of interesting to point out that Microsoft Visual C++
That said, there is simply no substitute for good, secure programming practices, but sometimes this isn't enough.
I use Am so all my stuff sounds depressing and I won't get so excited if throws an exception.
Put the code in the f*cking basket!
We can do this in java too- but instead of being able to write unsafe code in java we're forced to use JNI and code in C.
ROFL
So why couldn't executable code, like ActiveX or CORBA code, be sandboxed also? This should just require that the component be put into a restricted execution context, that perhaps has lower priveleges than the user's context. The component would operate like a GUEST user, and would not have access to the invoking user's priveleges and resources, like files, etc. This guest user could have it's own scheduling priorities and quotas for a subdirectory, and so on.
All the system calls, e.g. to DLL's or DSO's would be intercepted or remapped, or something like that, so that priveleges are checked and enforced, just like java does. Since modern CPU's can trap anything from illegal memory access to code or data, to illegal port access, it should be possible to fully isolate the code. Right?
Of course, the performance would be inferior because of the context switching between different privelege levels. But in a "safe" mode, this would be a fantastic way to run plugins for PDFs, Flash, a whole game, or some downloadable application.
I'm not a kernel expert, but I thought that mainframes could do this forever. What about Linux? e.g. with Wine?
BTW, this would also make peer-to-peer style distributed computation (like the SETI project) safe and still fast.
As I have said. Most programs that have these overruns are locally installed trusted applications...(outlook express, ICQ...) "safe" has nothing to do with security. "safe" is simply a programming paradigm like "strict", it does not have anything to do with security, maybe reliability, but not security.
As others have said time and time again, it's about the developer who is writing the code. Sure it's FUD, but everyone is throwing it in every direction. The only thing half way useful from the article is about each company's approach to development, which doesn't necessarily validate their products. It's good people are thinking critically about the article and poking holes in Bill Joy's article. The only problem with providing the power and benefit of unsafe code is, when some uses it inappropriately or incorrectly, it creates headaches for everyone in the project. No news there. Good developers will spend appropriate time to learn the tool and use it "correctly." Here's to the hope C# will not only be developer candy, but that it will promote good coding practices.
What kind of syntatical gobbeldy-gook is this!?!
.EXE header that states "the unsafe flag was set in the code, so don't run it if you don't run "unsafe" code...
If I put the keyword UNSAFE in front of any line of code, C# generates a flag (similar to CONST in C/C++), that sends the keyword all the way down to the code emitter which sets a flag in the
There's NOTHING, NADA, ZIP in this system that makes the code in this program "safe". All you're REALLY saying is "MICROSOFT WARRANTS THAT THIS CODE HAS NO POINTERS! (TM)"
That's what Joy is saying... When Microsoft has to state in their documentation "The keyword UNSAFE, marks code that is UNSAFE to run, because the code being run would be UNSAFE when it is run. This actually makes the code SAFE." There's something VERY WRONG here...
Stop buying the Orwellian newspeak... THE EMPEROR HAS NO CLOTHES!
What a bunch of pouty little children. No one can stand an open and honest dialogue about Linux so the cowards resort to modding down 66% of the posts to this thread. Truly pathetic.
Has anyone actually created programs of any substance using this hybrid language? Arguing about theory is one thing (and worthwhile). In reality, lets compare these languages. C was written 30 years ago. Its fast, and can do low level stuff. The low level stuff can be dangerous. If not properly utilized and managed, it can translate into major headaches. C++ brings in object oriented programming, but still a program is only as good as the programmer writing it. With the capabilities that C/c++ has, that can be dangerous. I hate having to debug memory stuff in c/c++!
Java on the other hand is purely object oriented. You dont have to do any low level stuff because its already taken care of!
You can code more effectively. Java has been around since 1995 and is a major language. My school just changed from teaching C++ to teaching Java. -- DePaul University CTI
This new language is a hybrid of java and c. It has been out how long? Has anyone written any useful programs on it? Windows executables? Anything that attempts to be mission critical?
Computers are getting faster and faster and Sun will make java better. Maybe java will be as fast as c++ one day
Since you don't want to write such code inadvertently, C# requires you to use the unsafe keyword on your class or method whenever you write code that deals with pointers. When you use the unsafe keyword, the resulting IL is marked as unsafe and can only run in a fully trusted environment (usually, security policy only trusts local assemblies). In the current version of the runtime, unsafe is defined at an assembly level, so having any unsafe code in assembly makes the entire assembly unsafe.
Well, in case writing unsafe code becomes a frequent practice among C# programmers, this means that in order to run most of the code, you need to set the security policy to trust most of the C# code. Now, I don't know much about C# and CLR, but I assume the when your code uses libraries with unsafe code, then your code ALSO becomes unsafe. Just imagine that one very common library to use unsafe code; then the unsafe code itself will spread like a virus. And this doesn't look good.
There's also (in theory) a special security privilege to run "potentially harmful" ActiveX scripts or Outlook macros; yet they seem to slip through on a regular basis. I have little faith in Microsoft's ability to successfully implement a decent security model, based on their track history alone.
I think we can all agree that if there was any attempt to secure IE and Outlook from threats, it was either ignored or done half-assed.
Just to be careful, I wouldn't compare a half-assed attempt at security to thier upcoming crusade (last crusade it was the Internet).
I'd place a bet that there are ways around C# security.
We'll have to wait and see. From what I understand, MS hasn't implemented a sandbox for executing applet like applications. When they do, I'm pretty sure it will be as restrictive and secure as the JVM (obviously pointer manipulation wouldn't be allowed). Why wouldn't they? It's not like they don't have experience making virtual machines.
Furthermore, using code that handles memory directly is a lousy way to implement platform independent software; why do you think there are so many little-to-big-to-little endian conversion functions in C?
It's not for building cross-platform code. It's for developing system code when you need to write system code.
"Communism is like having one [local] phone company " - Lenny Bruce
wasn't Bill Joy the cheif architect of that little computer language we are all talking about, Java?
It still provides pointer manipulation (which is damn handy) but AFAIK it kills the app if you try to access outside of its memory space. So, is it safe? What about if you mix in C functions? I'm wondering as it seems to be a good blend of OOP but without the kid gloves of Java.
whose afraid the world is going to be taken over by giant genetically engineered killer robots or something? Probably afraid the AI will be written in C#.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
Notice that Joy's article starts off sounding very technical, but never quite gets to any specific technical flaw in .Net. He just implies that it probably has a lot, without offering a single example, based on historical complaints about the company.
If you think the "untrusted code" part was a (single) example, note that he doesn't actually point out any specific flaw.
Java itself allows a program to delete user's entire hard drive, or write the binary op codes for a virus into a file and label it "readmeNOW.exe", if that user chooses to run the program as a standalone app. So Java has the concept of trusted and untrusted, too.
If Joy wants to convince a technical audience that C# is dangerously insecure, you'd think he could come up with an example.
Otherwise, it's nothing more than a fluff "I just don't like Microsoft, the company" piece.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Some tasks simply need low-level features. If you want to use a high-level language most of the time, you have got several choices: You can write the low-level parts in a different, low-level language, you can try to outgess the compiler vendor and write source code which compiles to the required machine code using a specific compiler version (in many cases, this is the C approach), or you can use a high-level language which supports low-level programming. The third choice does not have to be the worst, especially if the low-level language features are clearly separated from the high-level ones (C fails miserably in this area).
Remember that many mission-critical computer systems are implemented in Ada, which offers a wide range of very low-level features (interrupt handling, representation clauses, unchecked conversion of objects, and so on). Unlike C, there is also explicit support for machine addresses and address arithmetic.
However, you should keep in mind that only certain types of security problems can be avoided automatically by choosing an appropriate programming language. Buffer overflow and format string bugs are found in almost all C software, but they are not the only cause of problems.
Oh, by the way, there are pointers in VB. Not officially, and it's an "unsupported" hack, but there are.
;)
And VB.NET makes them official.
I don't get it. Anyone who has done any serious development for embedded systems has to see how utterly ridiculous this article is.
[FromTheMorning]
You've been taken in by the anit MS FUD.
Here is the most recent definition from MSDN:
"A set of technologies that enables software
components to interact with one another in a
networked environment, regardless of the language
in which they were created. ActiveX(TM) is built on
the Component Object Model (COM). "
Quite a step from "automatically downloading and
executing arbitrary programs" don't you think?
More specifically:
"An ActiveX control is essentially a simple OLE
object that supports the IUnknown interface. It
usually supports many more interfaces in order to
offer functionality, but all additional
interfaces can be viewed as optional and, as
such, a container should not rely on any
additional interfaces being supported. "
Anonymous posts are filtered.
Alas, I doubt anyone will be reading this, but I'll say it anyway:
Java's security model always felt tacked on to me, but even still, it's pretty decent for the kinds of security issues it was meant to deal with. The problem is that Java can still be used to create viruses and other nasty problems, especially if it can sweet talk to user into giving the Java code more permissions than it would otherwise have. The same thing is true of ActiveX: all the security in the world won't protect you from a user who cranks the security in his IE down a few notches. The reason users would do this is to get access to a control or java app that can do something interesting or useful. For example, a virus scan of your harddrive.
This leads me to a basic observation: the usefulness and capabilities of a language or programming environment is directly proportional to the amount of damage it can inflict on a system. Both languages and environments have their benefits and drawbacks, but deciding based on security is pointless: security is fundamentally a user-developer level issue. No amount of language-level or environment-level features can make computing secure if the user and developer aren't willing to think securely as well. If you do add more secure language and environment security measures, then the usefuleness of your language/environment decreases (e.g., to protect your local hard-drived files from unwanted operations, you lose the ability to save/read anywhere on your harddrive from your application). You cannot have a useful programming language/environment and still make guaranteed secure programs.
C#'s unsafe section problems are not security problems, but robustness problems. The unsafe sections make it very easy to create code as crashable and bug ridden as a pure C/C++ app! Java's constraints don't make it more secure than C#, but they do make it easier to write robust code.
Even with the unsafe sections, you can still write really high quality C# code because no language/environment feature can ever replace the programmer's diligence in writing secure code. And if you want code that's less bug-ridden and more robust, avoid unsafe code sections like the plague.
My greatest qualm with C#'s unsafe section is knowing that a bunch of programmers raised on MS's crappy coding style will create components and other applications with great reams of unsafe code forcing everyone using .NET to drop their security precautions in order to get basic applications running thus creating the backdoor every script kiddie is waiting for.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
Great troll...really fooled the moderators...oh...you dont know its a troll?
look at the obvious! first, he admits to not being an authority, making himself look humble, then he continues on to talk about how his opinion is right
He even goes off on ridiculous tangents to what he was talking about in every paragraphs!
Did you people even read what he was saying?!
Jesus christ, how does slashdot consistently pick idiots as moderators
I don't have the technical details on this. .EXE header indicating the code is unsafe. Is the resulting executable also encoded and signed including the flag state. Toggleing the "unsafe" flag in the header would otherwise be a trivial exercise. Please someone tell me there is some protection on the "unsafe" flag.
From other comments, using pointers causes a flag to be set which appears in the
Actually, Fujitsu COBOL is part of the
I'm a 2000 man.
What it *should* be about is security. Code which uses pointers and other potenitlaly indirection and derefrencing constructs should never come from anonymously the network, but should only put on the system by the user or administrator as a concious act. Period. Native Java is just as potentialy harmful as C# UNSAFE code. The real discussion here should be on the security of the Dot-Net environment. How secure is the run-time security? The Java solution, to allow noneperiod, is safest but limits the power of the language for native uses. Java is very frustrating if used as a general purpose language. SO in that repsect C# has potential. It is incumbent upon Microsoft to prove that in allowing indirection in C# they did not weaken security on Dot-Net. The burden of proof is on Microsoft--not C#. Given Microsoft's track record, I suspect it leaks like a sieve. But that is a suspicion. Let's hear from Microsoft and let some hackers have at it.
What a wonderful combination!
-- Alastair
Pointers don't kill people, bad programmers kill people.
Buy a clue Joy pointers are good. If pointerless Java is such a swiss army knife for programming rewrite Solaris in it. Oh dam there goes memory management. Solaris is mainly C isn't it Bill.
Has it occured to anyone that C# and .NET are not Java? That they aren't really even targeted at the same audiences.
The comments here seem to be of the ilk: I've never needed it, therefore nobody needs it.
There is a good reason why C# includes unsafe code. With Java, if you want to write a client side piece of software that actually can manipulate bits, memory, and buffers, you are just SOL. You just CAN'T do it.
But I don't need to do that, the whiner's whine. Why should anyone ever want to do that? Blah blah.
Well, I DO need to do exactly that regularly, and I don't feel like writing a nasty huge ass complex C++/C JINI POS for the rest of my application just because in three functions I need a little high performance buffer and bit twidling.
As for being secure, who claimed that ever piece of software was run off of a web page or off the internet. Remember client software? Those strange pieces of code that users actually intall on their computers? Yeah, that 99% of all software written (in C and C++). Why do you think that client side application are written in C and C++ and NOT in Java. If you guessed the training wheel limitations that Java imposes on low level coding, you guessed right.
90% of all of the security and stability issues in the average C/C++ program doesn't come from the low five or six low level bit twidling functions anyway. It comes from the universal use of pointers, pointer arithmetic, and lack of decent exception handling and memory management in the other functions in an application.
So in short, for average run of the mill client side apps, the ones that real people actually install and use on their desktops (which is Microsoft's world) you can get the performance of the low level bit twidling direct buffer access pointer arithmetic and have the rest of your app in a nice safe sandbox.
And what exactly is so wrong with that?
I've seen a couple of unbought books in the bookstore ( think about the sentance for a bit ) but other than that I haven't seen that much re: C#.
Is anybody actually using it other than MS? If so, what are the particular reasons for choosing it over C,C++, or Java or something else?
I'm actually curious - I don't understand the need for C# - Java is sufficient for platform indepandance - C# is currently just for MS-OS's, so C++ or whatever binary for your target OS would be equivlent.
There's a gorilla from Manilla whose a fella that stinks of vanilla and has salmonella.
Just to be *really* anal, the two are enharmonically equivalent only when tuning with equal temperament. However, if you use alternate tunings (such as tuning to perfect 5ths for a particular key, "just tuning," or using another Baroque tuning), there is a very audible difference between Cb and B, E# and F, etc.
I don't have a
I suspect that Bill Joy's article is not totally objective here. I was almost expecting the word "Advertisement below" to flash above this article.
.NET and C#.
See, the problem is that MS may have the killer Java technology here on the server side, and Sun smells it. So expect to hear more from people at Sun bashing hard on
What's Bill's point anyway? Ok, he knows stuff as he wrote vi and csh both in C, so he probably got into pointer trouble while writing his code. But, I am not sure about what he claims here. Is he asking MS to add the keyword "unsafe" into the C# language and is he bitching because MS already moved to the ECMA?
At least MS had the decency to move their language to a standard body right away, instead of tip toeing for about 2 years like Sun did with Java. And Sun still controls Java BTW.
Visibly, the guy with the gray goo on top of his head is running of fuel. It shows.
PPA, the girl next door.
-- I feel better now. Thanks for asking.
I've been reading a lot of comments about the IL code having some sort of flag mechanism indicating unsafe portions.
.exe header?
My question is this: since the end-user JIT executes IL, what stops someone from editing the IL so that it becomes 'unflagged' as unsafe and tricks the end-user into thinking it is a safe portion? Are there a group of unsafe instructions? Is the IL obfuscated in some way? Or is it just as simple as an 'unsafe=1' in the
I think many of our concerns about unsafe code could be answered by knowing these details. Could someone with the technical knowledge step forward?
----- rL
Once the nanobots take over the world, no-one's going to care about C#.
C4L, don't you see that you are fighting a losing battle? Ignorance such as the_skywise is useless to fight.
First: yes, it is possible to set the boundries where code is more and less safe. Scripting languages do that just as Java does. However, this stuff by Bill Joy is just nonsense. Yes, my "Hello World" application is more trusted in Java than C++ potentially. But Java doesn't run on Java, its runs in a native code implementation of a runner. From what I know there is no government agency ensuring that the JVM is absolutely secure (and even if they did - these people promised NT was too.)
Every single time you install most any application on most any system the code is unsafe to some degree. The issue is do you trust the vendor? Do you test deployments? And how do you get the code (just downloading from annonymous people is plain silly if security is your primary concern.)
Write the application in the language that does the job. If you are worried you have bad QC and are a bad developer, then maybe writing in Java will make you less worried about breaking someone else's OS. Hardly a ringing endorsement for Java or a horrible criticism for C#. All C# does is balance the security, independance, and similarity to C++ a bit differently than Java. Its not rocket science. Its like the owners of a 4 door and a 2 door Camry saying how horrible the other's car is - damn they are similar and the differences are a matter of taste, not absolutes.
Tim T.
Unsafe code = Unmanaged code =
allows pointers, direct allocation of memory, and you have to keep track of your own garbage collection
Insecure Code =
loginfunc(username,password)
{
return 1;
}
1. This may be obvious... but I would say that anyone can build an insecure program with any language.
2. I've used C#, it's in the programmer's interest to *not* use unmanaged code both time wise, and in many cases speed wise (the conversion of managed data types to unmanaged data types and back, is expensive.)
3. If we're concerned about unmanaged code, we should really be bitching about the latest version of C++ which (gasp) allows unmanaged code.
essentially this whole argument is moot. it's easier to use managed code, the performance cost is negligible, and poorly writen managed code is a far more likely threat than well written unmanaged code.
just my $.02
-george
No. You've completely missed my point.
Putting the word UNSAFE in front of a pointer declaration does not make the code dangerous. Likewise, having no UNSAFE declarations does not make the code safe (in this case, safe from exploits).
But by merely accepting the terminology, you're already separating the code modules in your mind as "safe" and "unsafe".
But then you probably think filtered cigarettes are perfectly fine...
I have never seen Microsoft have so many of their cronies posting to a Slashdot article before.
Look at all the Hotmail addresses!!!
Yes, ActiveX does a lot more than jump from a server into your browser and spin. Not often from my experience, but it is possible ;-)
.NET is to get the new portions of your program, as well as your new programs, over the network. It serves the data from a server (remote host) to your client (your desktop, etc). A file is transferred, from server to desktop. By definition, downloaded.
.NET is using the same basic framework. Maybe if they add some extra interfaces for what falls into each zone we'll have a start of an improvement.
You could, say, write an image editor or an archive utility as an ActiveX control and use the COM handling techniques to control the data regardles if it is on the desktop, in an office document, or on a remote server. I've got to admint, this sounds like a pretty cool idea.
But, back to practical usage - part of ActiveX in the confines of
Furthermore, this seems to be supported by your citation - "enhancements specifically designed to facilitate distribution of components over high-latency networks and to provide integration of controls into Web browsers" sounds like it confirms Bill Joy's side to me, even if he glossed over some other neat tricks in the MS bag.
Now, as far as security goes, I admit that I've never been fond of the way that IE handles its zones and it looks like
I'm also not very fond of this 'no sandbox' concept. We've already had a faked signature intercepted, and with the ActiveX debut there was that protest/demonstration page which would, without prompting, shut down your system via ActiveX controls. So far MS has not done anything to set my security expectatinos better than they left them.
Rule #1, people are stupid. There are no exceptions.
Despite its flaws it is much better than anything MicroSoft has had before from a developer's viewpoint. It makes it easy to write money-making apps on the worlds large operating system.
Obviously the real enemy of modern-day computing is bugs, not security exploits and viruses. I think we all suffer many times more (in terms of productivity loss) from program flaws and crashes than we do from system break-ins. Obviously this ratio varies a great deal from user to user, but overall I think bugs are a problem orders of magnitude greater than what we normally call "security".
I don't know anything about C#, but I do know that Java traps things like array overwrites at runtime. These are very common programming errors in C which can often take months to track down. So not only does Java's "security" in terms of pointer handling and bounds checking protect your system from exploits, it also protects you from programs gone haywire. And it helps programmers to debug their own code as well.
All the same logic about not running applications as root apples here as well. You do it more to protect the system from yourself than from others. I read the article as accusing C# of not providing the kid gloves that other modern languages do. Of course, bantering about "security" seems to attract a lot more attention than the more compelling arguments of "prevents you from screwing up your own system!" We have more fascination with security than we do with common sense.
The whole idea of "unsafe code" is a myth. Only operating systems can be unsafe.
Linux and NT have always allowed even the lowliest user to create a file with any arbitrary code in it, give it executable privileges, and run it without endangering other users. This is exactly the right model for code downloaded off the web. It should be run in a separate VM as user "foreign_code_from_sitename.com", and that user's privileges should be restricted in just the way that a Java app's privileges are restricted.
There are only two reasons this hasn't happened:
The first problem will eventually go away on its own. The second problem can, and should, be fixed by extending the user privilege concept at the operating system level.
Instead, the designers of Java basically reimplemented the protected VM concept at the application level. Given that they didn't control most users' hardware or OS, this was probably the best they could do -- but it was nothing more than a gross hack, and it should be treated as such. What really bothers me about it is that they don't seem to have noticed that they were reinventing the wheel, and instead have tried to present the concept of secure executable code as though it were a radical new idea.
Using a "safe" (i.e. type-safe) language can still be a good idea, when protection against a large class of hard-to-find bugs is more important than run-time performance. And using interpreted bytecode (aka P-code) is often a good way to make your software portable. But those are matters of reliability and portability, not security, and they can and should be left up to each individual software architect. When you're running on a machine which has very fast security support in hardware, any platform which has no way to safely run arbitrary unsigned machine code is pathetically broken. And that seems to be true of both Java and .NET.
Yep, Joy got all his points right. Everything he is saying about MS technology in general and C# is absolutely correct, i would sign the paper, if not for a couple of missing pages.... .NET framework is certainly not at all blind ...
Sun delivered a great technology to solve some problems - Java and all it's semi standardized frameworks... but is that the whole story? We are dealing with a problem space, which cannot be broken down to just one paradigm. Now that's Sun's blind spot, with it's Java "für alles" paradigm, which simply does'nt scale. Some things are done better with C, perl, ruby, C++, C# or cobol or whatever etc. etc. for various very valid reasons. In this area the
Probably Bill Joy knows this quite well, but prefers to elaborate only on the albeit important security aspects, which are'nt even in all given circumstance relevant.....How can such a great researcher, inventor and developer lend his hand in such a obvious way to his marketing department???
Furthermore, C# isn't even going after the same market as Java. Java's security model primarily comes into play for applets and mobile code, but that's only a tiny fraction of all applications. C#'s purpose in life is to allow programmers to create desktop and server applications more easily. For that purpose, an easy and robust interface to native code (regular expression libraries, XML parsers, etc.) is much more important than security.
The major problem with C# isn't technical, the major problem is that there aren't any good implementations available yet (no, Microsoft's implementation isn't all that great yet) and that C# comes from Microsoft. But once there are C# implementations that are competitive with Java implementations and once C# has a life outside Microsoft, C# will be a serious threat to Java. And we may see a truly open source, efficient implementation of C# before we see one for Java.
For the time being, I still think Java is the more logical choice for open source applications. It may yet be a few years before competitive C# implementations and libraries come along. Sun still can keep their lead by innovating and extending the Java platform, cooperating with the open source community, and being honest about the strengths and limitations of the Java platform. But if Sun continues along their current course, they will lose sooner or later.
If I never read this stupid ass joke again, it'll be too soon.
Please try to grow a brain.
-
Patsy Ramsey
And code "In C".
My exception safety is -fno-exceptions.
Java is safe because it is interpreted. Sure, it is compiled, but the compiled code doesn't run on hardware.
.NET code is interpreted, then they can make it safe. If they have a silly marker saying "This code is safe because it doesn't operate on memory directly", then that is just silly because some hacker can easily remove this marker.
If
Running code downloaded from the network, directly on your hardware, will always be somewhat dangerous. Of course that is what operating systems are for. However, there is always some way to figure out how to run malicious code in a privileged fashion.
you know, the language he wrote the code for the C shell and vi in, whilst a grad student at Berzerkley on a grant from...Big Blue.
XML = flat file database
C# = java
Word = wordperfect
excel = 123
Access = Dbase/Foxpro/Rbase
.NET = XML + RPC = flat files + unix's ability to do things easily.
Microsoft reinventing the world so we can make money, lots of it.
Bill Joy was the major hacker involved with early BSD. I think he's somewhat of a hypocrite saying this, seeing as he was the one that say, wrote an API that arbitrarily casts a struct sockaddr_in * to a struct sockaddr *, etc...
Don't you get it? "...and so forth".
Forth, you know?
On second thought, if you haven't heard of
Bill Joy before...
I mean, he's Bill Joy. If he can't knock out a safety-checker for C# units in a couple of weeks, then he's not the Bill Joy we grew up with.
--Blair
There seems to be a load of discussion on the actual functionalities and implementations of C#/.NET so far. But I think we should all take a step back and look at how MS approached the whole process of designing a supposedly platform-independent, net-oriented runtime system + language.
I think we all agree that being the language of the NET, security is of priority #1, way ahead of functionality and flexibility. However, to design any kind of secure system, it is essential that you make the strictest system, and only then relax the security restrictions to allow more functionality. But it looks like MS wanted C# to do everything, and then add security as an afterthought. It is dangerous to achieve security by incrementally restricting the system.
I like Java. I'd just like to point out that even in Java you have safe and unsafe runtime environments.
I could easily write a Java app that would write binary op codes for a virus directly into some of your favorite application executables. The sandbox runtime wouldn't execute you it, but the standalone runtime would if you told it to.
Bill Joy claims that there is a form of coding called "unsafe" in C# and expects you to draw the conclusion that C# is dangerous to use. Pretty pathetic argument for someone with his technical background.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Writing safe code is the developer's responsibility. The language has nothing to do with it. If you wanna write in C and also check for buffer overflows, you're gonna have to do it yourself. Otherwise, pick a new language.
-- Slashdot: When Public Access TV Says "No"
I really hope that Microsoft simply makes it impossible to run "Unsafe" CLR code in the browser. Not even an option.
No, that's not necessarily what we want, at least in the long run. It's more limiting than necessary for many purposes.
.Net has a security model that lets you configure your runtime to allow various levels of access depending on digital signature. If I'm the family computer guru, I might set up my parents' computers and my sister's computer to run -- with full access -- anything stamped with my digital signature. I would do that locally on their machines during a holiday visit.
After setting the security admin rules locally on their machines, I can thereafter deploy full-power software that I write to their (and my own!) browsers.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
I don't write programs for Macs or Unix. I use C++ and all of windows advanced features. I don't care if it's unsafe. It allows me to create programs no one has done before. If I were using Java with no hard disk access my programs would probably look more at home on a Commodore 64. I prefer the power to get at the computer OS and hardware and let my Norton products worry about security issues.
So Microsoft built ActiveX, a technique within Windows for automatically downloading and executing arbitrary programs.
.NET Framework. C# is managed by the same security as VB.NET/JScript.NET.
.NET could actually be quite secure. Its what ActiveX always should have been - managed.
Er, with a security prompt. A crap security prompt, yes, but a security prompt.
Netscape's JavaScript was designed to prevent this through its "Same Origin" security policy, but Internet Explorer's JScript technology, which nominally supports the same scripting language, fails to implement the Same Origin policy.
IE does implement domain security. There have been quite a few bugs in this, yes (and one major one not patched) - but this isn't a problem with JScript, just with IE.
But C# tries to encompass all the power of C as well as features borrowed from Java. And security cannot be added to an otherwise insecure language.
But it isn't C# that provides the security - its the
So far there have been very few and quite minor holes found in the betas of the framework, and (to my knowledge) none in the final.
If that trend continues, I think
They aren't referring to assembly language there, if that is what you are getting at.
DCMonkey
Show me an environment that provides all of this and I will switch in a second. I am not even showing the J2EE stuff.
It's a good question. .Net has several categories of pointer. Some are there to allow you to use efficient indirection as a programming paradigm without simultaneously exposing the underlying memory system of the machine. The two do *not* have to go together.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
No, it is safe because it is verifiable. What that means is a formal proof that the code doesn't violate various constraints (such as accessing memory that it shouldn't - which usually requires some level of type safety, checking arguments to function calls, etc). Once you have that level of "safety", you can then add in security models (e.g., inhibit "unlink" calls) and be sure that the code isn't going to subvert that model (such as roaming a pointer through memory looking for the permissions your code is allowed, and changing it to give yourself more permission once you find it).
It's just a side-effect that the specific byte-codes are designed to be verifiable, where machine code is generally not (and should not - at the implementation level, you eventually have to get down and dirty, and where attempting to be "safe" would be much too slow). Once it's been verified, it can be turned into native code and it remains just as safe.
I think Microsoft is just confusing the issue by calling it "safe" and "unsafe". It should be a matrix of "verifiable" vs. "unverifiable" and "trusted" vs. "untrusted". Code marked as "safe", but which fails the verification proof, should never be run, regardless of any code-signing levels of trust. Other than that, there isn't really any reason to mark code either way, except to avoid the overhead of trying to start checking unverifiable code when you know it is going to fail. It sounds like the "unsafe" attribute is mostly just a way to mark the source code so that a programmer doesn't inadvertently use unverifiable techniques.
Hmmmm. A lot like IIS. Or Outlook. Or IE.
But will it have spyware like M$ instant messaging?
Then that's good enough for me!
oh, great. first it's that vi versus emacs thing, now this.
That's the sound of the sarcasm plane darting swiftly over your head, safely unseen. If you look up quickly you might be able to spot the vapor trail.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Actually, by design .NET "shifts the burden from having to make critical security decisions--such as whether or not to run a particular application or what resources that application should be able to access--from end users to developers and administrators." This is an excerpt from a thorough security evaluation performed by Foundstone. The report can be found here.
Read a java spec bud. 'Like a cast in Java, declaring code as "unsafe" is equivalent to saying to the VM, "Hey, I know what I'm doing."' Huh? Java downcasts do not compromise the security of the VM.
Java's code does run on hardware.
The Java compiler compiles it to byte code. Then at run-time the JIT (just-in-time compiler) available on many Java platforms compiles the byte code to native code.
C# does the same thing. It compiles to a byte code called MSIL, and then at run-time it gets JITed to native code. And, just like Java, a C# app that you run from the web gets run in a sandbox to protect the user from malicious code.
Donate background CPU time to fight cancer.
Java has had for quite a while the ability to call C code, external DLL's, or whatever - JNI, the Java Native Interface. In fact it's also defined how external code (well, C and C++) can call into Java as well and launch a JVM from inside a native program. I've used it myself and it works just fine.
Apart from that, I can't really think of any features the CLR or C# language has that Java is missing. What you could possibly say is missing are tools like MS provides - though Java does have many amazing tools like TogetherJ, JBuilder, Netbeans, and others. Still if for sme reason you bought into the cross-language idea (in my mind a total farce but I can see where people would find it appealing on the surface) the JVM does support many languages but there's really no tool that brings them all together at the moment.
I agree with you on the web services aspect.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What I like a lot about about the applet model is not just that it keeps things in the sandbox, it's how fine grained your control is over what the sadbox really is.
An applet can do anything up to altering parts of your OS if you give it the scope. It can also be given just the barest permissions it needs, such as the ability to read and write to one directory on your computer and no other.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
...but it's really bugging me! How the heck do I pronounce this language? Is it just, "See Pound" or what? Thanks, and don't flame the n00b!
"To confine our attention to terrestrial matters would be to limit the human spirit." -Stephen Hawking
So does vi.
I'd like to refer to a function in ANSI C, which C# came from:
... if someone enters too much data, it overflows.
.. Increased focus on OS security can't be a bad thing.
char* gets(char *strPtr)
Notice any limit specification in that? No.
Compile with gcc, and you get an error "gets is dangerous and should never be used"
Since one of the greatest advantages of C (over say, VB) is the ability to USE pointers and memory addresses, and thus to CREATE potentially 'unsafe' code, is it *REALLY* a suprise MS left it in? Furthermore, is it a BAD THING that you can?
It's about F*CKIN' time MS brought out their own (if you could call it that) programming language that was a little more difficult than "dialoguebox.text = mytext". If developers are going to write applications with buffer overflows, LET THEM. It might teach managers the difference between VB SCRIPT KIDDIEZ ($10 an hour) and WINDOWS PROGRAMMERS ($80 an hour).
Furthermore, All current operating systems (NT or *nix kernel) are _protected mode_. Applications with buffer overflows can only hurt themselves. (with some exceptions in superuser code)
He should have checked out the MSDN docs. He should also have read some security studies or even done his own. Perhaps then he would have realized that the security of the CLR has nothing to do with an arbitrary bit set to mark a block of code as "safe", but rather to do with a type-safety verifier that is completely independent of the compiler and language used to generate the code in question.
C# is not tied to the CLR like Java is tied to the JVM. The CLR (Common Language Runtime) is designed to run IL code, and there are compilers for many different languages besides just C# that can generate IL. That said, it should be clear that the security of a C# program is not derived from the C# compiler. It comes from the CLR, so the security policy is enforced at the IL level, not prior to compilation. (It would be laughable if the security of the CLR was enforced only by the C# compiler rejecting "unsafe" code. I'd just write my own C# compiler that allowed it, or I'd whip out my IL assembler.)
The "unsafe" marking of code occurs only at the source code level. Whether or not code is considered type-safe by the CLR is not determined by an arbitrary flag set by the developer; it's a function of the IL code itself. It needs to be that way, otherwise programs compiled with my evil compiler for my own non-type-safe language would slip through the cracks. Note that even if my IL code is actually type-safe, if the CLR's type-safety verifier can't prove it, it won't be considered type-safe.
That being said, "unsafe" is just a compiler feature. Perhaps Bill Joy would have had nothing to say if Microsoft had decided to use a keyword other than "unsafe", like maybe "dont_generate_an_error_at_compile_time_if_the_cod e_inside_this_block_fails_the_type_safety_check_ev en_though_it_is_going_to_fail_when_the_CLR_tries_t o_run_it_in_a_context_that_requires_type_safety". (Actually you can achieve this if you don't mind adding a #define to your C# source and then running it through a C preprocessor first.)
But why take my word for it? Check out an interesting study into C# and the CLR's security done by some students at Rice University at http://www.owlnet.rice.edu/~jsinger/comp527/propos al.html. They have a lot of detail there about tests they ran, as well as a good paper summing up their results.
D
It's funny that everyone here is saying Sun is spewing FUD and joking about Slashdot being rigidly anti-MS. As far as I can see, almost everyone here is rigidly pro-Microsoft and eager to heap abuse on Java and praise on Brave Microsoft for making the "Genius" C# and .NET.
.NET is going to be asking your permission all the time. Let me tell you, I just spent the day with a secretary in a law office who was just wrapping her head around loading and saving documents. If her web browser asks her whether or not she "trusts" someone's code, she's going to just click a button at random no matter how many times I try to explain what to do.
.NET, without having ironclad and unequivocal guarantees - as Java can give you - you're setting yourself up to have another MS security disaster.
There's a tremendous amount of well-rated lies here about the article itself. It's really astounding in its volume - ranting on for pages about how Bill Joy is jealous, and C#'s pointers are totally safe, and Sun is making up lies about C#... "Insightful"! It's like some kind of geek guilt or something - we have to be hard on ourselves, and have a backlash against our backlash now?
I prefer to actually look at the objective truth on a given day. What's the article about? Joy is saying that C# doesn't force you to be safe. It lets you choose. And the problem is that if you let people choose to be unsafe, then they sometimes will be unsafe, because it's easier, or faster, or because they don't know any better.
Despite rampant misquoting here to the contrary, Joy wrote explicitly that he knows pointer-massaging code is marked "unsafe" in C#, and is recognized and treated differently by the CLR. It's right there in the article.
The point is that it just brings us back to square one security-wise - to ActiveX. Break out your digital signatures. Do you trust this code? Yes or no. If you want to run it, you better. Some of it might be "unsafe." Once you start flinging pointer arithmetic around, you can stand up and piss right over the sandbox wall.
So many choices. So much freedom.
Joy's point is that in the context of network computing, certain kinds of flexibility are dangerous and ultimately destructive.
I can just see all these rah-rah-C# people making the same kind of arguments I'm hearing about pointers for being able to do powerful word macros and having IE rendering emails. It's so powerful! "Just don't open any word documents from people you don't trust!" they say. Heh.
What we've learned is that we can't dump this security dillemma on the world under the guise of "choice." We've made that mistake (MS certainly has) over and over again, and the result is the same every time. For something like
We're on the road to Tycho.
I dunno, but Royal Dutch (Shell), one of the biggest oil companies in the world, uses Win2k worldwide in their wan (more than 70.000 machines), server, desktops, you name it.
Nasdaq also uses win2k based solutions.
Anyway, my NT server has now an uptime of 127 days and counting. Where are the reboots? I dunno, perhaps you don't know what you're doing, and considering your humourous remark about access I'm pretty sure you really don't have a clue.
Never underestimate the relief of true separation of Religion and State.
The major problem with C# isn't technical, the major problem is that there aren't any good implementations available yet (no, Microsoft's implementation isn't all that great yet) and that C# comes from Microsoft.
Big words, and I don't see any proof of it. In what way is the C# implementation of MS bad? (and others thus good?) Seems like you're recylcing a lot of hot air without adding anything useful to the conversation.
Never underestimate the relief of true separation of Religion and State.
That's a nice Microsoft marketing document. And Foundstone sounds like a completely unbiased 3rd party.
The part you'll want to read in that document is the part about "unmanaged" code. Funny how short that section is, isn't it!
I think we've found ourselves a Microsoft troll...here are some examples
Time for M$ to be on the recieving end of a little more FUD. B.J. has obvously been studying they're tactics.
Gee, co-founder and chief scientist of Sun Microsystems thinks that C# and .NET are bad?
Man... I never woulda thunk it.
Too bad this is mindless progaganda not directed at informing people, but at encouraging people to stick with their assumptions and not even try a competing product to Sun's.
His comments about "unsafe" code show his ignorance. The CLR applies the SAME rules to unsafe code as it does to safe code, it simply doesn't do the memory mangagment that it does with safe code.
In other words, it's a lot easier to crash your application with unsafe code. But that's about it.
err... no they didn't!
C# is supposed to be "C++++". Get it? Arrange the +'s in a certain way.
It turned out that when MS saw Unix and Linux as a threat, and when they decided that reliability was one of the biggest advantages that Unix/Linux offered, they took reliability seriously and made enormous progress in a relatively short period of time.
No, not so short. Sure, it's short in the sense that Win2K and XP were reliable while Win9x/ME were not, but it's not short in that 2K and XP were directly derived from more than a decade of previous work on NT, and it in a less direct manner from significant previous work on VMS and Prism. As much as people harped on the unreliability of NT, even 3.1 was a vast improvement over all previous Microsoft operating systems. That was, however, the work of quite a few years. Security will be, too, particularly since they still have the albatross of backwards compatibility to deal with.
The shift in priorities, however, can't be anything but good in the long term.
jim frost
jimf@frostbytes.com
This is not easy to do with random machine code (although several commercial products have existed for close to a decade that did a passable job on typical code, eg Purify and TestCenter) but with an intermediate representation that was specifically designed to make it easy, such as Java bytecodes, it's not difficult at all.
And, more to the point, it can be done with much less drastic performance penalties than we see with interpreters. To see this in action simply compare the performance of interpreted Java to JIT-compiled Java. Moreover, if you're willing to pay a heavier compilation cost than is reasonable with a JIT, the performance penalty will be merely incremental.
jim frost
jimf@frostbytes.com
Pointers are good. Sure, they're dangerous, but sometimes they are the only way out when you are trapped deep in some horribly designed legacy code.
The Moore-Murphy Law: The number of things that will go wrong will double every 2 years.
Only baby programmers and script kiddies and VB wienies are afraid to handle pointers.
You've evidently never programmed anything of any size, a notion that is backed up by a quote on your webpage: "We're studying for our Masters Degrees in Computer Science at NSU and hopefully we'll be finished on June 20, 2002."
When you get out into the Big Bad World Of Real Employment(tm) you'll find that those cute little pointers that you're so fond of in your toy CS101 code have grown up into big, badly behaved monsters that will bite you at any opportunity.
If you're doing a project of any complexity, keeping track of all your data pointers becomes a non trivial problem - more so when you start working with several other people on the same codebase. What is the lifetime of an object? whose responsibility is it to see that that object is destroyed? How do these rules change under faliure conditions? How do you ensure that all the rules you've put down are obeyed?
Jeez, why do you think Smart Pointers have become increasingly popular?
Some time ago, when Java was the fresh darling of the IT world, I was offered a job in a company doing just that: a virtual machine to run legacy COBOL programs in any modern platform.
They seemed quite stressed, thus I gave them the miss...
IANAL but write like a drunk one.
Would you accept a article written by Bill Gates on the failure of Java to solve the worlds computing problems? This article takes valid words and throws a Sun spin on them. You would think that the MS markething machine would have recognized that the tag "unsafe" would scare the uninformed.
It is simple a new tech in its infancy. It currently does a great job of solving Windows problems and goes a long way toward removing COM installation nightmares. It also makes server side Web processing scream.
Are there secruity problems? Most likely. Can Java be used maliciously? Absolutly.
Supporters and detractors agree, I believe, that the most luscious piece of fruit in Microsoft's C#/CLR/IL/.net basket is language-independence. While many find that enticing because they believe they won't have to take a personal productivity hit while they learn and master new languages and idioms, an other, perhaps more important, advantage is that existing libraries do not need to be rewritten to move into the new platform. Since security in most languages is presumed to be a programmer rather than language/compiler/runtime responsibility, it follows that for a platform to be language independent and secure, mechanisms must be in place to hobble unsafe code, which must penalize performance and, perhaps, scalability. One alternative would be that the security is compromised in some way to maintain reasonable performance benchmarks. Another alternative is that some language features are rejected by the platform. I think Bill Joy was saying he would bet that the hobbling is compromised. Sun did have to deal with the leagacy/unsafe problem with JNI, so I believe he has an understanding of the implementation issues. I suspect it's more likely that performance and scalability issues will require serious adapters of the Microsoft platform to rewrite code using C#.
Write a just-in-time compiler for an emulator. You can't do this in Java, or any other "secure" language that doesn't let you write directly to memory, access it via pointers, and use pointers to functions in that memory.
You will NEVER see fast, efficient emulators or just-in-time compilers written in any so-called "secure" language. Instead, you need a language like C, or assembler... or both.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
One of the most annoying aspects of java is that you can't do that. Java is the perfect lock-yourself-in language. If you want to escape, the only standard mechanism is JNI, which is completely useless (the verbosity and ease of failure when using JNI is mind-boggling, when I tried to use it a year ago, I eventually had to write a tool for generating JNI. What should have been a simple foreign function interface is really a complete mess.)
If C# offers mostly the same as Java, but with added features for real-world programming, such as the ability to add a dirty hack where it's needed, without going through all the torture and pain that Java makes you suffer, then I and many other developers will be much more happy to use C# than Java.
If all you care about is security, you wouldn't be using Java anyway, and you would certainly not download executable code over the web (applets). And if all you want is applets, then by all means, go ahead and use Java. But for people looking for something to use for enterprise-wide programming systems, having to integrate lots of legacy code, I'll bet C# will make a strong contender just because of this feature.
True, making it simple to do unsafe things is potentially dangerous. But making it unecessarily complex to do simple things also adds complexity, which isn't good for security either.
Did I mix my threads? I thought I read earlier:
Which is closer to what most of the users I know have learned. "Just click 'OK'"
This is not a political statement. This is not legal advice. It's a frick'n Slasdot post. However: I'm Running For
Difference between C# and ActiveX in this case is that in ActiveX, everything is "Unsafe" and you either take it or leave it. In Java, of course, everything is "safe". C# can go either way.
My god, people... another +5 post that belies a complete lack of understanding of the subject a thand. Di you even read the articles? They aren't talking about unsafe as in unsafe controls (ie, controls not verified with a certiifcate server or utilizing APIs that can be damaging to the client) - they are talking about doing unsafe things in terms of variable and object manipulation. Use a pointer incorrectly in a C windows app, and windows crashes. Hence, it's "unsafe". Not as in potentially virus-ridden or whatever you took it to mean. Get a clue. I shouldv'e know better than to expect insightful comments about Windows technologies from slashdork readers.
I second that and just want to add two quotes here ...
.NET Framework", An Analysis by Foundstone, Inc. and CORE Security Technologies]
"Code that runs outside the control of the CLR is referred to as "unmanaged" code. Unmanaged code by definition is not constrained by the security
measures of the CLR, and is thus capable of obtaining unauthorized access to resources in the native environment via traditional attacks."
["Security in the Microsoft
"The unsafe keyword specifies that the marked block will run in an unmanaged context."
["Inside C#", Tom Archer, Microsoft Press 2001]