Another way to GetTickCount

[ecube]

Int 2Ah  :bg

Code Select Expand


.386
.model flat, stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\user32.inc
include \masm32\include\kernel32.inc
include \masm32\include\masm32.inc
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\user32.lib
includelib \masm32\lib\masm32.lib
.data?
bf1 db 512 dup(?)
.code
start:
invoke GetTickCount
mov ecx,eax
invoke dwtoa,ecx,addr bf1
invoke MessageBox,0,addr bf1,NULL,MB_ICONINFORMATION
invoke RtlZeroMemory,addr bf1,512
xor eax,eax
Int 2Ah
mov ecx,eax
invoke dwtoa,ecx,addr bf1
invoke MessageBox,0,addr bf1,NULL,MB_ICONINFORMATION
ret
end start


[PBrennick]

E^cube,
That is VERY interesting and a 'must remember.' I had no idea that we could still do that! Any time we can do something without using an API, we will produce faster code.  :U

Paul

[Synfire]

Beware of int 2Ah, int 2Eh, and the like. Calling API's through interrupts can be done (no doubt) but shouldn't as they change between builds (not just versions). In other words, just because an interrupt procedure works on one Win2000Pro SP4 build doesn't mean it'll work on another Win2000Pro SP4 build. So if you start using interrupts on windows, expect your code to break on a lot of computers. Being as your working with index zero you should be fairly safe to assume this one will always be there, at least until some guy at Microsoft decides to start reorganizing (and they do that from time to time), but if you start searching through the dll's to see what API's really trigger don't expect it o be the same between builds.

I thought about doing this before myself, I tried to speed up one of my applications by using interrupts directly rather than arsing with calls that merely trigger interrupts and return. When I passed the "optimized" version off to my friend, whom I was creating the version of my application for, it wouldn't run on his machine. This is when I found out that Microsoft doesn't wrap interrupts in procedures only for simplicity sake, but also because the interrupts change so often that without procedures to wrap them a lot of programs would be broken between builds. It also keeps them from having to standardize the way the interrupt table is laid out. They can change things around behind the scenes as much as they want without you needing to know, or care.

Regards,
Bryant Keller

[Ghirai]

Original article was posted on rootkit.com.

[ecube]

Original article was posted on rootkit.com.

Actually it's origin is from the book Windows NT/2000 Native API Reference, and I believe it's mentioned in another book I have, thanks for sharing you're a regular at rootkit.com though...

[Ghirai]

I know, but i automatically assumed that, because of the relative short time between your post and that post, you've seen it there :bg