Hello from an absolute beginner

[brazer]

Hello community,

I have some questions but since this is my first post let me first introduce my self to show I'm not looking for trouble.

I'm not new to programming, my background is C++ and PowerShell which are two languages I'm proficient with and have written several working projects so far,
however I don't publicly share any of my projects except only one which you can find in my signature below if you whish to see.

Other major projects I work on include GUI framework and various utility libraries which I personally use to write new stuff, however the reason why I don't share them is
either due to incompatible licenses or because I wish to keep certain stuff for myself.

However when it comes to ASM I'm a new born, so far I've managed to set up a comfortable dev environment and getting some books to help in studying assembly.
The reason why I decided to learn assembly is because so far I have many times stumbled upon various scenarios that require knowing assembly and then I felt bad
for not understanding code or how to do this or that...

I wanted to start learning with nasm assembler because of nicer syntax but due to lack of modern books for X86-64 on Windows I'm it seems forced to use ml64 to make learning
as fast as possible, even though I dislike the syntax of MS assembler.

Here is my starting question!
I see ml64 is Microsoft assembler and what really confuses me is the MASM32 project on this site, I see there is MASM SDK that is presumably open source?
I quickly skimmed trough wikipedia site HERE and it doesn't seem to say that MS's ml64 is open source.

So I wonder how is the ml64 that is distributed with Windows SDK different from MASM SDK published on this site?
I assume there is some historical stuff and I would also like to know if there is some difference between MS's software license and masm SDK license?
what starting resources ex. links can you share to help me understand more about masm and MS's assembler?

[hutch--]

The Microsoft binaries in the masm32 SDK were an agreement With Microsoft Australia back in 1997. You get any later stuff directly from Microsoft under their conditions.

The 32 and 64 bit SDKs are NOT OPEN SOURCE and never have been. They are copyright FREEWARE.

To use the 64 bit version binaries (ML64 - LINK, you need to obtain them directly from Microsoft.

> I quickly skimmed trough wikipedia site HERE and it doesn't seem to say that MS's ml64 is open source.

ML64 is Microsoft proprietry software, it is not open source.

[daydreamer]

Welcome brazer
Good luck

[brazer]

Thank you guys, appreciate your responses! 

[zedd151]

Welcome to the forum, brazer!

[NoCforMe]

Welcome to the world of low(er)-level programming.

One question I'd ask you is this: are you sure you really need 64-bit programming? I've found that I can do everything I need to in the 32-bit realm. Unless you're coding some really high-performance or large-volume apps, you probably don't need 64-bit, even though it is the latest and greatest.

BTW, since you're an experienced C programmer, I'm sure you'll find that it's not difficult at all to translate C to ASM. In fact, that might be a good way for you to approach learning assembler: take a simple C program and translate it. You might want to look at some existing simple assembly-language programs and copy them. I always start my programs from templates I have, rather than trying to write from scratch. I'd suggest a GUI (windowed) application rather than a console (command-window) one, but that's up to you.

Hope to hear news of your first successful "Hello, world!" program soon.

[jj2007]

Welcome to the Forum

One question I'd ask you is this: are you sure you really need 64-bit programming? I've found that I can do everything I need to in the 32-bit realm. Unless your coding some really high-performance or large-volume apps, you probably don't need 64-bit, even though it is the latest and greatest.

Correct. However, if you plan to call asm routines from C, and your C compiler likes the 64-bit World, then it's a different story.

I have significant experience in 64-bit land but do 99% of my coding in 32-bit. It's mostly a matter of habit and taste. I can also confirm that the learning curve for 64-bit assembly is indeed steeper. Plus, there is considerable confusion about the best approach, and there are conflicting SDKs around.

[hutch--]

Don't be talked out of 64 bit MASM just because a few want to live in the past. Its capable of handling bigger data and written properly, its also faster. Its also current where 32 bit Windows is in its twilight. If you are writing 64 bit C/C++, you need to learn how to call 64 bit MASM procedures, that is among the reasons why 64 bit MASM exists as 64 bit Microsoft C/C++ does not handle inline assembler.

[Gunther]

brazer,

welcome to the forum and have a lot of fun. As far as 64 bit programming is concerned, you can trust Hutch's arguments in any case.

Good luck.

[brazer]

Thank you guys for welcome!

One question I'd ask you is this: are you sure you really need 64-bit programming? I've found that I can do everything I need to in the 32-bit realm. Unless you're coding some really high-performance or large-volume apps, you probably don't need 64-bit, even though it is the latest and greatest.

It's probably silly reason but why 64-bit is because I feel that learning old concepts first and then new concepts later would take more time than going straight to x64.
I look at it in similar way as to whether one should be learning C before C++ or jumping straight to C++ and save some time.

Can't say for sure but I think understanding 32 bit asm won't be that hard once I get a grasp of x64?
To my current knowledge the only difference is address size, use of segment registers and 64bit specific register names, is there anything else that is significant?

Don't be talked out of 64 bit MASM just because a few want to live in the past. Its capable of handling bigger data and written properly, its also faster. Its also current where 32 bit Windows is in its twilight. If you are writing 64 bit C/C++, you need to learn how to call 64 bit MASM procedures, that is among the reasons why 64 bit MASM exists as 64 bit Microsoft C/C++ does not handle inline assembler.

Don't worry I won't be drawn away  , I already took my path and also I'm obsessed to use cutting edge techniques.

I can also confirm that the learning curve for 64-bit assembly is indeed steeper. Plus, there is considerable confusion about the best approach, and there are conflicting SDKs around.

Interesting because I'm not able to imagine the benefits of 32bit programming except if you target 32 bit OS or if you want or need reduced memory use which is neglectable for small programs on today's computers.
What makes x64 bit learning curve steeper? I assume it's mostly about how code is written rather than new register names or address size?

[jj2007]

I can also confirm that the learning curve for 64-bit assembly is indeed steeper. Plus, there is considerable confusion about the best approach, and there are conflicting SDKs around.

Interesting because I'm not able to imagine the benefits of 32bit programming except if you target 32 bit OS or if you want or need reduced memory use which is neglectable for small programs on today's computers.
What makes x64 bit learning curve steeper? I assume it's mostly about how code is written rather than new register names or address size?

An example:

Code Select Expand

WinMain proc
LOCAL msg:MSG
  wc equ [rbx.WNDCLASSEX] ; we use an equate for better readability
  lea rbx, wcx
  mov wc.hInstance, rv(GetModuleHandle, 0)
  mov wc.hIcon, rv(LoadIcon, rax, IDI_APPLICATION)
  mov wc.hIconSm, rax ; the rv macro returns results in rax
  mov wc.hCursor, rv(LoadCursor, NULL, IDC_ARROW) ; get a cursor
  jinvoke RegisterClassEx, rbx ; the window class needs to be registered
  wsStyle=WS_OVERLAPPEDWINDOW or WS_VISIBLE or WS_CLIPCHILDREN
  jinvoke CreateWindowEx, 0, wc.lpszClassName, Chr$("Hello World"), wsStyle, 300+320*@64, 127, 300, 200, NULL, rv(LoadMenu, wc.hInstance, 100), wc.hInstance, NULL
  msgLoop: inc eax
shr eax, 1
je @F ; quit if GetMessage returned 0 (exit OK) or -1 (error), or if CwEx failed
  jinvoke TranslateMessage, addr msg ; translates virtual-key messages into character messages
jinvoke DispatchMessage, addr msg ; dispatches a message to a window procedure
jinvoke GetMessage, addr msg, 0, 0, 0 ; retrieve a message from the queue, and return a BOOL
  jmp msgLoop
@@: jinvoke ExitProcess, msg.wParam
WinMain endp

a) looks suspiciously similar to most standard main functions in assembly
b) assembles as 64- or 32-bit code, just by setting a single switch
c) lots of stuff going on under the hood

