VS12 can convert, but can also natively load VS2010 project files without conversion. It includes a full copy of the VS2010 toolchain, and Microsoft claims that all future versions will have direct backwards compatibility until VS2010.
RE: Combuster,
Here's something that GCC
cannot do, and the necessity of it is irrelevant: it cannot make naked functions in x86 mode. Visual C++ can. Not only that, VC++ supplies you with a _LOCAL_SIZE immediate so you can set up the stack of an ISR, so that you can use it as an actual C/++ function. The only portable way to do ISRs in GCC is to use assembly and call C++ -- VC++ can do it all from within C++, with one less call, too. Important? No, but it is a difference. Clang can do naked functions as well, but lacks an equivalent of _LOCAL_SIZE. I've actually requested naked support in GCC, but was flat out told "no" -- if it isn't needed in Linux, it isn't needed in GCC.
As per "If you care about performance, use ICC" -- yes, it's not as though ICC does not cost a relatively exorbitant amount, particularly when you can get various versions of VC++ for free via the various programs (bizspark, etc).
Visual C++ Steps:
- Set up projects for loading vhd, compiling kernel, expanding kernel, and closing vhd
write kernel expander
write kernel
It really isn't that complex. Using build order settings, this is quite trivial and extremely painless, particularly in VS2010 or VS2012. Nobody cares about <= VS2008 anymore.
GCC isn't the
right tool for building kernels, any more than VC or ICC are. GCC is the
right tool for building
Linux, because that's what GCC is pretty much designed to do - Linux and Linux Apps. Anything else is just an added bonus: it is designed for Linux and to make Linux faster these days. The developers don't care about other OSen because they don't have to. If you want actual portability, follow the Clang project, particularly since Clang is also trying to integrate Visual C++ compatibility as well as features that GCC developers won't add (like naked functions).
The
only limitation that I've ever run into with VC is the inability to prevent SSE code generation for 64-bit targets. That's it. A simple reworking of part of my design (and not a significant part) meant that that was fine. In fact, it may actually speed up the system in general in the end. But claiming that the only reason that someone would use VC is for "a few comfy features" or "bragging rights" is just as ridiculous a statement as "the only reason someone would use GCC is so they can turn off SSE code generation". Not everyone cares about C support - I certainly don't. I use C++ exclusively - I have no reason not to, because anything I could write in C, I could also write in C++. MSVC could drop C support altogether and I wouldn't even notice. MSVC is most certainly catching up in regards to standards support - the only things I still have wanting of in VC are const_expr and variadic templates. I don't really care that GCC is 10% the size of VC -- is this the mid-90s and hard drive space matters? I don't care that GCC supports all output formats - my toolchain can parse and work with PE binaries directly. I don't care that GCC works everywhere, because my primary system is Windows. I don't care that GCC works for everywhere, because anywhere I'm going to build for, VC can also build for (x86, x86-64, PPC, ARM).
Your rant is pointless because it is based on
your desires. Fine, VC isn't appropriate for
you. That doesn't mean that it isn't appropriate for everyone else, too.
