Build date

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is there a way for my EXE to tell when it was built?

The idea is to write a copyright date that shows "Copyright 2005-" and then
the date the EXE was last built

-baylor
 
baylor said:
Is there a way for my EXE to tell when it was built?

The idea is to write a copyright date that shows "Copyright 2005-" and then
the date the EXE was last built
Click to expand...

There's a 4-byte value beginning at byte 0x88 in all PE files which is
the timestamp. It's the number of seconds since 1970 that elapsed
before the file was created.
 
There's a 4-byte value beginning at byte 0x88 in all PE files which is
the timestamp. It's the number of seconds since 1970 that elapsed
before the file was created.
Click to expand...

Sorry, 0x88 might be true for some files, but definitely not for all.
The time stamp is relative to the PE exe header, which is after the
old DOS executable header and the DOS executable stub (which can have any
size).
The every segment has it's own timestamp.
For example Noepad.exe (Win2K, SP4) has the file timestamp at 0xE0.

See http://tuts4you.com/tutorials/PE-
Headers/Portable.Executable.File.Format.htm
or search for PE file format.
 
Mihai N. said:
Sorry, 0x88 might be true for some files, but definitely not for all.
The time stamp is relative to the PE exe header, which is after the
old DOS executable header and the DOS executable stub (which can have any
size).
The every segment has it's own timestamp.
For example Noepad.exe (Win2K, SP4) has the file timestamp at 0xE0.

See http://tuts4you.com/tutorials/PE-
Headers/Portable.Executable.File.Format.htm
or search for PE file format.
Click to expand...

I stand corrected - although according to the CLI spec, the DOS
executable stub must always be exactly 128 bytes. Whether the PE file
header comes immediately after the DOS stub is a different matter, of
course - and by the looks of it, adding 8 to the value specified at
position 0x3c is the way to go. (Mind you, that would suggest that the
file timestamp of notepad is at 0xe8, not 0xe0.)
 
I use the exe file date time:

Microsoft.VisualBasic.FileDateTime(Application.ExecutablePath).ToString("yyyy/MM/dd HH:mm:ss")
 
I stand corrected - although according to the CLI spec, the DOS
executable stub must always be exactly 128 bytes. Whether the PE file
header comes immediately after the DOS stub is a different matter, of
course - and by the looks of it, adding 8 to the value specified at
position 0x3c is the way to go. (Mind you, that would suggest that the
file timestamp of notepad is at 0xe8, not 0xe0.)
Click to expand...

You might be right about the CLI (meaning .NET ext files)
But for non-CLI executables this is definitely not true.
Notepad.exe was just an example. But I have seen applications where
the DOS executable was a full working version of the application.
An example is hiew (Hacker's View).

I thing the only 100% safe way is to get the .exe documentation
a do a proper parser. I not that difficult.
 
baylor said:
Is there a way for my EXE to tell when it was built?

The idea is to write a copyright date that shows "Copyright 2005-" and then
the date the EXE was last built
Click to expand...

According to Don Box (ISBN 0-201-73411-7) page 24, if you use an
AssemblyVersion attribute like

[assembly: AssemblyVersion("1.0.*")]

the third component of the version (major.minor.build.revision) is the
number of days since 2/1/2000.
 
Is there a way for my EXE to tell when it was built?
The idea is to write a copyright date that shows "Copyright 2005-" and then
the date the EXE was last built
Click to expand...

According to Don Box (ISBN 0-201-73411-7) page 24, if you use an
AssemblyVersion attribute like

[assembly: AssemblyVersion("1.0.*")]

the third component of the version (major.minor.build.revision) is the
number of days since 2/1/2000.
Click to expand...

And, since the revision is the seconds since midnight / 2:

/// <summary>
/// Returns build date/time, assuming Version was specified as AssemblyVersion("1.0.*") (or any other major.minor)
/// </summary>
/// <param name="V">A Version instance, with build date/time info in build.revision fields</param>
/// <remarks>
/// Date/time does not honor daylight savings time.
/// </remarks>
public static DateTime BuildDateTime(Version V)
{
return new DateTime(2000, 2, 1) +
new TimeSpan(V.Build, 0, 0, V.Revision * 2);
}

Note that the timestamp is currently 1 hr off - I **assume** this
means that it uses the system's offset from UMT and is not daylight
savings time aware. That for builds from midnight to 1 AM (DST) it will
show the previous day. But I haven't tested this. ;-)
 
Back
Top