flat assembler
Message board for the users of flat assembler.
Index
> Windows > OpenGL.asm example |
Author |
|
WereMole 09 Oct 2016, 01:15
What causes the WM_PAINT message to be repeated called in the OPELGL.ASM example?
|
|||
09 Oct 2016, 01:15 |
|
revolution 09 Oct 2016, 03:01
Because the update region is never validated Windows will continue to send WM_PAINT messages.
|
|||
09 Oct 2016, 03:01 |
|
WereMole 09 Oct 2016, 11:49
Thank you. I did not understand the importance of the validation.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd145213(v=vs.85).aspx To verify this I modified the WIN64 > OPENGL example. I added three lines. The code was: proc WindowProc uses rbx rsi rdi, hwnd,wmsg,wparam,lparam mov [hwnd],rcx frame now: proc WindowProc uses rbx rsi rdi, hwnd,wmsg,wparam,lparam mov [hwnd],rcx mov [wmsg],rdx mov [wparam],r8 mov [lparam],r9 frame Then I changed the end of .wmpaint from: jmp .finish To: mov rcx,[hwnd] mov rdx,[wmsg] mov r8,[lparam] mov r9,[wparam] jmp .defwndproc The animation stopped. Thanks again |
|||
09 Oct 2016, 11:49 |
|
ml64 29 Apr 2021, 11:26
This trick doesn't work with MDI Child windows.
Are there any ways to force the WM_PAINT for MDI without using a timer? |
|||
29 Apr 2021, 11:26 |
|
ml64 04 May 2021, 14:52
bitRAKE wrote: If not timer then separate thread, or main message loop. Could also forward message from parent? Message from the Frame Window would be slower than the Main loop. The Main Loop is the best way, thanks! BTW, why not using RDTSC instead of GetTickCount() |
|||
04 May 2021, 14:52 |
|
revolution 04 May 2021, 15:16
RDTSC is a variable speed timer of unknown frequency. It can slow down and speed up relative to real time.
Because of that RDTSC is unreliable for anything that needs regular timing intervals. |
|||
04 May 2021, 15:16 |
|
bitRAKE 04 May 2021, 15:43
Code: mov rax,[dword 0x7FFE0008] ; use KUSER_SHARED_DATA.InterruptTime (May the 4th be with you. ) _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
04 May 2021, 15:43 |
|
revolution 04 May 2021, 23:25
bitRAKE wrote:
Test it in your own systems to see what their settings are. |
|||
04 May 2021, 23:25 |
|
bitRAKE 05 May 2021, 00:34
I thought someone wrote a nice app to display all the timers and their resolutions. Did a bit of a search and couldn't find it. Some days the internet feels like swiss cheese.
_________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
05 May 2021, 00:34 |
|
DimonSoft 05 May 2021, 07:24
bitRAKE wrote:
For the sake of completeness. Is it documented anywhere? I mean, it’s well-known but it might be subject to change in the future if undocumented. |
|||
05 May 2021, 07:24 |
|
revolution 05 May 2021, 12:08
No, these "tricks" are never documented.
Just use the normal APIs GetSystemTimeAsFileTime etc. They return the same value anyway. I think some people assume the extra call-ret overhead will break the whole system, and decide to make their code fragile instead by reading from fixed "magic number" addresses. Or maybe some people just like the idea of making code "clever". In a way it does look "cool", right? You have some obscure code that magically works, nothing could be cooler, right? If you want hacker cred then it might work out well. |
|||
05 May 2021, 12:08 |
|
bitRAKE 06 May 2021, 01:12
DimonSoft wrote:
Or check the DDK. For a verbose explanation of how it's changed over time: https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/ntexapi_x/kuser_shared_data/index.htm Microsoft has documented structures through NDAs in the past in order to avoid litigation (unfair business practice of using KUSER_SHARED_DATA in their software). Some of these "protected trade secrets" have become more public over time. As for the glorification of ignorance, I have very little to say about that: Code: if Elite_Hacker or Clever or Cool_Kid or Just_Sensible mov rax,[dword 0x7FFE0008] else call [GetSystemTimeAsFileTime] end if _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
06 May 2021, 01:12 |
|
Tomasz Grysztar 06 May 2021, 06:43
bitRAKE wrote: As for the glorification of ignorance, I have very little to say about that: (...) I would say the difference is whether you code for Win32, or for NT 3.50+ kernel. ___ * Even worse, I use GetSystemTime and SystemTimeToFileTime, to get it to work on pre-Win2000 systems, even Win32s. |
|||
06 May 2021, 06:43 |
|
bitRAKE 06 May 2021, 10:08
Even ReactOS has support for it:
https://github.com/mirror/reactos/blob/c6d2b35ffc91e09f50dfb214ea58237509329d6b/reactos/include/ndk/ketypes.h#L416 ...and Wine has it, too. Some replies should just be cut short, the later part of my previous reply added nothing to the discussion. It was not meant to imply that using the API is bad in any way. _________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
06 May 2021, 10:08 |
|
Furs 06 May 2021, 12:34
revolution wrote: I think some people assume the extra call-ret overhead will break the whole system, and decide to make their code fragile instead by reading from fixed "magic number" addresses. Anyway, since this thing is used by MS code, it's probably safe/stable to use. If they changed it, then it would break those (already compiled) apps. And obviously Wine has to do it to support them. |
|||
06 May 2021, 12:34 |
|
Tomasz Grysztar 06 May 2021, 12:59
Apparently there also were some 32-bit applications using the int 2Ah to get the time, and Windows developers went the extra mile to keep supporting it in 32-bit kernel.
|
|||
06 May 2021, 12:59 |
|
revolution 06 May 2021, 13:37
Furs wrote: ... it's probably safe/stable to use. Why all the hate for the API? |
|||
06 May 2021, 13:37 |
|
DimonSoft 07 May 2021, 10:54
revolution wrote: Why all the hate for the API? It usually stops when one encounters the case where they have to dig through their 5-years-old code that SUDDENLY!!!111 stopped working with next OS version. What could go wrong? |
|||
07 May 2021, 10:54 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.