unresolved ERROR_INVALID_WINDOW_HANDLE at the end of program.

[donkey]

Hi Dogim,

Because all of this takes place in USER32.DLL it is only conjecture on my part. It is not very safe to place breakpoints in system DLLs (and it is certainly very unsafe to play around with the TIB) so I had trouble examining the stack to find the call address and handle and consequently could not be absolutely sure about what the call was doing. It checks the return for a signature 0xDCBAABCD, at least I am assuming its a signature since it is not a number that would be normally produced (like 0xBAADF00D). That signature is tied to the MUI and the next code executed is directly related to the MUI. For that reason, I think that even though I might have a few details wrong, the general concept is probably right. If I do have something wrong it is probably what the call is doing, it may call a function that tries to signal a window and returns 0xDCBAABCD if ERROR_INVALID_WINDOW_HANDLE thrown.

By the way, looking at the code and the fact that you are using PUSH/PUSH/CALL, you are going to have huge problems if you want to build your application for 64 bits. Since Win32 uses STDCALL the PUSH/PUSH/CALL is fine, however when you build with Win64 the calling convention is FASTCALL and PUSH/PUSH/CALL will fail. You should use INVOKE at all times when calling the API if you think you might one day port the code to 64 bits.

Edgar

[Dogim]

Hi Dogim,

Because all of this takes place in USER32.DLL it is only conjecture on my part. It is not very safe to place breakpoints in system DLLs (and it is certainly very unsafe to play around with the TIB) so I had trouble examining the stack to find the call address and handle and consequently could not be absolutely sure about what the call was doing. It checks the return for a signature 0xDCBAABCD, at least I am assuming its a signature since it is not a number that would be normally produced (like 0xBAADF00D). That signature is tied to the MUI and the next code executed is directly related to the MUI. For that reason, I think that even though I might have a few details wrong, the general concept is probably right. If I do have something wrong it is probably what the call is doing, it may call a function that tries to signal a window and returns 0xDCBAABCD if ERROR_INVALID_WINDOW_HANDLE thrown.

By the way, looking at the code and the fact that you are using PUSH/PUSH/CALL, you are going to have huge problems if you want to build your application for 64 bits. Since Win32 uses STDCALL the PUSH/PUSH/CALL is fine, however when you build with Win64 the calling convention is FASTCALL and PUSH/PUSH/CALL will fail. You should use INVOKE at all times when calling the API if you think you might one day port the code to 64 bits.

Edgar

This stuff is very interesting to me, the pushes  calls  is  just a way for me to understand what's going on under the hood,and i have been told that if i wanted to become a good asm programmer , i would have to peek under the hood,invoke speaks for itself and i am using it at the moment, but i wanted to see under the hood what was going on, i know you don't really need to peek under the hood to program in assembly language, but it just interest me to know, just as i had to learn how  the stdcall really works (eg pushing and poping  influence on the ESP register and how the stack works ) ,for now i,m going to lean on the 32 bit programming just as a learning stage, a preparation for the 64 bits programming, but remember i,m starting from scratch no programming experience whatsoever , and loving asm,as for  the above error, i will check into it as i get more experienced  :green

[donkey]

as for  the above error, i will check into it as i get more experienced  :green

The error is thrown by Windows so you have no control over it and no way to fix it, it happens after your process has finished so it has absolutely no effect at all on what you want to do. I think you'll find that as you get more experienced you will find yourself ignoring this type of thing (as I normally do) because there are a lot of other things you have to worry about that actually affect the execution of your programs. :wink

[Dogim]

The error is thrown by Windows so you have no control over it and no way to fix it, it happens after your process has finished so it has absolutely no effect at all on what you want to do. I think you'll find that as you get more experienced you will find yourself ignoring this type of thing (as I normally do) because there are a lot of other things you have to worry about that actually affect the execution of your programs. :wink

Thanks Edgar  :U