In complement to Roger, let me add some more information.
C++ is an evolution of C towards OOP and Generic programming (this second was added later with the income of templates, and was mainly "discovered by using templates", so the language syntax is a little bit fuzzy) actually introducing some "functional programming" techniques (via "lambda").
It retains the C "original sin" that consider the memory as a resource that must be managed by the programmer. In C this is a requirement (since it is a "high level assembler") But C++ -to retain this- introduces OOP without making a clear distinction between objects and values (you can instantiate a class either on heap and refer to it with a pointer, as well as on the stack or as an embedded member) and hence having to distinguish in syntax between address and reference. With the problem that is no always so clear who has to destroy something, and how can every other be informed of such an event. And that's what makes C++ "difficult".
On the other side, Java removed a number of C++ features (the ones that seemed to its designers "dangerous") and introduced a garbage collected memory model, and the idea that every object is on a managed heap.
This simplify a lot the OOP programming, but eliminates some useful thing certain abstract operation are comfortable with (like operator overloading, default parameter,...).
Java is not properly a "compiled language" mainly because a machine hardware processor don't have a "garbage collected heap". It requires a "virtual machine" dealing at least with the memory handling stuff.
Java designer -by the way- specify the interface between such such a machine and the language so that the language can be compiled in a way that no knowledge is required about the hardware instruction set, thus making Java programming suitable for every Java machine implementation for whatever platform.
Microsoft, to react to expansion of Java, introduced the .Net initiative, that -essentially- made available a "garbage collected heap and a virtual machine speaking MSIL - MS Intermediate Language", that -unlike the JVM- is much more similar in is "instruction set" to the underlying x86 processors. (an MSIL assembly program is compiled just before it is executed into processor instruction and then executed: this makes programs slower in start but faster in execution)
Since C++ (the most used language for COM object development, whose are mostly based many MS component interfaces) cannot interact with such an environment (there is no "relocable pointer" - also known as "handle" - and "tracked reference" for that) an new language (C#) was developed.
Like Java, it introduces a clear distinction between values (that must be on stack or somehow embedded in objects) and objects (that are always on heap) thus making the responsibility of the garbage collector clear, and the need of distinct pointer and reference syntax useless,thus eliminating the most of C++ fuzziness.
Unlike Java, C# retains C++ features like operator overloading, letting "type abstraction" still possible, and low level access still possible with unsafe operation that can still be explicitly required where needed.
Similarly, C++ had also been extended by Microsoft into C++/CLI by adding a number of keywords to let C++ able also to interact with "managed" environment.
As far today (2010) things seems to me, such "extension" are not widely accepted from both the C++ community (Who does more "system programming stuffs" don't like "managed environment") and the .Net community (that prefer the more simple C#, for managed stuffs).
To enforce the use of .Net, Miscorsoft came with a framework that today has a huge class library, making relatively simple every sort of "Programming" either about GUI, Networking, Web, Multimedia etc.
C++ cannot access such libraries and must therefore use natively compiled (or compilable) libraries.
Conversely, C++ compiler are available for virtually whatever processor, while MSIL JIT compiler for processor other than x86 are a rarity. (but x86 means both Windows and Linux, that is 98% of the end-user and data-center OSs of today: mono is -in its essence- the Linux implementation of an MSIL compiler).
Now to come to your questions:
a) Depends: C# is a simplified C++: going to C++ from C# means learn how to manage yourself memory and manage yourself addressing and pointers.
But the most of the GUI programming does not depend on the language but on the library used to manage the graphic interaction.
If your "calculator program" spits results on the "standard output" after taking inputs from the "standard input" ... C++ and C#are different only in what I just told.
If it has a graphic user interface, in C# you will probably use WinForm or WPF (.Net libraries), in C++ you will probably fall-through to the native Win32 C API or to some C++ wrapper like MFC or like WxWidget, Qt etc.
Completely different experiences.
b)yes: they are two well defined languages, each with its own specification. One is not a preprocessor for the other. If I well understood the question.
c)yes, by invoking
from the command line. But it still requires a .Net framework equipped machine to run (Just like a Win32 Application requires a Win32 "equipped machine" to run: you cannot run a Windows exe on linux, after all!)
d)Ideally yes, until a .Net equivalent MSIL machine exist for that platform. Apart from "mono", I'm not aware of any other implementation on.
In substance, if you want to be a windows developer (including Windows mobile) C# is probably more productive. If you want to be cross platform, Java for OOP and C++ for "native" are more widely available, but less "feature reach".
If you're not interested in immediate feature, but are foreseeing a long term language, give also a look to D
It is still immature in terms of frameworks and tools, but as a language it eliminates all the C++ fuzziness taking many C++, C# and Java paradigms (including both RAII and garbage collected OOP) good functional and meta-programming (D templates are far better then C++ ones) and compiles in native machine code. (and can be integrated in MS Visual Studio via visual D
It is gaining popularity in game programming, since it easily interface native C libraries, but is still in its "nerd stage" for certain aspects.