Index
> Tutorials and Examples > 64 bit ScanMap |
| Author |
|
|
TightCoderEx 29 Jun 2013, 19:40
I've implemented the 64 bit version of this snipped and I'll probably stick with it, if for no other reason it make code more manageable. At least the way I'm doing it anyway.
Once I'm sure it functions as expected, especially for procedures that need post default processing, I'll document code a lot better. Code: ScanMap: push r9 ; lParam push r8 ; wParam push rdx ; Msg push rcx ; hWnd push rsi mov rsi, rax ; Pointer to windows message map lodsd push rbx mov rbx, rax ; Pointer to windows default procedure lodsd mov rcx, rax ; Number of messages in map @@: lodsd ; Get application defined message number cmp edx, eax lodsd ; Pointer to application defined handler jz .Handle loopnz @B @@: or rbx, rbx pop rbx pop rsi jnz .Subed pop rcx pop rdx pop r8 pop r9 jmp [ DefWindowProc ] .Subed: mov rcx, rbx pop rbx ; lpPrevWndFunc pop rsi pop rdx ; hWnd pop r8 ; Msg pop r9 ; wParam pop rax sub rsp, 48 mov [ rsp + 32 ], rax ; wParam jmp [ CallWindowProc ] .Handle: call rax jc @B ; Do default processing if specified add rsp, 48 ; Waste everything on stack xor rax, rax ret As I haven't created any sub or super classed windows, that part of the app hasn't been tested yet. Although not extensively for the rest, but short sessions of program hasn't crashed it yet.
|
|||||||||||
29 Jun 2013, 19:40 |
|
|
bitRAKE 29 Jun 2013, 21:21
The example ran well on Win7. Sometimes in sub-/super- classing it's beneficial to execute the default handler first, and then work with that result.
|
|||
|
29 Jun 2013, 21:21 |
|
|
TightCoderEx 30 Jun 2013, 03:11
revolution wrote: BTW: This example is incomplete. Can you please post a fully working test app to show it working. In the next day or so, I'll have an example of a subclassed EDIT control, which will be in part a way of testing the beginning of my library routines called I2A & A2I. This will be multifunctional INTEGER to ASCIIZ and vis versa respectively. |
|||
|
30 Jun 2013, 03:11 |
|
|
TightCoderEx 30 Jun 2013, 03:14
bitRake wrote: Sometimes in sub-/super- classing it's beneficial to execute the default handler first, and then work with that result. |
|||
|
30 Jun 2013, 03:14 |
|
|
sinsi 30 Jun 2013, 03:36
You should be using full 64-bit addresses, what happens if the exe is loaded higher than the 4GB limit?
|
|||
|
30 Jun 2013, 03:36 |
|
|
revolution 30 Jun 2013, 03:53
TightCoderEx wrote: Did the attached ASM file not work for you? |
|||
|
30 Jun 2013, 03:53 |
|
|
TightCoderEx 30 Jun 2013, 05:00
revolution wrote: But you still need to allow for 64-bit addresses in V2. In my 32 bit version I've even used 16 bit loads, which definitely would pose a problem with sub/super classed windows. In Win7, so far DLL entry points are within the 32 bit boundary, so I think I'm safe with what I'm doing. sinsi wrote: what happens if the exe is loaded higher than the 4GB limit Am I correct in assuming that as long as no one changes PE data, sections will start @ 40000H on 4k boundaries and top of stack will be @ 70000H? Did M$ do this to eliminate a lot of REX qualifiers and would have made porting XP to 64 bit a lot less work. Please understand, any responses I give that seem to be dismissal are not intended to be so, it's just I don't take Win32 or 64 very seriously. It is only because I've had to replace my Linux box with one that only has EUFI. My ultimate goad is to create a library of routines that will be conducive to my OS and to that end all of these bits of information become criteria by which I base my kernel and subsequent abstract layers to my system. Thanks gentlemen for you input, it does help in my ultimate design criteria, even though it won't be for Windows or Linux, but I do need to use something in initial development. With any luck I'll be able to use FASM in my OS. |
|||
|
30 Jun 2013, 05:00 |
|
|
revolution 30 Jun 2013, 06:03
TightCoderEx wrote: In Win7, so far DLL entry points are within the 32 bit boundary, so I think I'm safe with what I'm doing. Since you already acknowledged that this is not for optimisation (which is fine) then I can't see the advantage of writing code that is known to be against the spec. It only takes a moments to fix and get it right for all future applications. But having known mis-performing code and hoping for the best in the future seems to me like a bomb waiting to go off. |
|||
|
30 Jun 2013, 06:03 |
|
|
TightCoderEx 30 Jun 2013, 13:26
revolution wrote: But such behaviour is not guaranteed by the Win64 design. Sure, it works today, but what about tomorrow when MS send everyone a new update with a rewritten loader? Or what about Win8, or whatever the next version will be called, it might break there because of different characteristics. Agreed and even though I don't plan on doing anything serious at this point in time for W7 or 8, but if it does happen why complicate the matter by having fragments of broken code. |
|||
|
30 Jun 2013, 13:26 |
|
< Last Thread | Next Thread > |
Forum Rules:
|