Functions were deprecated primarily for two reasons:
1) Known insecurities. Obvious reason to deprecate. If you don't feel like changing these, define the following directive:
#define _CRT_SECURE_NO_DEPRECATE
Obvious reason to deprecate? Defining another macro to make this specific compiler behave and stop throwing things it'sn't supposed to?
The reason to deprecate something in a compiler is because the standard says so. C99 and C++98 haven't deprecated that, it's plain wrong for a compiler to start adding deprecations here and there because they want to.
If they just showed a warning suggesting the use of another STANDARD function or read why you should use those functions carefully, that'd be fine, but no, they don't. An example of this is using
gets with gcc under Linux. gets hasn't been deprecated, but should be used with care or replaced with a call to fgets or anything else, but just because it's "insecure" doesn't give "obvious reasons" to the compiler to call it deprecated.
And then what? Will MS just remove those functions in the next release because were deprecated in the current version?
But anyway, if you can find something useful in the whole process of modifying the sources to make them compile with that compiler and not just having that compiler telling lies, that'd be good.