Re: [RosAsm example]

From: wolfgang kern (nowhere_at_nevernet.at)
Date: 06/18/04 

Date: Fri, 18 Jun 2004 13:37:17 +0200

"hutch--" wrote:

| wolfgang,

| This much I have seen from years of people trying to get around the
| fundamental architecture of a Window and its message handler is that
| it almost exclusively fails somewhere along the line. Where you are
| using a CreateWindowEx() function call to create the main window, the
| system architecture dumps the messages aimed at the window by both the
| system and the user interaction at an address set in the WNDCLASSEX
| structure for the RegisterClass API call and it does so with 4
| parameters loaded on the stack using STDCALL.

Yes,...

<the source code>
MainWindowProc: ;esp+00=ret +04=hdl +08=msg +0c=wP +10=lP
[return: 0] ;jmp to at the end
  pop D$return ;and reset stack for DefProc
  pushad ;ebx,ecx would be enough
 ;mov edx D$esp+020 ;whdl
  mov eax D$esp+024 ;msg
  mov ebx D$esp+028 ;wP
  mov ecx D$esp+02c ;lP
    cmp eax &WM_CHAR |jnz L7>>
    cmp bl 01b |jz EXIT ;[ESC]here is just DelObj and ExitProcess
[**]
Here I'd assume a bug as the stack may need to be restored before,
But as the crash ocure at start-up there might be another one too.
[**]
.... ;keys of interest handled here
.... ;all ignored jmp L9>>
valid_keys: call repaint |jmp L9>>
L7: cmp eax &WM_SYSCHAR |jnz L7> |call ALT_Key |jmp L9>
L7: cmp eax &WM_SYSKEYDOWN |jnz L7> |call ALT_Kbranch |jmp L9>
L7: cmp eax &WM_KEYDOWN |jnz L7> |call FKeyBranch |jmp L9>

;--------not needed for a single window:
;why should I message CLOSE/DESTROY.. to myself ??
;[ESC] = quit&terminate here.
;L7: cmp eax &WM_CLOSE |jnz L7>
; push D$esp+020 |call'USER32.DestroyWindow' |jmp L9>
;L7: cmp eax &WM_DESTROY |jnz L7>
; push 0 |call 'User32.PostQuitMessage'|jmp L9>
;'-------

L7: cmp eax &WM_PAINT |jnz L8>
         call MyCode ;this isn't a procedure
                         ;but calls several API funcions
[**] if I'd place a 'jmp L9>' here, it would paint endless

L8: ;parameters still on stack and remained unchanged
     popad |call 'User32.DefWindowProcA' |jmp L0>
L9: popad |xor eax eax
L0: add esp 010
     jmp D$return ;and this is the end of the procedure
</>

| You can process a number of things directly in the message loop but
| you must have somewhere to dump the unmodified messages sent to the
| Window and this is the last function in a WndProc that handles default
| message processing. The problem has always been that the guts of each
| windows version may be different and there is no other documented
| method of handling the default messages so even if you get a technique
| working on XP or server 2003 or whatever else, it will probably fail
| on another version.

Thanks Steven,
I think my (even uncommon) MainWindowProc keeps the stack in correct
order (except for the ESC-quit with the early but dirty EXIT yet),
so I suspect the Default-return of WM_PAINT behaves different on NT's.

Shall I change the message on stack after WM_PAINT handled?

__
wolfgang

Relevant Pages

  • Re: RDTSC instruction question on core 2 duo CPU
    ... then prints the 'GetThreadTimes' results to a console window. ... mov(eax, hThread); ... w.KillTimer(hWnd, 500); ...
    (alt.lang.asm)
  • Reliable process timing in multi-tasking environments
    ... then prints the 'GetThreadTimes' results to a console window. ... mov(eax, hThread); ... w.GetThreadTimes(hThread, Dummy, Dummy, KernelFT, UserFT); ...
    (alt.lang.asm)
  • Re: Fullscreen PPC
    ... timer handler and nothing in the WM_ACTIVATE handler, ... You select the window that you want to know about from the Windows List ... Paul T. ... // Resize the window over the taskbar area. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Child Window Creation
    ... your handler! ... painted until all posted messages have been pumped. ... but it was getting handled before the window painted. ...
    (microsoft.public.vc.mfc)
  • Re: Implement a SendMessage behaviour
    ... I know the call stack of a thread can't be empty but it was the simpliest way I found to explain the feature I needed. ... I meant I need as less as possible results of user actions in call stack of the thread that will run the new action. ... As soon as the next action is started, that's not a problem if the windows message queue receive some message as they will wait my current action ends to be proceed ... not in any way guarantee that by the time the message sent is actually processed that the window message queue is empty. ...
    (microsoft.public.dotnet.languages.csharp)