Is anyone using ML.EXE 7.10 ?

[hutch--]

I need to know if anyone is using ML.EXE version 7.10 as I need to get some testing done to check how compatible it is with 7.00, 6.15 and 6.14. If you are using this version would you give me a yell ?

[ToutEnMasm]

I have 7.10.3077,6.15 and 8.00.50215.44 (beta2.050215-4400).
I use only 6.15 for legal used.Others are for test.

7.1 made an error with option "verify only"
^{minus.asm(164) : fatal error A1018: COFF error writing file : NUL
CoffERROR f:\vs70builds\3077\vc\masm\ml\coffemit.c 870}

It's only a warning error,works is good

8.00 make an error with windows.inc
^{\masm32\include\windows.inc(17573) : error A2138: invalid data initializer}

the line is    "rImport ImportRec <>" in the "IMPORT_OBJECT_HEADER STRUCT"
and "ImportRec RECORD Reserved : 11,NameType : 3,Type2 : 2"

                         ToutEnMasm

[gfalen]

I use it exclusively.  It fixes several bugs from 6.xx.

[GregL]

I am using ML 7.10. I am pretty busy right now, so I may not be the best person for getting the testing done in a speedy manner. I would be glad to help out any way that I can though.

[hutch--]

From what I can tell so far 7.10 has the same defect as 7.0 from the XP DDK, the command line support is broken on *.asm and you must use a response file to build multiple modules into a library. &.10 is identical in size to 7.00 but it has an extra option for safe SEH but I don't know how useful that is for general purpose assembler programming.

At the going rate the older ml 6.15 looks a better prospect as it has SSE2 support, can use the SSE3 macro file from Intel and is as reliable as te older 6.14.

[gfalen]

Versions before 7.10 return incorrect TYPE values for byte size registers .

= 00000000             T= type al
= 00000000             T= type bl
= 70756473             T= type cl
= 053D0000             T= type dl

7.10 fixes this.

[hutch--]

Thanks Greg,

I knew the older versions were broken in the TYPE statement and ended up with macros that determined many more things.

[GregL]

Hutch,

I tried to run ML 7.10 with *.asm and got the error "MASM : fatal error A1000: cannot open file : *.asm", so it looks like that behavior is still there.


[edited]

Some things I have noticed using both ML 6.15 and 7.10 (I don't have 7.00 set up):

ML 7.10 defaults to the COFF object file format instead of the OMF format. The /omf switch was added with ML 6.15, but 6.15 still defaults to OMF. ML 7.10 still accepts the /coff switch so it doesn't break any makefiles or batch files when assembling Win32 programs. If someone wanted an OMF object file they would need to add the new /omf switch to makefiles and batch files.

ML 7.10 uses a different debug information format than 6.15. If you assemble with ML 7.10 with /Zi and link with LINK 6.00 with /DEBUG you get this error:

    fatal error LNK1103: debugging information corrupt; recompile module"

If you assemble with ML 6.15 with /Zi and link with LINK 7.10 with /DEBUG it's OK, there is no error.

[/edited]

[GregL]

I edited the post above after doing some more testing.

[Human]

i started to use 7.0
because 6.14 6.15 compiled my trainer with 1.5mb include in 20s, 7.0 in 4s, still its slow like hell to tasm less than 1s and nasm, seems microsoft never will fix include in db format or creating big tables with dup (?)  that can be put into data?
funny that in new w2k3 ddk there is only ml64 for 64bit intel and amd, and they dont work with masm includes, well amd64 has register based winapi not stack, so also my question will masm be rewritten to support amd64 or only way is fasm?

[hutch--]

There is already a 64 bit version of MASM, ML64 but its so far only in the vc2005 release. There is no chance of using the 32 bit include files and the calling convention is basically a 4 register version of FASTCALL which is technically different to the STDCALL used in win32. So far I understand there is 64 bit NASM, YASM, FASM and MASM. I gather there is a 64 bit version of GAS up and going in LINUX.

[bushpilot]

So far I understand there is 64 bit NASM, YASM, FASM and MASM. I gather there is a 64 bit version of GAS up and going in LINUX.

... and of course GoAsm is 64bit, as are GoRC and GoLink.

Greg

[Human]

hutch seems you dont understand me. my question was masm as like masm32 package with includes libs etc in 64bit, not masm 64 as ml64.exe that i had from w2k3 ddk, i mean does you masm project will be converted to 64bit or maybe already is?
soon we all will move to 64bit, 32bit is dead. and i have enough learning how to use another assembler, tasm,nasm,masm i think is enough.

[Ghirai]

soon we all will move to 64bit, 32bit is dead.

32bit arhitecture is a long way from dead...

[hutch--]

Yes,

I agree with this comment, there is no reason to assume that the current 64 bit x86 format will succeed. DOS to Windows 16 to 32 bit was driven by necessity as DOS was an anchor around the neck of application development but we are a long way from having exhausted the 2 gig application limit as it is genuinely hard to build an application that large.

Addressing range for very large databases and some unusual applications in image data processing can use the 64 bit addressing range but little else will take advantage from this and then you have all of the disadvantages like the most common data size being twice as large which effectively slows most things by half. Until we have the next generation of hardware with enough memory and processing power, much of 64 bit computing will be larger and slower than current 32 bit.