output: codeview -- change version number written
commit713fd1ffc82344f58a4ef94506a62c8e32704a2f
authorFabian Giesen <fabiang@radgametools.com>
Fri, 20 Apr 2018 08:26:56 +0000 (20 11:26 +0300)
committerCyrill Gorcunov <gorcunov@gmail.com>
Fri, 20 Apr 2018 08:27:19 +0000 (20 11:27 +0300)
tree56f0f0a13917622b46afc2a9a128d1a17220ca62
parentdd6a2cdcf4a4bbd2c64fe0dbdcd3e0a2c8d63032
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>
output/codeview.c