I've found myself a nice sweet spot - Windows Driver Kit (WDK) - it ships with Compiler (MSC 15.0) that can target MSVCRT.DLL
It's unusual to use something like the WDK for Desktop Apps, but it works.
The compiler is a bit outdated, and there is need for some trickery to get stl7 (internal naming) to work, but if something is missing you can install latest WSDK with it and reuse missing libs/headers from there (platform sdk)
At work I do use VS2010 with .sln/.vcxproj, but for my projects I just stay away from this - either makefiles, shell scripts, or some other tool, but not .sln/.vcxproj
Then again, I don't do much UI stuff, and If I do - I do it in code.
Debugging is there (but a bit harder, then again much more powerful) with WinDBG. There is also OllyDBG.
So WDK + SDK (missing pieces) and I'm set. And since I avoid heavy C++ projects, prefer to stick to C it's not problem for me. Occasionally I have to fix simple problems, like variable not declared at the top of the block, which never "C" compilers are okay, but MSC 15.0 is not (the one from WDK 7.1)
It's unusual to use something like the WDK for Desktop Apps, but it works.
The compiler is a bit outdated, and there is need for some trickery to get stl7 (internal naming) to work, but if something is missing you can install latest WSDK with it and reuse missing libs/headers from there (platform sdk)
At work I do use VS2010 with .sln/.vcxproj, but for my projects I just stay away from this - either makefiles, shell scripts, or some other tool, but not .sln/.vcxproj
Then again, I don't do much UI stuff, and If I do - I do it in code.
Debugging is there (but a bit harder, then again much more powerful) with WinDBG. There is also OllyDBG.
So WDK + SDK (missing pieces) and I'm set. And since I avoid heavy C++ projects, prefer to stick to C it's not problem for me. Occasionally I have to fix simple problems, like variable not declared at the top of the block, which never "C" compilers are okay, but MSC 15.0 is not (the one from WDK 7.1)