Hello from an absolute beginner

[hutch--]

brazer,

Something we have seen before is people making the wrong assumptions while collecting a range of information about writing code in assembler. The bottom line is if you want to succeed, you will learn how to write mnemonic code and the intricacies of the Intel instruction set. Then there is the base architecture in either 32 or 64 bit and a very large range of Windows API functions.

When you have learnt enough, you will know what to use and what tools you need but unless you start writing pure mnemonic code, you will not get to the starting line.

[brazer]

hutch--,

I understand your point and believe you that writing code is most important.

Your assumption is correct, I must admit, I've certainly spent a whole week until now preparing my self to have all the preparatory stuff in place,
dev environment, books, choosing a debugger, tools, coding style, web resources and what not...

I'll certainly jump into writing code soon no doubt about that, for now as I discover the fundamentals I'm starting to see the beauty of assembly,
just by listening how you guys love writing assembly only gives me an additional inspiration, I see you're experts and not just some random coders hanging around.

There is one "sickness" of mine however, I really enjoy being pedantic and that sticks with me since ever like a curse, it often times consumes my time and sometimes I just can't help myself.
But I'll listen to your advice and jump into asm ASAP

[NoCforMe]

[...] you can't access the bytes of esi and edi.

Right, unless you do something like this

Code: [Select]

MOV EAX, [ESI]
CMP AL, '.'
JE isPeriod

[NoCforMe]

Hah, I like your joke about RIP register lol 
I don't know if and when will 32 bit systems go out of scope, likely not anytime soon yet, there is still a bunch of devices running on 32 bit CPU's.

What criteria would there have to be to drop 32 bit OS support? hardware manufacturers perhaps? probably more likely than OS vendors.

Not bloody likely anytime soon, if ever. Despite Micro$oft's wet dreams of everyone abandoning everything else in favor of whatever the Latest and Greatest is. For chrissakes, there are still systems out there running 16-bit DOS code that have to be maintained. So I'd say that reports of the demise of Win32 are greatly exaggerated.

Question for you: You said you were copying ASM examples out of PDF files. Did you list any such sources? I couldn't find any searching this thread. I'd be curious to see what they look like. In the meantime, there is plenty of example code posted in non-PDF format, which may be easier to deal with and re-format.

An automatic ASM formatter sounds interesting and useful, but I wouldn't get hung up on it and let it impede your progress towards learning the language just yet.

