> See our first call to 'syscalls.40201B', it's jumping past our first string. A call normally knows how to return to where we came from by pushing the address of the next instruction to the stack. In this case though, our program doesn't intend to return to this at all, it is using that pushed address as a side effect, as that address really is the first byte of our string, it serves as a pointer to it, and it is now on the stack conveniently as an argument.<p>Nasty. I love it.<p>What is the rationale for doing this, rather than putting the strings in the rodata section or whatever they have in PE files, and pushing addresses as immediates?<p>Do the strings end up in the instruction cache? They are never interpreted as instructions, but they will be on the same cache lines as real instructions.
This sounds like a pretty weird thing to complain about (especially coming from the reversing direction).<p>Is the problem merely that they don't like how the strings are inlined in the code section? (Where else would you put it? Automagically putting them in the data section would also be non-obvious). Or is the problem that they think invoke should error out if the parameter is not an integral type that can be a directly pushed? Or is the problem with macro assemblers and high-level features in general?<p>The reason for such a macro is because it makes calling Windows functions more similar to how they are documented. I think it's still possible to use an assembler yet want such a macro for common uses (like calling Windows functions).