I've run into this issue twice now (in different forms) after upgrading build systems from old versions of Nmake to Nmake 8.0 (the version from Visual Studio 2005), so I think that means it's time to blog about it.
Scenario 1:
Your stuff builds ok, but the output is totally wrong. Characters are missing from the output, and during the build, your computer keeps beeping at you.
Compiling .._koho.c ..\gaimem.c ..\k_area.c ..\k_clearn.c ..\k_grbg.c ..\k_hnkn.c
..\k_moji.c ..\k_regist.c . evconv.c ..♂lbmgr.c ..nvdbg.c ..\k_frame.c
..\k_kenti.c ..\k_disp.c ..\k_atwid.c ..\k_crsr.c ..\k_kkti.c .. ngmgr.c
..\k_koho.c ..\k_bun mk.c ..comment.c ..utotune.c ..
Investigating, you find that all of the missing characters are C-style escape sequences - "\a", "\r", "\n", etc., and the escape sequences have been replaced by the corresponding control code - beep, CR, LF, etc. So why did nmake suddenly decide to start processing escape codes?
Scenario 2:
The following is something of an idiom for makefiles. It shows the command line that is about to be executed, then executes it. (This is a bit of a simplification. As presented, this serves no purpose, but the pattern becomes useful when inline response files are involved.)
.cpp.obj:
@type <<
$(CL_COMMAND_LINE)
<<NOKEEP
$(CL_COMMAND_LINE)
After upgrading to Nmake 8.0, this starts causing an error. Type complains that it can't find the temporary inline file. Replacing "type" with "cmd /c type" fixes the problem.
Both issues have essentially the same root cause. Tune in next time for the solution.