Just for the heck of it, here's my assembler "skeleton" that I use to start new (GUI) programs. It creates a desktop window (with a status bar) and a window procedure, centers it on the desktop. (I have other skeletons, one for creating console apps, another for creating apps that use a dialog box as the main window, a really useful thing as it eliminates the need to create controls using CreateWindowEx(). You'll need either a resource editor, or what I use, a dialog editor (my homemade one) that creates dialog memory templates you can simply INCLUDE in your .asm source. (I'm not a big fan of using resource files; yet another file to link and keep track of.)

Code: [Select]

;============================================
; -- Skeleton --
; -- [project title here] --
;
;============================================

.nolist
include \masm32\include\masm32rt.inc
.list

;============================================
; Defines, macros, prototypes, etc.
;============================================

$mainWinWidth EQU 600
$mainWinHeight EQU 500

;===== Window styles: =====
; Change 1st 2 styles to "WS_OVERLAPPEDWINDOW" if you want a resizeable window:
$mainWinStyles EQU WS_CAPTION or WS_SYSMENU or WS_CLIPCHILDREN or WS_VISIBLE

;===== Window background colors: =====
$bkRED EQU 254
$bkGRN EQU 243
$bkBLUE EQU 199

$BkColor EQU $bkRED OR ($bkGRN SHL 8) OR ($bkBLUE SHL 16)

$SBID EQU 1111
$SBX EQU 0
$SBY EQU $mainWinHeight - $SBHeight
$SBWidth EQU $mainWinWidth
$SBHeight EQU 40
$numStatusParts EQU 4

$SB_styles EQU WS_CHILD OR WS_VISIBLE

;============================================
; HERE BE DATA
;============================================
.data

WC WNDCLASSEX < SIZEOF WNDCLASSEX, \
CS_HREDRAW or CS_VREDRAW or CS_BYTEALIGNWINDOW, \
NULL, \ ;lpfnWndProc
NULL, \ ;cbClsExtra
NULL, \ ;cbWndExtra
NULL, \ ;hInstance
NULL, \ ;hIcon
NULL, \ ;hCursor
NULL, \ ;hbrBackground
NULL, \ ;lpszMenuName
NULL, \ ;lpszClassName
NULL > ;hIconSm

StatusParts DD 50, 150, 250, -1

NullString DB 0

MainClassName DB "[class name here]", 0

MainTitleText DB "[window title here]", 0

;============================================
; UNINITIALIZED DATA
;============================================
.data?

MainWinHandle HWND ?

InstanceHandle HINSTANCE ?

StatusHandle HWND ?
SBheight DD ?


;============================================
; CODE LIVES HERE
;============================================
.code

start: INVOKE GetModuleHandle, NULL
MOV InstanceHandle, EAX

CALL WinMain
INVOKE ExitProcess, EAX


;====================================================================
; Mainline proc
;====================================================================

WinMain PROC
LOCAL msg:MSG, brush:HBRUSH, wX:DWORD, wY:DWORD, gpRect:RECT

; Create  brush to set background color:
INVOKE CreateSolidBrush, $BkColor
MOV brush, EAX

; Register class for parent window:
MOV EAX, InstanceHandle
MOV WC.hInstance, EAX
MOV WC.lpfnWndProc, OFFSET MainWindowProc
MOV EAX, brush
MOV WC.hbrBackground, EAX
MOV WC.lpszClassName, OFFSET MainClassName
; INVOKE LoadIcon, InstanceHandle, 500    ; icon ID
; MOV WC.hIcon, EAX
MOV WC.hIcon, NULL
INVOKE LoadCursor, NULL, IDC_ARROW
MOV WC.hCursor, EAX
INVOKE RegisterClassEx, OFFSET WC

INVOKE GetSystemMetrics, SM_CXSCREEN
MOV EDX, $mainWinWidth
CALL CenterDim
MOV wX, EAX
INVOKE GetSystemMetrics, SM_CYSCREEN
MOV EDX, $mainWinHeight
CALL CenterDim
MOV wY, EAX

; Create our main window:
INVOKE CreateWindowEx, WS_EX_OVERLAPPEDWINDOW, OFFSET MainClassName,
OFFSET MainTitleText, $mainWinStyles, wX, wY, $mainWinWidth,
$mainWinHeight, NULL, NULL, InstanceHandle, NULL
MOV MainWinHandle, EAX

; Create the status bar:
INVOKE CreateStatusWindow, $SB_styles, OFFSET NullString, MainWinHandle, $SBID
MOV StatusHandle, EAX
MOV EDX, EAX
; Get the height of the status bar:
INVOKE GetWindowRect, EDX, ADDR gpRect
MOV EAX, gpRect.bottom
SUB EAX, gpRect.top
MOV SBheight, EAX

; Divide status bar into parts:
INVOKE SendMessage, StatusHandle, SB_SETPARTS, $numStatusParts, OFFSET StatusParts

;============= Message loop ===================
msgloop:
INVOKE GetMessage, ADDR msg, NULL, 0, 0
TEST EAX, EAX ;EAX = 0 = exit
JZ exit99
INVOKE TranslateMessage, ADDR msg
INVOKE DispatchMessage, ADDR msg
JMP msgloop

exit99: MOV EAX, msg.wParam
RET

WinMain ENDP

;====================================================================
; Main Window Proc
;====================================================================

MainWindowProc PROC hWin:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
LOCAL gpRect:RECT

MOV EAX, uMsg
; CMP EAX, WM_COMMAND
; JE do_command
CMP EAX, WM_CREATE
JE do_create
CMP EAX, WM_CLOSE
JE do_close
CMP EAX, WM_SIZE
JE dosize

dodefault:
; use DefWindowProc for all other messages:
INVOKE DefWindowProc, hWin, uMsg, wParam, lParam
RET

do_command:
; MOV AX, WORD PTR wParam
; CMP AX, ---- ;Check command code here.
; JE ---

do_create:

; Window creation code here

XOR EAX, EAX
RET

dosize:
INVOKE GetClientRect, hWin, ADDR gpRect
MOV EDX, gpRect.bottom
SUB EDX, gpRect.top
SUB EDX, SBheight
INVOKE MoveWindow, StatusHandle, 0,  EDX, gpRect.right, SBheight, TRUE

XOR EAX, EAX
RET

do_close:
INVOKE PostQuitMessage, NULL
MOV EAX, TRUE
RET

MainWindowProc ENDP

;====================================================================
; CenterDim
;
; Returns half screen dimension (X or Y) minus half window dimension
;
; On entry,
; EAX = screen dimension
; EDX = window dimension
;
; Returns:
; sdim/2 - wdim/2
;====================================================================

CenterDim PROC

SHR EAX, 1 ;divide screen dimension by 2
SHR EDX, 1 ;divide window dimension by 2
SUB EAX, EDX
RET ;Return w/# in EAX

CenterDim ENDP

END start


[jj2007]

[...] you can't access the bytes of esi and edi.

Right, unless you do something like this

Code: [Select]

MOV EAX, [ESI]
CMP AL, '.'
JE isPeriod

What I meant is:
al is the byte of eax
bl is the byte of ebx
cl is the byte of ecx
dl is the byte of edx
...
but that won't work for esi, edi, ebp and esp

[NoCforMe]

Yes, exactly, and isn't it kind of amazing that we can do that with EAX ... EDX at this late date? I mean, I use that capability all the time (but that might be because as Hutch might accuse me, I'm programming "in the past"). Those are historical artifacts dating back to the 1980s. I'm glad Intel left them in for us to use.

