This is the code behind the Win95 Kernel32.GetTickCount() ...
I dont have Win95 (just its kernel32.dll :)) and im not too familiar with the gs segment register -- is it a 16bit register? If so, why is GetTickCount always defined as a DWORD in all the various GetTickCount documentation? I know it's a DWORD in WinNT/2K/XP because they use this code:
So does Win95/WinME only return a 16-bit result for GetTickCount ?
Thanks very much for your time
:BFF76980 668E2DB4C2FBBF mov gs, [BFFBC2B4]
:BFF76987 65A100000000 mov eax, dword ptr gs:[00000000]
:BFF7698D 2BD2 sub edx, edx
:BFF7698F 8EEA mov gs, dxI dont have Win95 (just its kernel32.dll :)) and im not too familiar with the gs segment register -- is it a 16bit register? If so, why is GetTickCount always defined as a DWORD in all the various GetTickCount documentation? I know it's a DWORD in WinNT/2K/XP because they use this code:
:77E8692E BA0000FE7F mov edx, 7FFE0000 ;7FFE0000 = 32bit timer value
:77E86933 8B02 mov eax, dword ptr [edx]
:77E86935 F76204 mul [edx+04]
:77E86938 0FACD018 shrd eax, edx, 18 ;32bit result in eaxSo does Win95/WinME only return a 16-bit result for GetTickCount ?
Thanks very much for your time
This is reverse engineering, which is bad... This board isn't here to help you reverse engineer, nor is it here to help you understand reverse engineered software.
Having said that, it does return a 32 bit value.
It uses gs to point so some specific area of memory held over by the OS, and gs is 16 bits long. However, this is then used in conjunction with an address to point to an area of memory which is 32 bits long.
Just because the selector is 16 bits, it doesn't mean the data is also 16 bits. Otherwise everything would be 16 bit data, because cs:xxxx and ds:xxxx are used to point to the code segment, and data segments respectivly (and cs and ds are also 16 bit selectors).
Mirno
Having said that, it does return a 32 bit value.
It uses gs to point so some specific area of memory held over by the OS, and gs is 16 bits long. However, this is then used in conjunction with an address to point to an area of memory which is 32 bits long.
Just because the selector is 16 bits, it doesn't mean the data is also 16 bits. Otherwise everything would be 16 bit data, because cs:xxxx and ds:xxxx are used to point to the code segment, and data segments respectivly (and cs and ds are also 16 bit selectors).
Mirno
Thankyou very much for your explanation Mirno, that's the info I needed. I didnt think it was 'reverse engineering', I was just trying to figure out why my program was having problems on my friends Win95 box somewhere around where it called GetTickCount so i can only assume my problem lies there, and having a look at its 4 lines of code in kernel32 was all I could do as the API documentation wasnt helping at all. Forgive me :( , I understand the rules here and didn't think I was breaking them but I should've thought more carefully before posting from a deadlisting. I'll be sitting in the sin bin for the next ten minutes
Thanks again for your help kind sir it is very much appreciated
Thanks again for your help kind sir it is very much appreciated
Waddya mean 10 minutes, it would be at least 15 minutes normally. :tongue:
GetTickCount always returns a DWORD size number on everything from win95 to XP so it should be unproblematic to use.
If you are using it for timing, be aware that ring3 access can leave you with about 2 - 3% wander so its not all that accurate.
Regards,
hutch@movsd.com
GetTickCount always returns a DWORD size number on everything from win95 to XP so it should be unproblematic to use.
If you are using it for timing, be aware that ring3 access can leave you with about 2 - 3% wander so its not all that accurate.
Regards,
hutch@movsd.com