Call ml v.7.10.3077 "ml -c Fot_mas.obj t.asm" generate COFF output, but call
"jwasm -c Fot_mas.obj t.asm" generate OMF output. I think that kind of generation by default should depend on the OS:
Win - coff
Unix - elf
Dos - omf
I agree that JWASM.EXE should generate COFF object files by default. MASM has defaulted to COFF since v7 and there is no reason why a WIN32 assembler should not generate the WIN32 native format by default. JWASMD should continue to default to OMF since that is the format for DOS object files and the last DOS version of MASM (6.11d) also defaulted to OMF.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you please address this in v2.10 ? JWASM.EXE really should generate COFF by default just like all versions of MASM since v7. JWASMD.EXE and JWASMR.EXE should continue to generate OMF by default.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It depends on the Masm version. Default format for Masm v5 and v6 is OMF, but since v7, it is COFF.
> I think that kind of generation by default should depend on the OS:
I don't like this idea.
I agree that JWASM.EXE should generate COFF object files by default. MASM has defaulted to COFF since v7 and there is no reason why a WIN32 assembler should not generate the WIN32 native format by default. JWASMD should continue to default to OMF since that is the format for DOS object files and the last DOS version of MASM (6.11d) also defaulted to OMF.
Could you please address this in v2.10 ? JWASM.EXE really should generate COFF by default just like all versions of MASM since v7. JWASMD.EXE and JWASMR.EXE should continue to generate OMF by default.
> Could you please address this in v2.10 ?
That's too much work - I'd have to check all my assembly projects if they ( silently ) assume that OMF is written.
Ticket moved from /p/jwasm/bugs/126/