#265 option -Zf incompatibility with MASM

[MazeGen]

When the code is assembled with "ml.exe -Zf" (version 10.00.40219.01), coff symbol table contains "haloed" symbol of IMAGE_SYM_CLASS_LABEL class, while "jwasm -coff -Zf" (v2.10) assembles it to "_haloed" symbol of IMAGE_SYM_CLASS_EXTERNAL class:

.686
.model flat, stdcall
.code
haloed:
nop
END

---

Similar incompatibility shows the following code. With jwasm it is again "_haloed" with EXTERNAL class, masm generates "haloed" with STATIC class:

.686
.model flat, stdcall
.data
haloed label byte
nop
END

ML 11.00.50727.1 behaves the same in both cases as ML 10.00.40219.01.

---

There is also a case when jwasm generates public symbol without leading underscore "_" (instead of STATIC or LABEL class with the same symbol name) but I couldn't replicate it right now.

[japheth]

I agree that what jwasm does is not what masm does.

However, the -Zf switch is supposed to "make all symbols public".
Obviously, masm does NOT make all symbols public - at least with -coff;
but, if you assemble your code with Masm using -Zf and for output format OMF,
then both labels and data items actually DO become public.

IOW: this behavior of masm might actually be a bug, and what jwasm does seems to be more what's to be expected.

[MazeGen]

IMO, masm behaviour with COFF and Zf has the advantage of keeping the original symbol's class. This helps, for example, to recognize symbols that have been explicitly made public and those "exported" by the Zf option. This is important in case of local macro symbols ("??0000") - it doesn't make much sense to make them public.

As for the OMF/COFF difference, who knows, it might be because they want different behavior for COFF and keep it the same for OMF (that is obsolete for years AFAIK). And nobody bothered to change the Zf option description.