"C++ gives you the choice of traditional pointers or references. A "reference" is a sort of super-pointer that includes data on where valid targets must be, and gets checked for validity every time you use it. I don't do Java, but I am under the impression that it uses references only. That isn't enough in itself to prevent writing Java viruses, but it gives the OS a fighting chance of confining them to the sandbox... "
Actually, references are nothing but pointers under the hood. You can think of it as a constantly dereferenced pointer if you wish. References have the extra requirement that it must always have been initialized with a reference to an existing object. This is what the compiler enforces. But the compiler may be fooled as well:
What is y refering to now? This is perfectly legal C++ in some weird way. You can use y if you wish, and in most cases it will work (depending on compiler).
( Pointer version would look like:
Object* func()
{
Object x;
return
}
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?
and what difference does direct memory access have when these problems arise in communication channels (not located IN memory mind you)?
Currently, most of the projects simultaniously support Windows and Linux, but these projects are currently focusing a lot of attention of COM and.NET. They are not even adding support for the various open source technologies like CORBA. I expect that you will find open source operating systems to be a bit behind the times langauge wize in a few years.
COM and.NET does not automatically exclude CORBA. The desktop perhaps doesn't need CORBA (never has, never will..? I'm not an expert on CORBA, but the last time I read about it, it didn't feel very snappy/light weight). CORBA is however still a good choice for heavy weight distributed systems.
And I see nothing that will make CORBA obsolete with.NET framework. Instead, I see new implementations which utilize.NET so that you can use ONE implementation of CORBA in many languages w/o the need to reprogramming it for each language.
Also, open source is become more popular on the windows platform. Ever looked at CodeProject or Codeguru? These are two of hundreds of good open source sites. Most of its user base however, do not generally like the GPL. Odds are that they use a BSD style license (I have seen some LGPL'd code though). Anyhow, I could very well imagine that someone implements a.NETified CORBA implementation (or bridge). There are legacy systems which use CORBA, and there are situations when DCOM won't do the trick. And there are Windows platforms which ultimately have to communicate with these systems. Thus, someone will make a.NET CORBA implementation and sell it. And then someone just don't want to pay for it. Then an open source implementation is born.
IIRC, one difference between the java JIT and.NET JIT is that the.NET JIT saves the JIT compiled code for reuse. Thus, in theory,.NET apps should be faster after a good run through. I am however not 100% on this, since I read about this during early stages of.NET. It might just have been some vapour feature...
Have you ever tried running user NT desktops without giving them Administrator? I have, and it's a support nightmare. They can't install so much as a screensaver, which may be fine for controlled environments like a telesales CTI terminal bank "Would you like the porn channel?", but it doesn't work in an office environment; the masses rebel.
Your wonderful NT kernel security model is a waste of bits.
You don't need admin rights damnit! NT supports capabilities, much like Linux. In NT your process is given some default priveliges, everything else must be asked for. If your user profile allows the specific privelige you ask for, you get it. And this is a very good thing since you can then get the privelige when you need it, and release it when you don't. Thus you are eliminating many big risks associated with buffer underruns.
Unfortunately, many windows programmers are VB weenies or totally ignorant, so they choose to:
Require administrator rights for their application (i.e. programmer too stupid to read anything but the VB reference manual...)
After (luckily) have found the man pages for acquiring privelige tokens, they keep it open during the whole lifetime of the application (thus leaving it wide open for potential attacks)
The thing is, it's not hard to do this! It's childs play. There are API functions which you can call to acquire a privelige token and release them. And the ACL model is probably one of the simplest access control models out there. Someone who cannot grasp that, should not be producing public software IMHO.
Sadly, many of the redmond programmers are totally ignorant when it comes to security. My bet is that it's because most of their programmers are freshmen "hackers" whose only non-fake experience entry in their CV is Visual Basic.
Last time I checked, Linux implemented a capability model as well. I have not yet fully familiarised myself with it, but I can't remember that the programmer has to specifically ask for a privelige.
Lets not forget that most of the security holes found in Windows are in conjunction with other Microsoft products such as Office and the Explorer (I still consider IE to be a product and not a part of the OS, despite what Microsoft says...)
All in all, I think the dudes over at the kernel department is pretty aware of the security threats. Just look at the security model which NT/Win2k employs. It's far more advanced than the traditional UNIX security model, and still not too complex to understand. I think the problem lies in all of the other "loser" departments within Microsoft (which are mostly VB hackers which has no clue about security). They just don't care about security. Perhaps Bill has whipped them enough now to make a change.
[Offtopic]
I'd take a win2k kernel w/o all the messy gore surrounding it any day for serious work if it was possible. Why? The hardware support is much better for Windows than any other UNIX derivatives (and I don't have the knowledge nor time to produce a driver either), and the core OS isn't that bad.
And when customers have specific demands, you have to comply. You can't just stuff a UNIX os down their throat against their will.. (that is probably one of the fastest ways to lose your customer). But if the customer is willing and there is hardware support for what the customer wants built, I'd rather go for FreeBSD (or OpenBSD depending on situation) any day. (I don't trust many of the flaky Linux driver hackers out there.. and I don't know how and don't have time to do something about it. Tough shit I guess, but I'm lucky to have alternatives)
Hmm... lets see. The Linux camp is divided into two camps; the hacker geeks and the l33t windows gamer d00ds.
The geeks are too busy coding away (gracias) and the gamer d00ds are the type of people that leech their games from FTP sites. Not their local video game store. Unless you Linux is not brought to the wider audience, then there will be no revenues in Linux games. It's quite simple.
Windows will keep on dominating as the gamers platform of choice unless someone makes a Window out of Linux.. and that is not going to happen any time soon.
Slashdot Mirror
Obj-C = C + Smalltalk like OO-extensions. In essence, Obj-C is a strict superset of C, thus everything you can do in C, you can do in Obj-C.
If the program got killed off when accessing weird pointers, that was probably due to the OS and not the language itself.
"C++ gives you the choice of traditional pointers or references. A "reference" is a sort of super-pointer that includes data on where valid targets must be, and gets checked for validity every time you use it. I don't do Java, but I am under the impression that it uses references only. That isn't enough in itself to prevent writing Java viruses, but it gives the OS a fighting chance of confining them to the sandbox... "
;)
Actually, references are nothing but pointers under the hood. You can think of it as a constantly dereferenced pointer if you wish. References have the extra requirement that it must always have been initialized with a reference to an existing object. This is what the compiler enforces. But the compiler may be fooled as well:
Object& func()
{
Object x;
Object& obj = x;
return x;
}
Object& y = func();
What is y refering to now? This is perfectly legal C++ in some weird way. You can use y if you wish, and in most cases it will work (depending on compiler).
( Pointer version would look like:
Object* func()
{
Object x;
return
}
Object* y = func();
I just hade to clear that up
Unsafe code can be both IL code (managed and unmanaged) and x86 code (managed and unmanaged) if I have understood everything correctly.
and what difference does direct memory access have when these problems arise in communication channels (not located IN memory mind you)?
COM and .NET does not automatically exclude CORBA. The desktop perhaps doesn't need CORBA (never has, never will..? I'm not an expert on CORBA, but the last time I read about it, it didn't feel very snappy/light weight). CORBA is however still a good choice for heavy weight distributed systems.
And I see nothing that will make CORBA obsolete with .NET framework. Instead, I see new implementations which utilize .NET so that you can use ONE implementation of CORBA in many languages w/o the need to reprogramming it for each language.
Also, open source is become more popular on the windows platform. Ever looked at CodeProject or Codeguru? These are two of hundreds of good open source sites. Most of its user base however, do not generally like the GPL. Odds are that they use a BSD style license (I have seen some LGPL'd code though). Anyhow, I could very well imagine that someone implements a .NETified CORBA implementation (or bridge). There are legacy systems which use CORBA, and there are situations when DCOM won't do the trick. And there are Windows platforms which ultimately have to communicate with these systems. Thus, someone will make a .NET CORBA implementation and sell it. And then someone just don't want to pay for it. Then an open source implementation is born.
One implementation to rule them all... ;)
IIRC, one difference between the java JIT and .NET JIT is that the .NET JIT saves the JIT compiled code for reuse. Thus, in theory, .NET apps should be faster after a good run through. I am however not 100% on this, since I read about this during early stages of .NET. It might just have been some vapour feature...
Your wonderful NT kernel security model is a waste of bits. You don't need admin rights damnit! NT supports capabilities, much like Linux. In NT your process is given some default priveliges, everything else must be asked for. If your user profile allows the specific privelige you ask for, you get it. And this is a very good thing since you can then get the privelige when you need it, and release it when you don't. Thus you are eliminating many big risks associated with buffer underruns.
Unfortunately, many windows programmers are VB weenies or totally ignorant, so they choose to:
The thing is, it's not hard to do this! It's childs play. There are API functions which you can call to acquire a privelige token and release them. And the ACL model is probably one of the simplest access control models out there. Someone who cannot grasp that, should not be producing public software IMHO.
Sadly, many of the redmond programmers are totally ignorant when it comes to security. My bet is that it's because most of their programmers are freshmen "hackers" whose only non-fake experience entry in their CV is Visual Basic.
Last time I checked, Linux implemented a capability model as well. I have not yet fully familiarised myself with it, but I can't remember that the programmer has to specifically ask for a privelige.
Lets not forget that most of the security holes found in Windows are in conjunction with other Microsoft products such as Office and the Explorer (I still consider IE to be a product and not a part of the OS, despite what Microsoft says...)
All in all, I think the dudes over at the kernel department is pretty aware of the security threats. Just look at the security model which NT/Win2k employs. It's far more advanced than the traditional UNIX security model, and still not too complex to understand. I think the problem lies in all of the other "loser" departments within Microsoft (which are mostly VB hackers which has no clue about security). They just don't care about security. Perhaps Bill has whipped them enough now to make a change.
[Offtopic]
I'd take a win2k kernel w/o all the messy gore surrounding it any day for serious work if it was possible. Why? The hardware support is much better for Windows than any other UNIX derivatives (and I don't have the knowledge nor time to produce a driver either), and the core OS isn't that bad.
And when customers have specific demands, you have to comply. You can't just stuff a UNIX os down their throat against their will.. (that is probably one of the fastest ways to lose your customer). But if the customer is willing and there is hardware support for what the customer wants built, I'd rather go for FreeBSD (or OpenBSD depending on situation) any day. (I don't trust many of the flaky Linux driver hackers out there.. and I don't know how and don't have time to do something about it. Tough shit I guess, but I'm lucky to have alternatives)
Hahaha! Your posts always make me laugh out loud. You must be the best damn troll on slashdot. Keep on rocking the house! :D
Linux games were expected to sell?
Hmm... lets see. The Linux camp is divided into two camps; the hacker geeks and the l33t windows gamer d00ds.
The geeks are too busy coding away (gracias) and the gamer d00ds are the type of people that leech their games from FTP sites. Not their local video game store. Unless you Linux is not brought to the wider audience, then there will be no revenues in Linux games. It's quite simple.
Windows will keep on dominating as the gamers platform of choice unless someone makes a Window out of Linux.. and that is not going to happen any time soon.