Done Get FILETIMEs with @WINAPI

[vefatica]

This is incorrect, because (I suspect) what's in buf is converted to an unsigned 32-bit integer. Could it be converted to something 64-bit instead?

v:\> echo %@winapi[kernel32.dll,GetSystemTimePreciseAsFileTime,buf]
30896176

 

[rconn]

No - result codes (in TCC and CMD) are 32-bit.

 

[vefatica]

No - result codes (in TCC and CMD) are 32-bit.

Hmmm. It's not a result code in the sense that it's the return value of a function; the API's return type is void. It's just something the function puts in buf. What TCC is displaying is, in fact, the actual FILETIME now divided by 2**32.

 

[vefatica]

What exactly is happening when I do this? My use of foo seems to be undocumented.

v:\> echo %@winapi[kernel32.dll,GetSystemTimePreciseAsFileTime,foo]
30896234

Whatever the last parameter, the API function is writing an 8-byte (64-bit) little-endian unsigned integer there. When I give foo, TCC decodes the first 4 bytes as a DWORD.

If I give buffer or abuffer, the function still writes the 64-bit FILETIME and TCC doesn't try to make it a number (understood).

But I can grab the actual bytes (abuffer) or WORDs (buffer) using @ASCII. and rebuild the 64-bit number. Either of these work and give the correct FILETIME now. First, using abuffer, second using buffer.

::agenow.btm
setdos /x-5678
set result=%@word[0-7,%@ascii[%@winapi[kernel32.dll,GetSystemTimePreciseAsFileTime,abuffer]]]
setdos /x+5678
set age=0
do i=0 to 7
    set age=%@eval[%age + (%@word[%i,%result] SHL (8*%i))]
enddo
echo %age

::agenow2.btm
setdos /x-5678
set result=%@word[0-3,%@ascii[%@winapi[kernel32.dll,GetSystemTimePreciseAsFileTime,buffer]]]
setdos /x+5678
set age=0
do i=0 to 3
    set age=%@eval[%age + (%@word[%i,%result] SHL (16*%i))]
enddo
echo %age

Here's a comparison of those two methods with @MAKEAGE, and _AGENOW (plugin).

v:\> echo %@makeage[%_utcdate %_utctime] & echo %_agenow & agenow.btm & agenow2.btm
132698327840000000
132698327841220836
132698327841238357
132698327841303037

Unfortunately, I can't turn off the special meaning of '%' (because I need it) so I figure the DIY method will fail if one of the bytes/WORDs is 37 ('%').

 

[Charles Dye]

Wasn't there some way to use @WINAPI with binary buffers? I seem to recall such a feature, but I can't find anything in the documentation. Maybe it's just my overactive imagination.