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 ?
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
I use it exclusively. It fixes several bugs from 6.xx.
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.
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.
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.
Thanks Greg,
I knew the older versions were broken in the TYPE statement and ended up with macros that determined many more things.
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]
I edited the post above after doing some more testing.
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?
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.
QuoteSo 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
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.
Quote from: Human on December 11, 2005, 05:49:02 AM
soon we all will move to 64bit, 32bit is dead.
32bit arhitecture is a long way from dead...
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.
Quote from: Human32bit is dead
In your 4th post, you are claiming that 32 bit is dead? Quite interesting...
well it was as soon, i cant agree that 64bit will not soon takeover. why then we use everywhere where needed mmx,sse,sse2, compression,decompression of video,music, games they will push all to 64bit soon, even now i cant speed up my decompressor because my athlon doesnt have sse2 and we cant do compare of mmx regs and use je or jne without playing with code due only sse2 has instructions that modify flags directly, jpg decompressor refills data bucket with 16bit if we already have 15 bit and max is 32, with 64 we can refill with 48bit so 3x less updating,rol,and, etc. well we dont need 64bit for normal programs that dont require fast data processing but it will change over 1 or 2 years, when only 64bit cpu will be there. even microsoft droped 32bit support for vista. so only way will be xp x64 or drm'ware vista
I remember the time,when other HUMANS talk about the 32 vs 16 bit environment the exact way. But the domination of first one takes about 10 years :P