[NoCforMe]

I did suspect it's [code formatting] personal taste because not much can be found on the net, I was able to find only one lengthy resource:
http://www.sourceformat.com/coding-standard-asm-style.htm

I just took a peek at that, and I've got to say: it's a bunch of crap. I'm sure Hutch would agree with me here. And my gawd, it's a lengthy bunch of crap: meticulously sectioned, painstakingly annotated. Still crap.

I mean, it's fine to have strong opinions about good formatting style: we all do. Some are better than others, of course, but in the end it's all pretty subjective. (Well, I have some formatting rules that I think are objectively better, like identifying locals vs. globals via capitalization, but if someone just doesn't like that style then it doesn't matter if it's better or not.) But to try to impose your style on the rest of the world? Buddy, that just ain't gonna work. (And I hate his use of lowercase throughout!)

If I might ask, what kind of code will you be writing? I took a quick peek at your GitHub (is that the right term?); are you a gamer? Just curious about what kind of apps you'll be creating.

Whatever you do, since we all know that assembler is not the hot current production tool, nor will it ever be, have fun with it. (That why I use it.)

[jj2007]

I did suspect it's [code formatting] personal taste because not much can be found on the net, I was able to find only one lengthy resource:
http://www.sourceformat.com/coding-standard-asm-style.htm

I just took a peek at that, and I've got to say: it's a bunch of crap. I'm sure Hutch would agree with me here.

Me too

Code: [Select]

    call CopyString
    inc di
    mov si, OFFSET DTA_TIME     ;Copy time, date and size
    mov cx, 4
    rep movsw
    mov ah, 4Fh                 ;Next filename
    int 21h
    jnc StoreFileName
    mov [last], bx              ;Save pointer to last file entry
    mov al, [keepSorted]        ;If returning from EXEC, need to resort

The primary problem with this program is the formatting. The label fields overlap the mnemonic fields (in almost every instance), the operand fields of the various instructions are not aligned

Code: [Select]

                call    CopyString
                inc     di                      ;Skip zero byte (???).

                mov     si, offset DTAtime      ;Copy time, date and size
                mov     cx, 4
        rep     movsw

I thoroughly hate when coders use

Code: [Select]

mov eaxinstead of

Code: [Select]

mov eax
The human eye is not happy with jumping all over the place - mov eax is easier to read and to understand

As to lowercase vs uppercase: I prefer offset somevar, much easier to read and to type.

Code: [Select]

    mov [last], bx              ;Save pointer to last file entry
    mov al, [keepSorted]        ;If returning from EXEC, need to resort
Much better:

Code: [Select]

    mov last, bx              ;Save pointer to last file entry
    mov al, keepSorted        ;If returning from EXEC, need to resort
That [bracket] crap is coming from older assemblers; not needed with MASM/UAsm/AsmC.

Most studies on the subject indicate that routines in excess of 150-200 lines of code tend to contain more bugs

One of my WndProcs has more than 1600 lines

[brazer]

Question for you: You said you were copying ASM examples out of PDF files. Did you list any such sources? I couldn't find any searching this thread. I'd be curious to see what they look like. In the meantime, there is plenty of example code posted in non-PDF format, which may be easier to deal with and re-format.

An automatic ASM formatter sounds interesting and useful, but I wouldn't get hung up on it and let it impede your progress towards learning the language just yet.

The following are the only 2 comprehensive books (1600 pages total) about modern assembly which I use:
https://www.amazon.com/Art-64-Bit-Assembly-Language/dp/1718501080
https://www.amazon.com/Modern-X86-Assembly-Language-Programming/dp/1484240626

Reason why I prefer books over tutorials and samples on the net etc. is because books are beginner friendly, go step by step, from easy toward complex and every concept and keyword in
code samples is explained in detail.

I just finished chapter 1 out of 16 of the first book, that's some 8 code samples, one of which looks like this:

Code: [Select]

; Listing 1 - 5
; A "Hello, world!" program using the C / C + + printf() function to
; provide the output.
option casemap:none
.data
; Note: "10" value is a line feed character, also known as the
; "C" newline character.
fmtStr byte 'Hello, world!', 10, 0
.code
; External declaration so MASM knows about the C / C + + printf()
; function.
externdef printf:proc

; Here is the "asmFunc" function.
public asmFunc
asmFunc proc
; "Magic" instruction offered without explanation at this point:
sub rsp, 56
; Here's where we'll call the C printf() function to print
; "Hello, world!" Pass the address of the format string
; to printf() in the RCX register. Use the LEA instruction
; to get the address of fmtStr.
lea rcx, fmtStr
call printf
; Another "magic" instruction that undoes the effect of the
; previous one before this procedure returns to its caller.
add rsp, 56

ret                          ; Returns to caller

asmFunc endp
end

I can imagine how funny this code may look to you, but to me, I didn't understand anything how this code works until I've read the explanation,
heavy commenting and step by step explanation found in the book is very useful to me, primarily because I don't need to go google out anything nor ask questions, it's all there.

Once I finish those books, using samples, tutorials, docs and other types of resources will be easier.

An automatic ASM formatter sounds interesting and useful, but I wouldn't get hung up on it and let it impede your progress towards learning the language just yet.

Just for the heck of it, here's my assembler "skeleton"...

snippets and templates are cool, I can imagine they are much more useful in assembly than in other languages.

I'll certainly make some of my own in the future, but for now I just need to get grasp of the very basic stuff, memorizing mnemonics, calling conventions, register names, directives,
language grammar, history and all the very basic stuff to get some confidence.

While I'm familiar with windows API, I'm certainly having difficulty understanding how your sample works, it will take some time until I get a glimpse over basics.

And my asm formatter, if you look at the sample code above it takes to format it by hand and get annoying, I'll be updating my formatter little by little as I discover new language constructs but I consider it
finished for my needs.

[NoCforMe]

OK, here's another skeleton, but totally pared down: you can't get any simpler than this if you want to create a window. (A console app could be even smaller.)

Code: [Select]

;============================================
; -- Absolute Minimum Skeleton --
;
; Creates a resizeable window, and that's it.
;============================================

.nolist
include \masm32\include\masm32rt.inc
.list

;============================================
; HERE BE DATA
;============================================
.data

WC WNDCLASSEX < SIZEOF WNDCLASSEX, \
CS_HREDRAW or CS_VREDRAW or CS_BYTEALIGNWINDOW, \
NULL, \ ;lpfnWndProc
NULL, \ ;cbClsExtra
NULL, \ ;cbWndExtra
NULL, \ ;hInstance
NULL, \ ;hIcon
NULL, \ ;hCursor
NULL, \ ;hbrBackground
NULL, \ ;lpszMenuName
NULL, \ ;lpszClassName
NULL > ;hIconSm


MainClassName DB "AbsMinSkel", 0
MainTitleText DB "Absolute Minimum Skeleton Demo", 0

;============================================
; UNINITIALIZED DATA
;============================================
.data?

InstanceHandle HINSTANCE ?

;============================================
; CODE LIVES HERE
;============================================
.code


start: INVOKE GetModuleHandle, NULL
MOV InstanceHandle, EAX

CALL WinMain
INVOKE ExitProcess, EAX

;====================================================================
; Mainline proc
;====================================================================

WinMain PROC
LOCAL msg:MSG

; Register class for parent window:
MOV EAX, InstanceHandle
MOV WC.hInstance, EAX
MOV WC.lpfnWndProc, OFFSET MainWindowProc
INVOKE GetStockObject, WHITE_BRUSH ;Use a Windows stock item.
MOV WC.hbrBackground, EAX
MOV WC.lpszClassName, OFFSET MainClassName
MOV WC.hIcon, NULL
INVOKE LoadCursor, NULL, IDC_ARROW
MOV WC.hCursor, EAX
INVOKE RegisterClassEx, OFFSET WC

; Create our main window:
INVOKE CreateWindowEx,
WS_EX_OVERLAPPEDWINDOW, ;EXstyles
OFFSET MainClassName,
OFFSET MainTitleText,
WS_OVERLAPPEDWINDOW or WS_CLIPCHILDREN or WS_VISIBLE, ;window is resizeable
100, ;X-pos
100, ;Y-pos
600, ;width
400, ;height
NULL, ;parent (none=desktop)
0, ;menu/ID (none needed here)
InstanceHandle, ;instance handle
0 ;param (not used here)

;============= Message loop ===================
msgloop:
INVOKE GetMessage, ADDR msg, NULL, 0, 0
TEST EAX, EAX ;EAX = 0 = exit
JZ exit99
INVOKE TranslateMessage, ADDR msg
INVOKE DispatchMessage, ADDR msg
JMP msgloop

exit99: MOV EAX, msg.wParam
RET

WinMain ENDP

;====================================================================
; Main Window Proc
;====================================================================

MainWindowProc PROC hWin:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD
LOCAL gpRect:RECT

CMP uMsg, WM_CLOSE
JE do_close

dodefault:
; use DefWindowProc for all other messages:
INVOKE DefWindowProc, hWin, uMsg, wParam, lParam
RET

do_close:
INVOKE PostQuitMessage, NULL
MOV EAX, TRUE
RET

MainWindowProc ENDP

; This sets the program entry point for Windows:
END start


I'm assuming you're familiar with Windows, specifically with the Win32 API? Creating windows and all in C? If so, it's the same in assembly language. If not, here's what you have to do to create and use a window:

• Register the window class with RegisterClassEx() *
• Create a window procedure ("proc") for the window to handle the messages it'll be getting
• Create a message loop at the end of your "mainline" procedure (main() in C)
• Create the window with CreateWindowEx() *

* You don't need to do this or create the window by hand if you use a dialog (using a resource editor), in which case the "dialog manager" takes care of all that for you.

(I unrolled the CreateWindowEx() call so you can see what all those parameters are.)

Once you create the window, you're rolling. The window procedure gets the window's messages and processes them. Here, the only one we're bothering with here is WM_CLOSE, which is received when the user gets tired of looking at this stupid window and closes it.

The message loop is the famous "message pump" that constantly gets and dispatches messages to your window procedure (actually, to ALL your window procedures--there can be many of them). Since Windows is an event-driven OS, all the interaction with a window is through the messages it receives (and the messages it and other parts of your code sends).

The window procedure ALWAYS looks like this:

Code: [Select]

<name of proc here> PROC hWin:HWND, uMsg:DWORD, wParam:DWORD, lParam:DWORD

The names of those parameters (hWin, uMsg, etc.) don't matter at all; you could call them "JoeSchmo" and they'd still work. What's important is their type (well, they're all DWORDs, QWORDs in 64-bit) and their meaning:

• hWin is the window handle (unique to this window)
• uMsg is the message being received (WM_CREATE, WM_CLOSE, etc.)
• wParam and lParam are additional data accompanying the message (depends on the message)

And be sure to forward any messages you don't handle to DefWindowProc(), so Windows can do its default thing with them.

Hopefully none of this is insulting your intelligence because you're already familiar with it.

You could actually assemble and link this li'l program if you wanted. I've attached the .exe so you can see the result (nothing to write home about).

[brazer]

I'm assuming you're familiar with Windows, specifically with the Win32 API? Creating windows and all in C? If so, it's the same in assembly language.
Hopefully none of this is insulting your intelligence because you're already familiar with it.

No far from that, you're not insulting me, Win32 API is not a problem, I just want to get to know the language before I jump into UI programming
or anything that is ahead of basics for now.

You could actually assemble and link this li'l program if you wanted. I've attached the .exe so you can see the result (nothing to write home about).

I couldn't assemble it because didn't install masm SDK, but I've downloaded your executable and what is truly amazing is that the executable is only 4KB.
That's really awesome, it's shows the potential of using assembly instead of HLL.

In any case a long journey is ahead of me to get comfortable with the language, everything is very different from what I'm used to.
Appreciate all of the help, I'll certainly get back to this thread to recall samples.