So it's all the same? No, because you probably want to touch the bare metal, so you want to go under the hood, and there the learning curve kicks in. Google x64 stack alignment shadow space to get a glimpse of it

Btw there is no .if eax>ecx or similar in that snippet above. Strangely enough, the snippet assembles with ML64, UAsm and AsmC. If there was a .Repeat  ... inc eax ... .Until eax>100, it would assemble with UAsm and AsmC but not with MASM. Micros*t decided that all that hi level crap that we were used to in 32-bit land was no longer necessary for the 21th Century, so they dropped it. Hutch has created workaround macros, but they won't work with the WatCom clones (UAsm and AsmC). Which is not a problem when coding hello world apps, but when you approach the 10,000 lines, you might appreciate that the clones are a factor 5 or so faster...

My advice? None. Do as you please, you have plenty of choice

[hutch--]

brazer,

x64 Windows has a more complex architecture, its stack is complicated and if it is not aligned correctly, it just won't run. A pure mnemonic procedure will run OK but any external calls require correct alignment. ML64 is not trying to be a C/C++ compiler, its a low level assembler and supplied with VS to handle the lack of inline assembler.

For free standing executables, making library modules is simple enough if you know how to write the ML64 code. Others come and go but ML64 is backed by the OS vendor, Microsoft. It is not a warmed over 32 bit assembler but a dedicated 64 bit Windows assembler.

Just be warned that the learning curve with 64 bit MASM is complicated but if you master it, it has the hoot and is more than capable of producing reliable fast 64 bit apps.

[daydreamer]

64bit biggest advantage is let you alloc almost all 64gb memory,but mostly usage is cg programs and video processing,you have plenty of 16 64 bit register,16 XMM/YMM regs in 64bit
while 32bit restricted to 3.5gb memory and winapi uses 3 registers,so push 3 regs/pop 3 regs after call to use most 32bit registers also fewer 8 XMM/YMM regs


I dont know what your goal is after not being asm newbie
cpp,you use lots of OOP there are some who made MASM OOP
some are also into SSE SIMD 128bit programming like me
here we mostly keep it restricted to use SSE2 to be make it run on older computers
all kinds of programming in asm,even few who make DOS programs

[brazer]

OK, I must trust you guys it will be tricky and time consuming, every beginning sucks..
btw. I found one good and funny reason why here

but the main reason is simply because you can

Lol, I really like that one, it gives a special kind of motivation

[Vortex]

Hi brazer,

Welcome to the Masm Forum.