output: codeview -- change version number written

Windows Store and Xbox One apps need to pass WACK, the Windows App
Certification Kit, and part of that process involves a tool named
BinScope that checks the debug info of all object files making up
the final executable against a list of minimum versions.

These minimum versions get increased periodically as new SDKs and
compilers are released. In a patch 2 years ago, I made NASM
pretend it was MASM and output a then-current MASM version number.

Well, the minimum version number has increased again, and
periodically hardcoding a new random MASM version to keep BinScope
happy doesn't seem like the way to go.

It turns out that BinScope does not impose any minimum version
requirements on object files listing a source language BinScope
doesn't know about.

I have no idea how to officially request a new CodeView language
ID (or whether there even is a way to do so for someone outside
MS). But experimentally, using 'N' (0x4e) for NASM seems to be
working just fine and is far away from the range of currently
allocated language IDs (which stop at 0x10).

Long story short, make NASM emit a source language ID of 0x4e,
with the actual NASM version in the version number fields.
BinScope is happy to accept that, and since the language ID field
is purely an informational field in an optional debug info record
that (as far as I can tell) is not used for anything else, this
seems reasonably safe and unlikely to cause trouble.

Signed-off-by: Fabian Giesen <fabiang@radgametools.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>

1 files changed, 16 insertions, 4 deletions

diff --git a/output/codeview.c b/output/codeview.c
index c8a90e91..15561793 100644
--- a/output/codeview.c
+++ b/output/codeview.c
@@ -635,9 +635,21 @@ static uint16_t write_symbolinfo_properties(struct coff_Section *sect,
 
     creator_len = 2 + 4 + 2 + 3*2 + 3*2 + strlen(creator_str)+1 + 2;
 
+    /*
+     * We used to use a language ID of 3 for "MASM", since it's closest of the
+     * options available; however, BinScope from WACK (the Windows Application
+     * Certification Kit) tests for specific minimum MASM versions and trying to
+     * match an increasing sequence of random MASM version/build numbers seems
+     * like a fool's errand.
+     *
+     * Instead, use a different language ID (NASM is, after all, not MASM
+     * syntax) and just write the actual NASM version number. BinScope appears
+     * to be happy with that.
+     */
+
     section_write16(sect, creator_len);
     section_write16(sect, 0x1116);
-    section_write32(sect, 3); /* language/flags */
+    section_write32(sect, 'N'); /* language: 'N' (0x4e) for "NASM"; flags are 0 */
     if (win64)
         section_write16(sect, 0x00D0); /* machine */
     else if (win32)
@@ -649,9 +661,9 @@ static uint16_t write_symbolinfo_properties(struct coff_Section *sect,
     section_write16(sect, 0); /* verFEBuild */
 
     /* BinScope/WACK insist on version >= 8.0.50727 */
-    section_write16(sect, 8); /* verMajor */
-    section_write16(sect, 0); /* verMinor */
-    section_write16(sect, 50727); /* verBuild */
+    section_write16(sect, NASM_MAJOR_VER); /* verMajor */
+    section_write16(sect, NASM_MINOR_VER); /* verMinor */
+    section_write16(sect, NASM_SUBMINOR_VER*100 + NASM_PATCHLEVEL_VER); /* verBuild */
 
     section_wbytes(sect, creator_str, strlen(creator_str)+1); /* verSt */
     /*