Returning to Win asm after many years

[Spec-Chum]

Hey all, I'm sure no one will remember me but I was a member of the old masm forum in about 2010 - I didn't post much, but great to see some familiar names lol

Anyway something, not sure what, rekindled my interest in asm and I heard about UASM so thought I'd try it, mainly as I wanted to try my hand at win64 asm.

I have a couple of questions, if I may.

• What advantages/disadvantages does UASM have over the other one I've seen, ASMC?  Subjective, I know, sorry
• option: win64:n - I've pretty much figured out what options 1 to 7 do, but what does 8 do?  It says "takes care of everything", which I assumed meant it set the others as it saw fit, but the recommended setting is 11 - which includes 8
• Is there any benefit from using the latest MS link.exe from Visual Studio 2017 over wlink?
• What does RV do?  "Insert return value into EAX or RAX in a nested INVOKE call"  Eh? lol

On a side note, great work on MASM64 Hutch, I've read some of the things missing from ml64.exe, you've done a great job, it looks like.

Thank you :)

[Spec-Chum]

OK, I was naive about MASM64 it seems, just been reading more of the forum.

It's not missing anything, it's just gone back to being an assembler instead of a Cassembler lol

Sorry hutch.

Both have their uses tho, and I do like UASM too.

[zedd151]

Welcome to the forum? Er, uh.. welcome back??

Hey, how ya doin?

8)

[hutch--]

No need to apologise, just remember that what you see is what you get, MASM64 is up, working and application ready with its own library and macro system, already has working examples, templates and of late documentation. I am used to the illiterate slagging off about what they don't know about MASM in 64 bit but its always been a put up or shut up world.  :P

Welcome back.

[zedd151]

I've read some of the things missing from ml64.exe,

Thats how skynet got started, broken, buggy software from the start - by design.   8)
Yes, there is a steep learning curve with ml64, as I have found out.

It will take (me at least) a while to get used to the calling convention for instance.
But as 32 bit is on it's way out, sooner or later we have no choice.

[jj2007]

But as 32 bit is on it's way out, sooner or later we have no choice.

That is what hardware vendors want us to believe; like in the old days when 16-bit DOS was thrown out by 32-bit Windows.
Fact is that
- 64-bit programs are not faster than 32-bit programs (16->32: roughly a factor 5...10 gain)
- the gain in addressable memory concerns 0.1% of all applications (16->32: 640kB was a joke, 2GB is luxury)
- there is a 1000 times more 32-bit "legacy" software on the market than 16-bit code.

32-bit software will stay forever.

[hutch--]

Those of us familiar with the grunt of 64 bit MASM don't have to make that choice. 32 bit code will be with us for a long time as it is still useful but its legacy code, 64 bit with /LARGEADDRESSAWARE can handle massive amounts of memory, has twice as many registers and has lower stack overhead that 32 bit STDCALL code. Like each OS version architecture change, it is more complicated than 32 bit code but much more powerful.

Gone are the days when you have to add the overhead of pushing non volatile registers so you can write the algorithm properly, with 7 volatile registers you rarely ever need to preserve registers but when you do you have a total of 14 out of the 16 available (wise not to play with RBP and RSP) that can be easily used for very large and complex algorithms.

What you need is a real assembler[tm] like MASM which can do it all and as a professional tool for professional programmers, it does not hold your hot little hand and will regularly bite the hand that feeds it. Its pre-processor is a cantankerous old pig that can do a vast number of things if you suffer long enough to learn how it works.

Large sheet of XXXX grade sandpaper in the loo. You can tell the men from the boys by the paper they use.  :P

[zedd151]

@hutch, yes I know. But due to combination of memory block/and my recent memory leakage, It's going to be hard for me to learn new tricks. (old dog - lol) But I AM trying to learn.

[hutch--]

Don't write yourself off Z, I have seen enough of your code to say that you know what you are doing, the rest is just practice. It took me months to get the swing of how 64 bit Windows worked and while it is more complicated, it also is more efficient and it is the future.

[zedd151]

Don't write yourself off Z

Oh God no, I am just getting comfortable again, and can now relax and code at leisure.
I have been working on a few projects, one involves converting a few of my oldies but
goodies to 64 bit. But I still mainly use 32 bit for the time being.

I have a decent Windows 7 64 bit setup, Windows 10 is still around if I 'really' need it,
for benchmark comparisons and compatibility testing for instance.

I have Windows xp I can run in Virtual Box when I want to stroll down 'memory lane',
I never new enough 16 bit code to do anything useful (Thank God!) so for me its either
32 bit or 64 bit. And I am slowly trying to learn 64 bit asm programming.   

I do have a couple of plugins that convert
push arg
push arg
push arg
call procedure

to: invoke procedure, arg, arg, arg

and vice versa. I want to experiment with creating one that simplifies converting from
32 bit code to to 64 bit code, without using macros - so that the converted code looks
very similar to a 64 bit disassembly output.   8) But thats on the back burner at the
moment.