Win-64 Alternate method of populating WNDCLASSEX

Index > Tutorials and Examples > Win-64 Alternate method of populating WNDCLASSEX

Author

Thread

TightCoderEx

Joined: 14 Feb 2013
Posts: 58
Location: Alberta

TightCoderEx 02 Dec 2018, 01:05

In this example, the part that is actually different (first 12 instruction) from that of other methodologies would be negligible in 32 bit as we're talking about 40 bytes vs 31. However, as WNDCLASSEX is significantly larger in 64 bit, a 58% savings is realized, but the caveat to that would be the declaration could be overlapped, in effect making this example 42% larger in overall overhead.

Code:

temp
  wc WNDCLASSEX sizeof.WNDCLASSEX,0,WindowProc,0,0,NULL,NULL,NULL,COLOR_BTNFACE+1,NULL,_class,NULL

Where temp and wc point to the same place.
In any event, whenever possible I like using the stack, especially for volatile data.

Code:

  STYLE  equ CS_VREDRAW or CS_HREDRAW or CS_OWNDC or CS_BYTEALIGNCLIENT or CS_BYTEALIGNWINDOW

; Build a WNDCLASSEX structure on the stack.

        xor     ecx, ecx
        push    rcx                     ; <hIconSm>
        push    ClassName               ;  lpszClassName
        push    rcx                     ; <lpszMenuName>
        push    COLOR_BTNFACE-1         ;  hbrBackground
        push    rcx                     ; <hCursor>
        push    rcx                     ; <hIcon>
        mov     edi, esp
        push    rax                     ; hInstance
        push    rcx                     ; cbWndExtra & cbClsExtra
        push    MainWndProc
        mov     rax, STYLE * 0x100000000 + sizeof.WNDCLASSEX
        push    rax

    ; Now remaining values denoted by <...> can be retrieved and written to thier
    ; appropriate positions.

        sub     esp, 32                 ; Shadow space
        mov     edx, IDI_APPLICATION
        call    [LoadIcon]
        stosq                           ; Save @ hIcon
        mov     [edi+32], rax           ;        hIconSm
        xor     ecx, ecx
        mov     edx, IDC_ARROW
        call    [LoadCursor]
        stosq                           ; hCursor

        ; If required loading menu would go here but RDI would have to be bumped
        ; over hbrBackground

        mov     ecx, esp
        add     ecx, 32                 ; Points to base of WNDCLASSEX
        call    [RegisterClassEx]
        add     esp, 32                 ; Kill shadow space
        test    eax, 0xffff
        jnz     @F

        xor     ecx, ecx                ; Use desktop window
        mov     edx, ErrReg             ; Error text
        mov      r8, ApplName           ; Windows Caption text
        mov      r9, MB_ICONSTOP or MB_OK or MB_APPLMODAL
        call     [MessageBox]
        stc
        jmp     ErrEx

    @@:

I tried to find it again, but if memory serves me, ATOM is defined as a 16-bit value so my TEST shouldn't break. Even if it isn't, I'm pretty sure the LSW will still be non-zero if the value is a DWORD.

02 Dec 2018, 01:05

bitRAKE

Joined: 21 Jul 2003
Posts: 4020
Location: vpcmpistri

bitRAKE 02 Dec 2018, 10:51

The class ATOM is word sized, and can even be used to create the window. Why not TEST AX,AX? The only concern I have with the code is that RSP is not always 32-bit -- mostly it can be, but there is no guarantee.

In the past, compact window creation was done by setting a single bit in DLGTEMPLATE (WS_POPUP is bit 31 - nothing else is needed) and calling DialogBoxIndirectParamW. It seems like you are trying to do something more general.

Code:

    entry $
    pop rax                             ; 5A                align stack, lol
    mov ecx,[rcx]                       ; 8B09              HINSTANCE #32#
    lea rdx,[DlgMain]                   ;                   DLGTEMPLATE
    xor r8,r8                           ; 4D 31C0           HWND_DESKTOP
    lea r9,[DialogFunc]                 ; 4C 8D0D D5FFFFFF
    ; LPARAM on stack (0)
    call [DialogBoxIndirectParamW]      ; FF15 49000000
    xchg ecx,eax                        ; 91
    call [ExitProcess]                  ; FF15 52000000

The above would be in the extreme case - very little initialization code. The default dialog message pump is sufficient for most programs.

Description:	build with fasmg	Download
Filename:	DlgMain64.zip
Filesize:	1.4 KB
Downloaded:	783 Time(s)

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup

02 Dec 2018, 10:51

TightCoderEx

Joined: 14 Feb 2013
Posts: 58
Location: Alberta

TightCoderEx 02 Dec 2018, 15:09

test ax,ax is definitely a better alternative and code has been changed to reflect that. It's too bad API didn't sign extend to 32 bits, then test eax,eax could have been used.

I wasn't able to assemble "DlgMain" as ZIP is missing format/format.inc.

This was helpful, as some time ago I had played around with passing this to linker and even modifying PE, but hadn't read documentation yet to see how it works with FASM. This did make object file 24% smaller although I do realize it hasn't optimized application in any way.

Code:

format PE64 GUI 6.0 at $10000 on "NUL"
stack 1000h,1000h
heap  1000h,1000h

It's been 10 yrs or so since I've played with Win applications, but when I did use dialog boxes, it was the predefined ones like file, font, color selection. There was an issue I ran into with DialogBoxParam though, and if I remember correctly is was subclassing controls in the window. I'm not sure though.

I'm attaching the entire source as it exists to date and you'll notice the stack stays at least QWORD aligned and when shadow space is required, then PAGE (128 bit) aligned.

Description:	File is work in progress as it does not create main window yet and fall into message pump.	Download
Filename:	PhraseG.ASM
Filesize:	6.18 KB
Downloaded:	777 Time(s)

02 Dec 2018, 15:09

bitRAKE

Joined: 21 Jul 2003
Posts: 4020
Location: vpcmpistri

bitRAKE 04 Dec 2018, 00:56

Oh, DlgMain is built with FASMG - it's in the regular download - no other fancy includes.

Dialog boxes should be able to create any controls registered in the application or global space. Yet, they are themselves a subclass of a standard window. So, I can see how their blocking of regular window functionality might change the way another control is designed to function. If small or reuse of existing code is the goal then dialogs offer a model one can design for.

04 Dec 2018, 00:56

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum