I suppose they want to support Windows code which was intended to be compiled only with specific versions of Microsoft compiler and uses such #ifdefs, or to support the Microsoft header files which are inherited by ICL. Surely, it's not intended for use in writing code.
I'm curious as to which version of the compiler you are using. An _MSC_VER of 1200 refers to Visual Studio 6 circa 1998. If I recall correctly, I thinkour Intel C++ Compiler for Windows (IA32)version 6 and maybe 7.1 had an _MSC_VER of 1200.I believe 8.0 is 1300 or 1310 (unfortunately don't have 8.0 installed on my system).
In any event, the reason we define this macro is very much in line with what Tim stated. For us to be as interoperable with the MS compiler as possible, it is important that we take the same paths through people's code as the version of the MS we are claiming compatibility with. Here's the motiviation based upon what the team has seenin the past:
-Customercode starts off being platform/compiler agnostic.
-Windows becomes the customer predominant or only OS the application runs on.
-Customer code becomesdependant on _MSC_VER and since the code only runs on Windows, no testing is done with _MSC_VER set to something else.
-Intel C++ Compiler compiles the application (with no _MSC_VER) and shows a compile time/runtime problem due to really no fault of its own. Still the customer perceives the problem is with the compiler.
Iapologize for the length post. Joe Goodman wrote an excellent article on Compiler Interoperability in a recent Dr. Dobbs.the article has more details.
Hope this explains it. Let me know if you have questions.
The value of _MSC_VER depends on command line option, for details see documentation about /Qvc6, /Qvc7 and /Qvc7.1.
/Qvc6 (_MSC_VER == 1200) is default option if it isnt redefined in %Program Files%IntelCPPCompiler80Ia32Binicl.cfg (real path depends on your choice during installation).