I did suspect it's [code formatting] personal taste because not much can be found on the net, I was able to find only one lengthy resource:
http://www.sourceformat.com/coding-standard-asm-style.htm

I just took a peek at that, and I've got to say: it's a bunch of crap. I'm sure Hutch would agree with me here. And my gawd, it's a lengthy bunch of crap: meticulously sectioned, painstakingly annotated. Still crap.

I mean, it's fine to have strong opinions about good formatting style: we all do. Some are better than others, of course, but in the end it's all pretty subjective. (Well, I have some formatting rules that I think are objectively better, like identifying locals vs. globals via capitalization, but if someone just doesn't like that style then it doesn't matter if it's better or not.) But to try to impose your style on the rest of the world? Buddy, that just ain't gonna work. (And I hate his use of lowercase throughout!)

Sorry but I somehow missed this post of yours, I see formatting can be one big subjective debate but this is the only link I found and honestly didn't read it all,
I only skimmed trough and haven't formed any opinions yet because it's too early for me to make conclusions.

If I might ask, what kind of code will you be writing? I took a quick peek at your GitHub (is that the right term?); are you a gamer? Just curious about what kind of apps you'll be creating.

Whatever you do, since we all know that assembler is not the hot current production tool, nor will it ever be, have fun with it. (That why I use it.)

I wanted to know know game dev, but I have given up long time ago because to make games one person alone is not enough to make good games and I don't really want to waste years to work on just one
game project, most free game engines out there suck and I don't have motivation nor time to write my own, I don't know nor enjoy graphics design, pure coding is much more fun.
I made only one game so far which is a 2D roulette simulation, primarily math and calculation of odds instead of shiny graphics.

I'm not really sure what kind of code will I write in assembly, but major motivation that drives me is to boost my programming skills, I like low level programming, micro optimizations and dependency free code.

Assembly is attractive, I'm not really sure why didn't I learn it before but there was and still is a lot of people telling that assembly isn't a thing because you can't defeat compiler and similar excuses.
I guess I was affected by such statements so I never took a look at asm myself but I do realize now there are 2 conflicting world views between assembly coders and HLL coders, at least when it comes to pushing
personal opinions upon others.

So in the end I guess I'll be using assembly in combination with HLL to optimize portions of code and to boost skills overall but nothing serious or big.

[jj2007]

Assembly is attractive, I'm not really sure why didn't I learn it before but there was and still is a lot of people telling that assembly isn't a thing because you can't defeat compiler and similar excuses.

There are occasionally cases where the C/C++ compiler is on par with assembly, but generally we are not happy if we can't beat the beast by at least a factor 2 - see The Lab for some examples

Attached my Windows GUI template - pure Masm32 SDK code, 93 lines, 7.5kB exe, with a menu, an edit control and a WM_PAINT handler. I think it's about time to install the Masm32 SDK ;-)

[hutch--]

brazer,

I will tell you a funny story, back in the late 90s, most academia lambasted assembler programming as unreadable, unwritable and unable to compete with then modern C compilers.

As many asm programmers are fluent in C, the solution to this dogma was done by example. My contribution was a 6k editor called "TheGun" written in 32 bit MASM and their mouths became silent. Microsoft re-released an updated ML.EXE and assembler became main stream again.

There has always been programming language wars and that will probably never change but the brutal performance of pure assembler coding keeps them honest, they may not like it, they may never be able to write it but its there for a reason, Microsoft need assemblers for their OS development.

64 bit MASM (ML64.EXE) is very low level and no joy to learn but with enough support, include files, libraries and documentation, it can deliver kick ass performance when written correctly. You just need to know how to write it.

[NoCforMe]

I've downloaded your executable and what is truly amazing is that the executable is only 4KB.
That's really awesome, it's shows the potential of using assembly instead of HLL.

That's because it doesn't have to drag in the entire C runtime library just to put up a simple window. We get to pick and choose exactly what code gets included in our executables.

Assembly is attractive, I'm not really sure why didn't I learn it before but there was and still is a lot of people telling that assembly isn't a thing because you can't defeat compiler and similar excuses.
I guess I was affected by such statements so I never took a look at asm myself but I do realize now there are 2 conflicting world views between assembly coders and HLL coders, at least when it comes to pushing personal opinions upon others.

Good. Just so long as you realize that assembly language is not, and probably will never be, a really viable development tool for commercial applications, mainly because of the portability issue, but for other reasons as well, you can have lots of fun exploring it and coming up with useful ways to apply it. Writing assembler utility routines for a HLL program isn't a bad way to go at all.

[TimoVJL]

Just to be fair for C.