I. filetime and systemtime formats the first time format I encountered was the filetime returned when the getfiletime function was used, which is a 64-bit (8-byte) structure. In the SDK documentation, the structure is described as follows: "The 64-bit value of the filetime structure indicates that the structure starts from January 1, 100 nanoseconds (One nanosecond is one thousandth of a second) is the value of the interval ". I don't know about you-my friends and relatives-all started to grow up when I heard "100 s. But fortunately, another time format of Win32 eliminates this problem. This format is systemtime. It is a structure that contains members such as year, month, day, hour, minute, second, And microsecond, and an API function filetimetosystemtime is used to convert filetiem format into systemtime format. Of course, if you want to know whether it is a leap year, Ji and so on, you have to manually switch. Every time I run the code using the getfiletime and filetimetosystemtime functions, I always find that the time is several hours less than the correct time. Why? Finally, I realized that when I installed Windows NT and 95, I once told the system where I live. In Win32, filetime is always Greenwich Mean Time (UTC ). Using UTC, you will find that the actual time is only 2 in Nashua, New York, and the time is 7 in Greenwich Mean. It would be terrible to let programmers check and correct each filetime. This is why Win32 provides the filetimetolocaltime function. Call filetimetolocalfiletime before calling filetimetosystemtime, which facilitates the time zone correction of filetime. Ii. MS-DOS format
The third format that depicts time is an old-fashioned MS-DOS format. In this format, the date and time are stored independently in two double words. Because there is only 16 bits, the annual value is the difference from that in 1980. Moreover, the time precision of this format is 2 seconds. If you choose to use this format, the filetimetodosdatetime function is indispensable. How can I think of this time format? Sorry, when I was developing the depends program, I didn't expect to use the systemtime format at first. So until I realized this problem, all versions of depends convert filetime to MS-DOS format. Iii. timestamp in PE files. The fourth time format is not seen in our common API documents. In Win32 executable files, the PE File Header (image_file_header) contains a DWORD field timedatestamp. It is the number of seconds since, January 1, January 1, 1970, GMT. Timedatestamp is set by the connector (linker) and is also used in other parts of the PE file. Here, I want to admit a stupid mistake I made before. In my article peering inside the PE: a tour of the Win32 portable Executable File Format (MSJ March 1994) and book Windows 95 system programming secrets, I describe the timedatestamp field as the number of seconds that have elapsed since 4, January 1, December 31, 1969. I get this result because I set timedatestamp to 0 and run dumpbin to see when the conversion was made. Here I didn't take into account that dumpbin has helped me to convert the time into the current time zone of the Computer (my time zone will certainly not be the GMT time zone. So here I will correct this error again. Timedatestamp is quite useful in PE files. For example, if you change the date and time of a file in the file system, the timedatestamp remains unchanged. In this way, when you want to know when the file is created, the timedatestamp is relatively accurate (the premise is that the connector correctly sets it ). The only technology required for timedatestamp is how to convert it into a familiar time format. After consideration, I solve this problem in this way. The value of filetime and timedatestamp relative to a specific time point, respectively. If I can use filetime to describe timedatestamp, I can use the Win32 time function mentioned above to do anything I want to do. Therefore, I need to first convert January 1, January 1, 1970 to the filetime format, and then convert timedatestamp (in seconds) to 100 nanoseconds, finally, add the two values above to get the desired filetime format. To convert July January 1, 1970 to filetime, I first defined a systeimtime structure, and then left the July January 1, 1970 blank. Then, I only need to call systemtimetofiletime to get the filetime format. The conversion result is used in the depends code: 0x019db1ded53e8000. It is easy to convert the number of seconds to 100 nanoseconds: Just multiply by 10000000. Of course, the result will certainly exceed 32 bits, so be sure to force the multiplier to a 64-bit integer (_ int64 in VC ). Of course, if you want to save some trouble, you can use the ctime function in the C Runtime Library. 4. The longdt time in the Mac operating system is the same as that in filetime. This time is also an 8-byte data format and is also the Count of seconds relative to a time point. However, unfortunately, this time is different from filetime, Which is January 1, 1904 midnight. Inspired by the above article, I wrote a function that converts longdt TO THE filetime format:
| Function longdttofiletime (LDT: int64): filetime; var ft1904: filetime; st1904: systemtime; begin st1904.wyear: = 1904; st1904.wmonth: = 1; st1904.wday: = 1; st1904.whour: = 0; st1904.wminute: = 0; st1904.wsecond: = 0; st1904.wmilliseconds: = 0; systemtimetofiletime (st1904, ft1904); LDT: = LDT * 10000000; LDT: = LDT + (int64 (ft1904); filetimetolocalfiletime (filetime (LDT), filetime (LDT); Result: = filetime (LDT); end; |
