This information has been posted throughout the forum but i'm putting it here to help newcomers find it, and to save others a lot of time. Masm 9.00.30729.01 fixes some old long overdue bugs.
1)Download and install Masm32 (http://www.masm32.com/masmdl.htm)
2)Download and install Microsoft Visual C++ 2008 Redistributable Package(few megabytes in size, http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en)
3) Download ml.exe verison 9.00.30729.01 from http://d01.megashares.com/?d01=2552924 (or take from the gig+ visual studio 2008 sdk)
then replace the ml in your C:\masm32\bin dir with the new one
4) Now you're good to go!(tested on fresh install of XP SP 2 and Vista Home)
I didn't include the new link because its annoying and lacks features the old which still works fine has, if you want to install the new link you'll need mspdb80.dll for it to work aswell.
Thanks for info,
I have tested it and all isn't so good.
I used it in the \Program Files\Microsoft Visual Studio 9.0\VC\bin directory
and I keep the version 6.15 ( very stable from Iczelion site) in the masm32\bin directory
what's not good about it? i've recompilled all the big projects i've written in masm(megabytes of source code, and megabytes in output size) and it seems to compile everything fine. Plus it fixes some old bugs, that some people including myself were unaware of, like the invoke bug.
He can generate internal errors with some headers. 6.15 make it.
I have quickly verified,the invoke bug isn't corrected.
Quote
Microsoft (R) Macro Assembler Version 9.00.30729.01 03/26/09 17:57:26
bug.asm Page 1 - 1 mov bl, 123
.LISTALL
00000041 A0 00000000 R * mov al, ab
00000046 50 * push eax
00000047 E8 0000003C * call test1
0000004C 0F B6 C0 invoke test1, ab
movzx eax, al
http://www.masm32.com/board/index.php?topic=11102.0 dizz says it is, and his listing show it is...herm idk
e^cube wrote
QuoteThis information has been posted throughout the forum but i'm putting it here to help newcomers find it, and to save others a lot of time. Masm 9.00.30729.01 fixes some old long overdue bugs.
thanks for the info !!
Quote
dizz says it is, and his listing show it is...herm idk
Perhaps he say it is corrected but he is wrong.
The bug is:
Quote
When masm push a byte in the stack , he need to translate it before to a dword.
He used different methods for that,in this case
invoke test1, ab ;ab is a byte in data
;------------- here what he do to perform this -------------------
00000041 A0 00000000 R * mov al, ab
00000046 50 * push eax
00000047 E8 0000003C * call test1
;--------------------------------------------------------------------------------------
he put ab in al,eax is modified
usually he just push the data and there is no register modify (32 bits data)
As an addition to E^cube's explanation, I recommend using Polink.exe instead of link.exe It has no extra dependencies and creates smaller executables.
Erol, it sounds like you have tested this. I do not remember -- does the v9.x linker create a dependency to mspdb80.dll or the latest CRT? I tinkered with it once, but might have dropped it for this reason. Not only was this dependency an issue, but the executable was about 20% larger than the one made with the original link, and 30% larger than if it were made with polink.
Where are those additional dependencies? I checked the attached code with Olly but found only Kernel32...
include \masm32\include\masm32rt.inc
.code
start: exit
end start
[attachment deleted by admin]
Actually, the mspdb80.dll dependancy is for running link.exe itself.
Quote from: Greg on March 28, 2009, 10:33:34 PM
Actually, the mspdb80.dll dependancy is for running link.exe itself.
Exactly :bg
File sizes for RichMasm (http://www.masm32.com/board/index.php?topic=9044.msg73814#msg73814):
1. with Polink: 58880 bytes
2. with link 5.12: 59392 bytes (+512 bytes = +0.87%)
3. with link 9.00: 59392 bytes (+512 bytes = +0.87%)
Actually link.exe only imports a few functions from mspdb80.dll, polink has user32 and kernel32 as dependencies, does that increase the size of the final executable ?? You would think that the people here would at least understand importing functions from a DLL ::). 512 bytes is a section, it could easily be due to internal data alignment, and I'll bet my bottom dollar that if the alignment is different between polink and link that polink is wrong but the error is fixed up on load or is insignificant. To make a case you would have to prove that first the 512 bytes is consistently added and what it is for and also whether polink has omitted something in the PE specification that accounts for the 512 bytes or Microsoft has unnecessarily expanded a section. Just to say "this file is 512 bytes larger" means absolutely nothing, I can adjust section sizes and "hope" that my PE will run on all versions of Windows including future ones and say that I have reduced the executable size but in reality I have just played some tricks with sections. Also, my machine has 2GB of memory available to applications, I think that 512 bytes is insignificant in itself. My smallest (current) assembly application is around 75KB and my largest is around 3.5MB at best I would not even notice 512 bytes and I certainly wouldn't waste a nanosecond trying to save it (which is probably the difference in load times). Yet another pointless debate that seems to plague assembly language forums.
Edgar
The search for the smallest code, the fastest code and the smallest executable, these are common mental illnesses among us :green
Quote from: mitchi on March 29, 2009, 04:02:38 AM
The search for the smallest code, the fastest code and the smallest executable, these are common mental illnesses among us :green
Nope, the search for a pointless optimization that might save 10 seconds over the entire lifespan of the program but takes 6 hours to implement, not one of my mental illnesses, though I have many others.
:bg
And the secret is ".rloc" as to why POLINK saves 512 bytes on an EXE file. ML.EXE uses the later DLL mainly to ensure it will not run on a standard earlier OS version, Microsoft have done this for years. A linker is a linker is a linker, basically it plonks the appropriate startup code at the front of the executable code, with PE files it structures the sections complete with the required alignment and positions the entry point.
Having used POLINK for years it is up to date specification wise and is generally MORE UP TO DATE than Microsoft link.
OK, I should be more precise to explain some facts. jj2007's example has nothing wrong and we know all about some fundemental principals of the PE specification. To be honest, an application running on a 32-bit OS will allocate a minimum of 4096 bytes in memory. Prefering Polink means that your application will not contain those junk bytes inserted by link.exe. Finally, the size difference is a result depending on how you interpret the PE specification. As Hutch stated Polink reflects a more precise usage of the specification. Personaly, I am not a fanatic of squeezing PE sections to get the minimal size : My tools on my website are not built with the /SECTION directive to merge sections and I don't use EXE compressors.
If someone decides to create his own llinker, that would probably be something similar to Polink in terms of dealing with the PE specification as there is no reason to insert unnecessary bytes to the executable built with the linker.
Mark, here is an exmple :
A typical application like Iczelion's tutorial #3, ( the blank window example ) has a size of 1536 bytes when linked with Polink ( link.exe -> 2560 bytes )
Quote from: Vortex on March 29, 2009, 09:08:54 AM
OK, I should be more precise to explain some facts. jj2007's example has nothing wrong
Erol, thanks for the detailed clarification. There is a rumour that the new versions of link increases executable sizes and/or introduces "dependencies", but until now I have not seen any concrete examples - that's what I wanted to show. As to polink, it does produces somewhat smaller executables, but it is a matter of taste whether one accepts the 512 extra bytes or not :bg
Attached a screenshot comparing the sections created by polink and link. File sizes are 58880 and 59392
[attachment deleted by admin]
I understand what you mean. No any problem. Probably, there was a rumour.
Jochen, thanks for the Peview analysis. It's one of the most powerful tools to study PEs and MS COFF object files.
Quote from: Vortex on March 29, 2009, 09:08:54 AM
A typical application like Iczelion's tutorial #3, ( the blank window example ) has a size of 1536 bytes when linked with Polink ( link.exe -> 2560 bytes )
Yes, this was very similar to my experience. On the particular piece of code I tested, there was a significant difference in size, and if the code is small like in this example, then the difference appears larger. This is why I gave a
percentage estimate for a figure, because this was my observation with that particular executable. No lengthy trials were performed, nor did I say that I had conducted any lengthy trials...
I knew the reason why POLINK achieves smaller executables. But also consider that even though the "hardcore" programmers here make multi-megabyte executables in assembler, the majority of pure-assembler binaries are likely very small. Thus, the 512 bytes saved here and there amounts to a
significant percentage of the (typical) executable size. In a 2MB binary, who cares about a few KB? That would be much better helped by an executable compressor like PECompact. But in a 5kB executable, 1kB is 20%. This just
seems more important, because it is a larger percentage.
Alas, as Donkey says, spending hours of extra time to save a few bytes does not seem like a worthwhile investment. This is why I only observed this in passing -- spending any more time on it was pointless. (However, on the pedantic flip-side, if all executable code were created in assembler and as small as possible, how many Peta-Bytes of internet bandwidth would be freed monthly? How many Exo-Bytes of hard disk space would be freed?)
I gave up on the newer versions of ML and LINK when using AVG anti-virus. AVG was marking all MASM code as being infected (is it still?), so on a whim, I reassembled the code using the newest versions of ML and LINK at the time, and presto, AVG did not detect anything from that new executable. However, the executable was larger than the original, and I seem to recall it had a dependency on the latest CRT, or maybe the .PDB file as described previously. But this was some time ago, and my memory isn't the greatest.
People,
POLink : creates smaller executables because it puts Import Directory in .data
MSLink : use /MERGE:.data=.rdata command
POLink : creates smaller executables because it defaults to 512 section alignment
MSLink : use /FILEALIGN:512 command
now stop the silly POLink vs MSLink debate.
Quote from: ToutEnMasm on March 26, 2009, 06:01:46 PMQuote
dizz says it is, and his listing show it is...herm idk
Perhaps he say it is corrected but he is wrong.
The bug is:
Quote
When masm push a byte in the stack , he need to translate it before to a dword.
He used different methods for that,in this case
invoke test1, ab ;ab is a byte in data
;------------- here what he do to perform this -------------------
00000041 A0 00000000 R * mov al, ab
00000046 50 * push eax
00000047 E8 0000003C * call test1
;--------------------------------------------------------------------------------------
he put ab in al,eax is modified
usually he just push the data and there is no register modify (32 bits data)
What are you talking about?!???! What does your listing show?!
Quote from: ToutEnMasm on March 26, 2009, 06:01:46 PM
Quote
dizz says it is, and his listing show it is...herm idk
Perhaps he say it is corrected but he is wrong.
The bug is:
Quote
When masm push a byte in the stack , he need to translate it before to a dword.
He used different methods for that,in this case
invoke test1, ab ;ab is a byte in data
;------------- here what he do to perform this -------------------
00000041 A0 00000000 R * mov al, ab
00000046 50 * push eax
00000047 E8 0000003C * call test1
;--------------------------------------------------------------------------------------
he put ab in al,eax is modified
usually he just push the data and there is no register modify (32 bits data)
How do you expect to push a BYTE value onto the stack in 32 bit programming ? There is no such thing as PUSHB in 32 bit mode but if there was it would be exactly as above. Since the rest of EAX is of no importance it is undefined after the "PUSHB". I do not see this a bug at all, it is simply a way to execute a request that makes no sense in 32 bit programming with a quick fix. SO if you don't want EAX modified, (even though it is considered volatile) then don't try to perform task that are unsupported by the platform you are programming in.
Remember that in 32 bit mode you can only ever PUSH a DWORD, this is determined by the address-size attribute and nothing that any assembler can do, everything else is a fix up by the assembler to cover the asses of programmers who don't know this or choose not to follow the rules of the IA32 architecture. The only BUG here is that MASM lets you push a BYTE at all, it should throw an invalid operand error for the programmer who obviously doesn't understand the stack, or perhaps display a link to the Intel web site to complain that though you're using a 32 bit processor you still want to use 8 bit operands.
Edgar
Hi Mark,
Yes, Donkey is right with his statement pointing that doing extra researches to perform some minor optimizations in large executables has no any practical value. That's true.
Me too, I have the same false positive problem with an AV software. Mark, you have other options :
a) Assemble the source code with the latest version of ml.exe
b) Instead of the newer version of link.exe, try to use Open Watcom's Wlink, Jeremy's GoLink or Pelle's Polink. There also Alink (http://alink.sourceforge.net) but it's an outdated product.
Quoteif all executable code were created in assembler
This should be the idea. For us the assembly coders, what's is difficult is not finding an algorithm simple or complicated but focussing our attention to create clean, easily understable and readable code. Using only assembly language to create applications should be mainly based on writing readable and maintainable code. It's easy to gain bad habits in programming but it takes a lot of efforts to learn how to write readable code. Careful indentation, casing standards, easily understable variables, good documentation and moving code portions to procedures are the elements of properly written code. Sometimes, I find myself struggling with my own code to understand what I was trying to do. I think we should create to a sticky topic about writing clean assembly code.
Quote from: drizz on March 29, 2009, 04:31:51 PM
People,
POLink : creates smaller executables because it puts Import Directory in .data
MSLink : use /MERGE:.data=.rdata command
POLink : creates smaller executables because it defaults to 512 section alignment
MSLink : use /FILEALIGN:512 command
drizz,
No change of file size with your options. Stuck at 58880 for polink, 59392 for ms link, both old and newest version.
Quote
now stop the silly POLink vs MSLink debate.
There are no silly debates in this forum, except for the Colosseum and the Soap Box. We raised the question whether the newest version of MS link creates dependencies and increases file size substantially. That is an entirely sober and valid question for assembly programming. If you can bring solid evidence, everybody will be grateful.
Maybe you are thinking of the dependencies the Visual C++ 2003, 2005 and 2008 compilers produce.
http://www.masm32.com/board/index.php?topic=9803.msg71774#msg71774
Also, with just MASM, if you link to the Visual C++ 2003, 2005 and 2008 versions of msvcrt.lib you will get these dependencies too. If you link to the MASM32 version of msvcrt.lib you won't get them.
Dependency Walker (http://www.dependencywalker.com/) is great for viewing dependencies.
QuoteMSLink : use /MERGE:.data=.rdata command
MSLink : use /FILEALIGN:512 command
I can't get those to work. They get (silently) ignored ? Using MS linker 9.00.21022.08 , will try others, too.
I compare the resulting executables and the only difference is the timestamp :eek
Hi drizz,
MSLink : use /MERGE:.data=.rdata command
You should be careful with the MERGE switch as it can lead you to a problem with section attributes :
LINK : warning LNK4254: section '.data' (C0000040) merged into '.rdata' (4000004
0) with different attributes
The linker shipped with VS 2008 Express Edition Sp1 ( V9.00.30729.01 ) creates the executable but the PE will crash.
This one works :
link /SUBSYSTEM:WINDOWS /FILEALIGN:512 /MERGE:.data=.rdata /SECTION:.rdata,RW Win.obj
To avoid any misunderstandings, none of us we intend to begin a Polink vs MS link debate.
Quote from: Vortex on March 29, 2009, 07:22:04 PM
This one works :
link /SUBSYSTEM:WINDOWS /FILEALIGN:512 /MERGE:.data=.rdata /SECTION:.rdata,RW Win.obj
Well, kind of - it doesn't crash, but in my specific case it increases file size by a 1000% :boohoo:
Apparently, it doesn't like this construct:
.data?
align 4
lbl LABEL byte
ORG $+BufLen-1
db ?
.data? becomes part of the .data initialised section...
Quote from: BlackVortex on March 29, 2009, 06:39:42 PM
QuoteMSLink : use /MERGE:.data=.rdata command
MSLink : use /FILEALIGN:512 command
I can't get those to work. They get (silently) ignored ? Using MS linker 9.00.21022.08 , will try others, too.
I compare the resulting executables and the only difference is the timestamp :eek
I only meant /MERGE as an example, i wrote the commands by heart, should be
>/MERGE:.rdata=.data< or better >
/MERGE:.rdata=.text<
and for the size squeezers:
/FILEALIGN:512 /MERGE:.rdata=.text /MERGE:.rsrc=.text /MERGE:.data=.text /MERGE:.bss=.text /SECTION:.text,RWE
oh btw FILEALIGN is an undocumented switch but should works with all link versions. Check the resulting PE with LordPE.
Just tested (properly this time) and drizz is correct as always.
Also, more on-topic, can someone please upload somewhere latest MS link.exe and link.exe.config ? I have Visual Studio 9.0 but my version is earlier, it reports 9.00.21022.08.
(or PM)
Quote from: drizz on March 29, 2009, 09:14:01 PM
oh btw FILEALIGN is an undocumented switch but should works with all link versions. Check the resulting PE with LordPE.
The switch works but does not produce smaller executables because its default is already 512 bytes. Try putting /FILEALIGN:1024...
The other switches work partially but do not seem to be able to produce the same size as polink with default switches.
Testbed attached.
And,
no, I don't want to start a link vs polink debate, but I am curious to know what is fact and what is fiction.
[attachment deleted by admin]
I confirm jj's findings. Polink is more efficient. I just wish the windows loader would accept a file alignment of 256, or a switch to omit the DOS header and stub. Just for kicks :green2
I forgot something :) I have my link patched not to produce "Rich Signature"
I can also run latest ml without manifests and winsxs dependency but those are topics for some other forum :)