I never said that the most common products are the least secure. I said they are the MOST LIKELY TO BE ATTACKED.
Learn to read. Then learn to think.
Also, there is a WORLD of difference between products intended for the desktop (where usability and performance are *usually* a higher priority than security) and server environments, where security and stability should be a higher priority than features.
A SINGLE example (Apache) does not disprove the general trend! Look at Sendmail, arguably the most common UNIX mailer in existence, for all time. Sendmail has had more root-compromise security bugs than ANY PRODUCT IN HISTORY. Sure, it may be relatively secure now, but it has taken MANY years, and I would argue that there are STILL bugs lurking in it.
Again, LEARN TO READ. I said that there is a SIGNIFICANT CORRELATION between how popular a product is, and how likely it is to be the target of a virus/worm/whatever author.
The main reason that there are so many viruses written for Microsoft products (mainly Word, Windows, and Outlook) is that they are the most common products in their niches.
If Linux became the most popular desktop OS, then it would become the target of the virus writers. Same for any other competitor to Microsoft products.
By the same flawed logic, then Microsoft shouldn't be allowed to include a GUI (windowing system), because someone else might want to provide a better one. Or networking. Or hell, even virtual memory.
Sorry, Netscape blew it. Plain and simple. Microsoft was only too happy to watch them destroy themselves.
I never said the browser SHOULD crash. Software should never, never, never, never, never, never, never, never, never, never, ever crash.
But the fact is that this bug is totally unimportant. Sure, IE shouldn't crash. But this bug can only occur if you INTEND to hit the bug -- this is not normal HTML. And the crash does not expose any security hole (no buffer overruns, etc.), so it's just a crashing bug.
So, Microsoft will fix it, and that's all. In general, IE has been FAR, FAR more tolerant of evil HTML than Netscrape ever was.
Microsoft's security push has only been going on for so long. This bug has apparently existed in IE4.0+, which was released well before the security emphasis.
I'm not saying that excuses anyone from not examining security more closely in the past -- security should always be a high priority, and stability even higher than that. But you are exaggerating when you say that they are "failing in that mission". At least give them a chance to do something about their (relatively recent) mission.
And in one crucial way, Microsoft IS extremely serious about fixing these kinds of bugs -- by switching to managed code (.Net / C# / etc.). It will take many years to move the majority of code that users run to managed code (such as browsers, etc.), but it WILL happen. And when it does, we will have eliminated the vast majority of simple memory management bugs, such as this one (bad pointers, buffer overruns, etc.). Managed code will not magically fix all problems, but it will fix the majority of problems like this.
So, for once, Microsoft is doing it right. But anyone who thinks that BEGINNING an initiative means that the initiative is OVER / solved, doesn't understand English.
Oh my god! Someone found! A BUG! In SOFTWARE! And it happens on TOTALLY INVALID HTML! How could Microsoft possibly make such a horrible, horrible mistake!!
THIS NEVER HAPPENS ANYWHERE ELSE! Thank GOD the rest of the world is bug-free!
Sooooooo, someone found a bug in Office. Why is this news? Why is this reported, and not the bugs in any other software?
Software has bugs. It's like the definition of software. Big freakin' deal. Someone found the bug, Microsoft will fix it, people will download the patch, and life will go on.
When will Slashdot report on something UNRELATED to Microsoft? When will Slashdot get over its obvious, antagonistic bias? Probably never.
Regardless of whether Microsoft publicly acknowledges support for x86-64, it has ALREADY implemented support for it in the NT source tree.
Microsoft has a very complex relationship with Intel. If Microsoft has to commit to a decision that could have a negative effect on its relationship with Intel, it has to think long and hard about that, and it has to keep information about those decisions as quiet as possible, until it is ready to announce.
To make this more clear:
Microsoft has already ported NT to 64-bit (in general), and this is tested, documented code. This was done years ago.
Microsoft has already ported NT to x86-64, which is just one specific 64-bit platform.
Whether Microsoft commits to supporting x86-64 depends on the market. Microsoft is positioned very well to adapt to either fate of 64-bit computing: IA64 or x86-64.
I suppose it isn't that different. In my post I never compared the.Net implementation against Linux / ld.so. I'm just trying to clear away some of the FUD around this issue.
Although arguably it's cleaner to have the binding stuff in a file, rather than having to carry it around in your process environment strings.
Well, I can see your point. But the main problem with the registry is that information has to be "loaded" into it to be useful. In other words, say you have an app directory on a CD (or where-ever), and your app needs one of these settings. The XML file is called a "manifest", and the filename is the name of the executable + ".config" (so "foo.exe.config"). This config file can specify assembly binding overrides, configuration values, debugging parameters, and lots more.
The nice thing about this is that you never have to load the XML file into the registry. So you can also have two copies of the SAME app that have different settings. Which, if you have to muck around in the registry, is impossible or just very annoying. Also, the only things in that XML file are the things relevant to your app -- you don't have to wade through 30 different registry keys to find what you want.
All are good books. The Reference one is just that -- a reference. It is not a tutorial, although there are a few samples. It's mostly just a hardcore description of the internal APIs.
Also, people, pull your heads out of your asses. A lot of the reason that life is difficult on Windows is that Microsoft has had to put up with 15+ years of application developers doing STUPID things in their apps, and then whining when Microsoft has fixed the bugs they depended on, or improved APIs. Microsoft has spent TONS of money on backward compatibility. Arguably, the commercial success of Windows has stifled its own technical development.
Your comment that "When has Microsoft ever gotten that right?" is just misinformed and stupid. Of course there are back-compat problems -- but the exception proves the rule. 2000/XP run an AMAZING number of apps, written over a long, long period of time, and with a reasonable degree of fidelity. Just because your favorite app broke, doesn't mean that N,000 apps DIDN'T.
Another reason is that an EXE or a DLL can contain BOTH managed (.Net) and unmanaged (traditional compiled) code.
So, yes, it's partly a means to make it easier to deal with them ("ohh, it's just a different kind of EXE/DLL"), but there is also a very good technical reason -- interoperability between managed and unmanaged code.
It's a LOT more complicated than that. Microsoft is trying to solve a very real problem that has plagued developers on EVERY platform that supports DLLs, including Linux. Using symlinks is just one approach. And while it does solve some of the problems, it is not a complete solution.
Here's one of the main situations that Microsoft is trying to address: Microsoft ships FOO.DLL with Windows, or as part of some SDK (like DirectX). Company 1 develops an app, ships it, and on the app CD, it has a copy of FOO.DLL. Company 2 does the same thing.
Now. A bug is discovered in FOO.DLL, and it must be fixed. Unfortunately, fixing it one way causes app 1 to crash, and fixing it the other way causes app 2 to crash. And both apps link to the same version.
So what do you do? In the past, you just crossed your fingers and looked the other way, and tried to write code that behaved as best as possible in whatever circumstances you could think of. But inevitably bug fixes cause other bugs (regressions).
So, Microsoft is trying to solve this, by changing DLL binding, in two important ways:
1) DLL binding will use much more than just a name. Microsoft has developed a very powerful & flexible way to do DLL binding. This is what the.Net framework uses, but it is NOT limited to.Net DLLs -- traditional "unmanaged" code can use this, too. I won't go into details here, because it's very well-documented elsewhere, but suffice to say that developers will have a LOT more control over how apps and DLLs bind to DLLs. This is purely a Good Thing, and it IS fully backward-compatible -- it's an opt-in.
2) You'll have total control over redirecting DLLs, on a per-app basis. Some docs here. This means that you can override DLL binding -- if app 1 MUST have version 4.3.5.1.34 of FOO.DLL, and app 2 MUST have version 4.3.5.1.35b, then you can write a simple XML file for each one, that controls exactly which version they get.
Anyone who reads some kind of evil into this is just plain stupid, and has never done any serious development. Any programmer worth their salt knows that DLL binding is ridiculously crude -- and that goes for every modern platform. Microsoft suffers from this more than most, and has therefore decided to do something about it, and has designed a pretty good system. If you have half a brain, you should check it out, and try to keep that knee-jerk reaction under control. (I'm not directing that comment at Grishnakh, but at all of the slobbering idiots who just flame Microsoft whenever they see the name in a headline.)
Get a grip. Microsoft has already announced that, as part of the ECMA standards process, they are granting EVERYONE the right to implement the.Net Framework, WITHOUT paying any royalties whatsoever.
So... 1) It will be easy for Microsoft to cope with changes to the standard, and 2) How could *anyone* implement a change to a specification, before the change occurs?
[Sorry to post so much in a single day, but...]
Microsoft has already provided a Java compiler that produces MSIL (.Net's bytecode equivalent) instead of Java bytecode. It's called J#. It works great. It also handles translating the names of most of the Java classes to the.Net equivalents.
Which just shows how little you understand of Microsoft's SOAP framework. The.Net Framework supports SOAP encoding, but it is done in a very general pluggable encoder class hierarchy.
Microsoft provides a SOAP formatter, and a high-density binary RPC-like encoding. Even if this RPC encoding is not the same as the SOAP RPC encoding, it will only take Microsoft a single service release to update it, and bring it into conformance with any SOAP/RPC specification -- if Microsoft chooses to do so.
You can even write your own encoders, and slot those into Microsoft's existing framework! For example, the SOAP encoder is a class called SoapFormatter. The binary RPC formatter is called (surprisingly) BinaryFormatter. But they both implement IFormatter and IRemotingFormatter -- and that interface is publicly documented. Anyone can write a class that implements IFormatter, and slot their class right into the ASP.Net (SOAP) framework.
You should really try to understand things more before you just attack them. And I don't see at all how this is "biting" Microsoft, given their very flexible, extensible platform.
Unfortunately, Microsoft middle managers periodically get infatuated with stupid naming conventions. ActiveFoo, DirectFoo, Foo.Net, whatever. It's like pixie-dust -- you just rename your project ActiveDirectFoo++.Net 2000 XP to get it noticed. (I worked there for 5 years, so I've seen this first-hand.)
They slapped the.Net name on a bunch of different things:
A new language platform. This part went through several names: Universal Runtime (URT), Common Language Runtime / Common Language Infrastructure (CLR / CLI), etc. This includes the C# language (and VB.Net, managed extensions to C++, etc.), MSIL, and the Base Class Library (BCL). Pretty good stuff, in my opinion.
SOAP, implemented using the CLR. This is actually a pretty cool implementation of SOAP, because the.Net platform provides 95% of the glue you need to expose (or use) classes and methods and datatypes over XML/HTTP (SOAP). This is a core part of the.Net Framework, and of ASP.Net, which is Microsoft's ISAPI/IIS bridge into the.Net world. In my opinion, pretty good technology, and it's surprisingly "open".
A set of centralized back-end services. This is Hailstorm, Passport, etc. (Passport got renamed ".Net Passport".) This is Microsoft's effort to make money on "software as a service". They recognize that they can't just float on Office sales forever, and they want to provide some kind of centralized services, and get some fraction of a dollar for every widget transaction on the net. (This is where the ".Net" name originally came from -- it just kind of metastasized into other projects later.) In my opinion, this is the worst aspect of.Net -- it's confusing to developers, and Microsoft has not developed an image as a company that can reliably provide network services, so why should anyone trust their service to Microsoft?
Anyway, I hope this provides some info on what the.Net name covers, and why. The.Net name originally started as an umbrella name for the centralized network services that Microsoft wants to provide (Hailstorm, Passport, blah blah). Later, Microsoft decided to plaster it all over a bunch of other things, and it was just a confusing disaster.
In my opinion, the most important part to focus on is the new language platform -- MSIL and C# and the managed C++ extensions are a really Good Thing, and they are also -- surprisingly -- "Open". They have been submitted to ECMA as public standards, and Microsoft has pledged that any patents they hold that are involved in implementing the standards may be used, royalty-free, by anyone who wishes to implement the standards.
God, do you people even know how to read?.Net is no more a lock-in than Java. In fact, it's LESS of a lock-in. As has been reported on/., Microsoft has made public the specifications for every layer of.Net -- the languages, the intermediate language (bytecode equivalent), the code libraries, etc. It's no more a lock-in than C++ is.
And there are already several open-source projects implementing.Net from scratch -- including on Linux! (See Mono, and the GNU equivalent, I forget its name.)
If I had a nickel for every stupid, uninformed comment about Microsoft on/. I could BUY Microsoft.
`Value classes' as you term them, amazingly complicate the language; they're one of the reasons that C++ is such a ball of hair.
Wrong. You are confusing local-scoped (stack) value types with explicit memory management (malloc/free new/delete). The thing that makes life so difficult in C++ is explicit memory management -- the programmer has control over when memory is freed, and therefore, usually gets it wrong.
Look at the value type system in C# /.Net. It's very, very simple, simplifies a lot of the base class library (common classes like Point and Rectangle), and just makes sense.
I love garbage collectors. However, putting undue pressure on them will reduce their performance. And memory management performance is one of the hot issues between traditional unmanaged execution (C/C++ malloc/new/etc.) and managed memory (GCs).
Value types do not complicate GC design. They are completely orthogonal to GC design -- by definition, they simply don't involve GC at all.
Again, look at value types in C# /.Net. Very simple, very effective, and with absolutely no penalty for use.
Oh, please. How about all the startups that never started because they had business plans that a retarded 10-year old could see through? How about all the startups that failed because they were just plain STUPID?
Slashdot Mirror
I never said that the most common products are the least secure. I said they are the MOST LIKELY TO BE ATTACKED.
Learn to read. Then learn to think.
Also, there is a WORLD of difference between products intended for the desktop (where usability and performance are *usually* a higher priority than security) and server environments, where security and stability should be a higher priority than features.
A SINGLE example (Apache) does not disprove the general trend! Look at Sendmail, arguably the most common UNIX mailer in existence, for all time. Sendmail has had more root-compromise security bugs than ANY PRODUCT IN HISTORY. Sure, it may be relatively secure now, but it has taken MANY years, and I would argue that there are STILL bugs lurking in it.
Again, LEARN TO READ. I said that there is a SIGNIFICANT CORRELATION between how popular a product is, and how likely it is to be the target of a virus/worm/whatever author.
The main reason that there are so many viruses written for Microsoft products (mainly Word, Windows, and Outlook) is that they are the most common products in their niches.
If Linux became the most popular desktop OS, then it would become the target of the virus writers. Same for any other competitor to Microsoft products.
By the same flawed logic, then Microsoft shouldn't be allowed to include a GUI (windowing system), because someone else might want to provide a better one. Or networking. Or hell, even virtual memory.
Sorry, Netscape blew it. Plain and simple. Microsoft was only too happy to watch them destroy themselves.
Where in the HELL did this article say that Linux was going to be "locked out" of this architecture? This is TOTAL /. FUD.
Can Linux users actually READ?
And if desktop PCs improve, how is that bad?
I never said the browser SHOULD crash. Software should never, never, never, never, never, never, never, never, never, never, ever crash.
But the fact is that this bug is totally unimportant. Sure, IE shouldn't crash. But this bug can only occur if you INTEND to hit the bug -- this is not normal HTML. And the crash does not expose any security hole (no buffer overruns, etc.), so it's just a crashing bug.
So, Microsoft will fix it, and that's all. In general, IE has been FAR, FAR more tolerant of evil HTML than Netscrape ever was.
Microsoft's security push has only been going on for so long. This bug has apparently existed in IE4.0+, which was released well before the security emphasis.
I'm not saying that excuses anyone from not examining security more closely in the past -- security should always be a high priority, and stability even higher than that. But you are exaggerating when you say that they are "failing in that mission". At least give them a chance to do something about their (relatively recent) mission.
And in one crucial way, Microsoft IS extremely serious about fixing these kinds of bugs -- by switching to managed code (.Net / C# / etc.). It will take many years to move the majority of code that users run to managed code (such as browsers, etc.), but it WILL happen. And when it does, we will have eliminated the vast majority of simple memory management bugs, such as this one (bad pointers, buffer overruns, etc.). Managed code will not magically fix all problems, but it will fix the majority of problems like this.
So, for once, Microsoft is doing it right. But anyone who thinks that BEGINNING an initiative means that the initiative is OVER / solved, doesn't understand English.
Oh my god! Someone found! A BUG! In SOFTWARE! And it happens on TOTALLY INVALID HTML! How could Microsoft possibly make such a horrible, horrible mistake!!
THIS NEVER HAPPENS ANYWHERE ELSE! Thank GOD the rest of the world is bug-free!
Windows 2000 and XP have already done this. And it works for nearly every video adapter on the market.
I love the way the desktop is using translucent windows, but the mail icon is still the same crappy monochrome (1 bit!) icon.
Sooooooo, someone found a bug in Office. Why is this news? Why is this reported, and not the bugs in any other software?
Software has bugs. It's like the definition of software. Big freakin' deal. Someone found the bug, Microsoft will fix it, people will download the patch, and life will go on.
When will Slashdot report on something UNRELATED to Microsoft? When will Slashdot get over its obvious, antagonistic bias? Probably never.
Regardless of whether Microsoft publicly acknowledges support for x86-64, it has ALREADY implemented support for it in the NT source tree.
Microsoft has a very complex relationship with Intel. If Microsoft has to commit to a decision that could have a negative effect on its relationship with Intel, it has to think long and hard about that, and it has to keep information about those decisions as quiet as possible, until it is ready to announce.
To make this more clear:
I suppose it isn't that different. In my post I never compared the .Net implementation against Linux / ld.so. I'm just trying to clear away some of the FUD around this issue.
Although arguably it's cleaner to have the binding stuff in a file, rather than having to carry it around in your process environment strings.
Well, I can see your point. But the main problem with the registry is that information has to be "loaded" into it to be useful. In other words, say you have an app directory on a CD (or where-ever), and your app needs one of these settings. The XML file is called a "manifest", and the filename is the name of the executable + ".config" (so "foo.exe.config"). This config file can specify assembly binding overrides, configuration values, debugging parameters, and lots more.
The nice thing about this is that you never have to load the XML file into the registry. So you can also have two copies of the SAME app that have different settings. Which, if you have to muck around in the registry, is impossible or just very annoying. Also, the only things in that XML file are the things relevant to your app -- you don't have to wade through 30 different registry keys to find what you want.
> Quick. What is a utility which will tell
/exports foo.dll". Pay attention before you say something stupid. Although I do agree with some of your other points.
> you all the shared libraries that an
> application uses?
On NT, "dumpbin
Microsoft's APIs are not that secret. Check out Windows NT / 2000 Native API Reference by Gary Nebbett. I have a copy of this -- he's done an excellent job at reverse engineering most of the internal NT APIs. (And, no, it wasn't published by MS Press.) Also, Undocumented Windows 2000 Secrets: A Programmer's Cookbook and Undocumented Windows NT.
All are good books. The Reference one is just that -- a reference. It is not a tutorial, although there are a few samples. It's mostly just a hardcore description of the internal APIs.
Also, people, pull your heads out of your asses. A lot of the reason that life is difficult on Windows is that Microsoft has had to put up with 15+ years of application developers doing STUPID things in their apps, and then whining when Microsoft has fixed the bugs they depended on, or improved APIs. Microsoft has spent TONS of money on backward compatibility. Arguably, the commercial success of Windows has stifled its own technical development.
Your comment that "When has Microsoft ever gotten that right?" is just misinformed and stupid. Of course there are back-compat problems -- but the exception proves the rule. 2000/XP run an AMAZING number of apps, written over a long, long period of time, and with a reasonable degree of fidelity. Just because your favorite app broke, doesn't mean that N,000 apps DIDN'T.
Another reason is that an EXE or a DLL can contain BOTH managed (.Net) and unmanaged (traditional compiled) code.
So, yes, it's partly a means to make it easier to deal with them ("ohh, it's just a different kind of EXE/DLL"), but there is also a very good technical reason -- interoperability between managed and unmanaged code.
It's a LOT more complicated than that. Microsoft is trying to solve a very real problem that has plagued developers on EVERY platform that supports DLLs, including Linux. Using symlinks is just one approach. And while it does solve some of the problems, it is not a complete solution.
.Net framework uses, but it is NOT limited to .Net DLLs -- traditional "unmanaged" code can use this, too. I won't go into details here, because it's very well-documented elsewhere, but suffice to say that developers will have a LOT more control over how apps and DLLs bind to DLLs. This is purely a Good Thing, and it IS fully backward-compatible -- it's an opt-in.
Here's one of the main situations that Microsoft is trying to address: Microsoft ships FOO.DLL with Windows, or as part of some SDK (like DirectX). Company 1 develops an app, ships it, and on the app CD, it has a copy of FOO.DLL. Company 2 does the same thing.
Now. A bug is discovered in FOO.DLL, and it must be fixed. Unfortunately, fixing it one way causes app 1 to crash, and fixing it the other way causes app 2 to crash. And both apps link to the same version.
So what do you do? In the past, you just crossed your fingers and looked the other way, and tried to write code that behaved as best as possible in whatever circumstances you could think of. But inevitably bug fixes cause other bugs (regressions).
So, Microsoft is trying to solve this, by changing DLL binding, in two important ways:
1) DLL binding will use much more than just a name. Microsoft has developed a very powerful & flexible way to do DLL binding. This is what the
2) You'll have total control over redirecting DLLs, on a per-app basis. Some docs here. This means that you can override DLL binding -- if app 1 MUST have version 4.3.5.1.34 of FOO.DLL, and app 2 MUST have version 4.3.5.1.35b, then you can write a simple XML file for each one, that controls exactly which version they get.
Anyone who reads some kind of evil into this is just plain stupid, and has never done any serious development. Any programmer worth their salt knows that DLL binding is ridiculously crude -- and that goes for every modern platform. Microsoft suffers from this more than most, and has therefore decided to do something about it, and has designed a pretty good system. If you have half a brain, you should check it out, and try to keep that knee-jerk reaction under control. (I'm not directing that comment at Grishnakh, but at all of the slobbering idiots who just flame Microsoft whenever they see the name in a headline.)
Get a grip. Microsoft has already announced that, as part of the ECMA standards process, they are granting EVERYONE the right to implement the .Net Framework, WITHOUT paying any royalties whatsoever.
The patents are purely defensive.
And in related news, the sky is not falling.
So... 1) It will be easy for Microsoft to cope with changes to the standard, and 2) How could *anyone* implement a change to a specification, before the change occurs?
Main J# page
J# download page (free!)
J# is a free download because it is an add-on to Visual Studio .Net (which isn't).
Which just shows how little you understand of Microsoft's SOAP framework. The .Net Framework supports SOAP encoding, but it is done in a very general pluggable encoder class hierarchy.
.Net (SOAP) framework.
Microsoft provides a SOAP formatter, and a high-density binary RPC-like encoding. Even if this RPC encoding is not the same as the SOAP RPC encoding, it will only take Microsoft a single service release to update it, and bring it into conformance with any SOAP/RPC specification -- if Microsoft chooses to do so.
You can even write your own encoders, and slot those into Microsoft's existing framework! For example, the SOAP encoder is a class called SoapFormatter. The binary RPC formatter is called (surprisingly) BinaryFormatter. But they both implement IFormatter and IRemotingFormatter -- and that interface is publicly documented. Anyone can write a class that implements IFormatter, and slot their class right into the ASP
You should really try to understand things more before you just attack them. And I don't see at all how this is "biting" Microsoft, given their very flexible, extensible platform.
Unfortunately, Microsoft middle managers periodically get infatuated with stupid naming conventions. ActiveFoo, DirectFoo, Foo .Net, whatever. It's like pixie-dust -- you just rename your project ActiveDirectFoo++ .Net 2000 XP to get it noticed. (I worked there for 5 years, so I've seen this first-hand.)
They slapped the .Net name on a bunch of different things:
Anyway, I hope this provides some info on what the .Net name covers, and why. The .Net name originally started as an umbrella name for the centralized network services that Microsoft wants to provide (Hailstorm, Passport, blah blah). Later, Microsoft decided to plaster it all over a bunch of other things, and it was just a confusing disaster.
In my opinion, the most important part to focus on is the new language platform -- MSIL and C# and the managed C++ extensions are a really Good Thing, and they are also -- surprisingly -- "Open". They have been submitted to ECMA as public standards, and Microsoft has pledged that any patents they hold that are involved in implementing the standards may be used, royalty-free, by anyone who wishes to implement the standards.
God, do you people even know how to read? .Net is no more a lock-in than Java. In fact, it's LESS of a lock-in. As has been reported on /., Microsoft has made public the specifications for every layer of .Net -- the languages, the intermediate language (bytecode equivalent), the code libraries, etc. It's no more a lock-in than C++ is.
.Net from scratch -- including on Linux! (See Mono, and the GNU equivalent, I forget its name.)
/. I could BUY Microsoft.
And there are already several open-source projects implementing
If I had a nickel for every stupid, uninformed comment about Microsoft on
How ironic. We'll have to go to Russia, to be free. :\
(btw, there is no more "Soviet" Russia. see early 1990s.)
Wrong. You are confusing local-scoped (stack) value types with explicit memory management (malloc/free new/delete). The thing that makes life so difficult in C++ is explicit memory management -- the programmer has control over when memory is freed, and therefore, usually gets it wrong.
Look at the value type system in C# /
I love garbage collectors. However, putting undue pressure on them will reduce their performance. And memory management performance is one of the hot issues between traditional unmanaged execution (C/C++ malloc/new/etc.) and managed memory (GCs).
Value types do not complicate GC design. They are completely orthogonal to GC design -- by definition, they simply don't involve GC at all.
Again, look at value types in C# /
Oh, please. How about all the startups that never started because they had business plans that a retarded 10-year old could see through? How about all the startups that failed because they were just plain STUPID?