Microsoft SetTimer parameters wrote:

[in] nIDEvent
Type: UINT_PTR

A nonzero timer identifier.

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-settimer

  .wmpaint:
        invoke  BeginPaint,[hwnd],ps
        mov     [hdc],eax
        invoke  EndPaint,[hwnd],ps
        xor     eax,eax
        jmp     .finish   
    

Is the "align 16" for faster performance?

A variable of a certain size must be at an address multiple of this size.

There is an alignment requirement for the stack in 64-bit Windows. But other variables not passed on the stack don't have that requirement.

revolution wrote:

There is an alignment requirement for the stack in 64-bit Windows. But other variables not passed on the stack don't have that requirement.

I can't find a link to MSDN, but there was something like that there too. This is done in Windows to reduce cache line and memory page misses. So that the variable does not fall on the boundaries of the cache lines and page boundaries. In the stack, the flag is responsible for alignment, but they had an agreement with the data sections (it seems to have come from C)

That is to address potential performance and/or efficiency hazards. It doesn't affect the correctness of the code.

A variable of a certain size must be at an address multiple of this size.

... each variable in the Windows operating system should be located at addresses multiple of its size ...

I'm telling you, I can't find this article on MSDN.

Must != should.

I agree with "should". The "must" is not correct, there is no requirement.

Is it this one?

When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) will be generated

IF is_Windows_64_bit AND is_data_on_the_stack_for_an_api_call THEN
  align your stack or suffer crashes
ELSE
  do whatever you want, but prefer aligned over unaligned
ENDIF    

There are instructions, like MOVAPS, that require alignment.

Quote:

When the source or destination operand is a memory operand, the operand must be aligned on a 16-byte boundary or a general-protection exception (#GP) will be generated

There is also the AC flag which enforces all memory accesses to be aligned but Windows doesn't use it.

Interesting fact: you know the Window Class Name that needs to be put into WNDCLASS structure?
Recently, I was coding the x64 app and my UNICODE string for a class name was misaligned.
The string address was not divisible by 2 --- I had declared something as DB before the class name.
The application did not run until I corrected that.
Weird! This was never mentioned in any help files.

section '.data' data readable writeable

    glb_InputBuffer     dq 0
    glb_OutputBuffer    dq 0
    bool_Running        db 0    ; cause of misalignment
    txt_FrameClass      du 'TFrameWndClass',0

    ...

    lea     rsi, [my_wnd_cls]       ; local variable
    mov     [rsi + WNDCLASS.lpszClassName], txt_FrameClass
    invoke  RegisterClassW, rsi     ; crashes inside
    

section '.data' data readable writeable

    glb_InputBuffer     dq 0
    glb_OutputBuffer    dq 0
    bool_Running        db 0    ; cause of misalignment
    bool_Dummy          db 0    ; fixed misalignment
    txt_FrameClass      du 'TFrameWndClass',0

    ...

    lea     rsi, [my_wnd_cls]       ; local variable
    mov     [rsi + WNDCLASS.lpszClassName], txt_FrameClass
    invoke  RegisterClassW, rsi     ; no crash
    

... the wide string address must be aligned!

0x000003E6 ERROR_NOACCESS Invalid access to memory location.