• (nodebb)

    the process that's writing the files isn't setting the "last write time"

    TRWTF is that in fact, the process that's writing the files is setting the "last write" time, but explicitly to something invalid. (Or maybe if the system clock is wildly inaccurate, see below.)

    See, the mere fact of writing to the file is enough to make the OS underneath set the file's "last write" time to "now", so if that isn't happening, the only conclusion is that the process is deliberately setting it to something else.

    It's probably also a good idea to see what the file's last-written time actually is, since FileTimeToDosDateTime is specified as failing if the file time lies outside the range 1980-01-01 to 2107-12-31.

    So, the WTFs here....

    1. Someone thinking that updating the last write time on a file is something the application has to do itself.

    2. Your choice of : (a) A program that writes to a file and then sets the last-write time to an invalid value, or (b) The system clock being set to a value that's decades out of whack with reality. Or both.

    3. A function called FileAge that returns the time and date that the file was last written. "How old is this file?" "Three weeks ago next Wednesday at four o'clock in the afternoon."

  • (nodebb)

    That is not Pascal, that is actually Delphi. And yes, it will no longer work, because the code shown works only on not NT kernels - which is basically Windows 95/98 and ME if you are in a self-destructive mood. So even for Delphi the code is weirdly out of date and should not be run on modern Windows versions. I guess they didn't update to the latest version which was released somewhat in the mid-2000s.

    Addendum 2026-09-14 07:15: So the Real WTF is that they are using a compiler that produces code for a complete different OS.

  • (nodebb) in reply to MaxiTB

    Actually Delphi and C++ Builder are still being actively developed, just not under Borland, as they sold both to Embarcadero Technologies in 2008 and the last release was in March of this year.

  • (nodebb) in reply to MaxiTB

    And yes, it will no longer work, because the code shown works only on not NT kernels - which is basically Windows 95/98 and ME if you are in a self-destructive mood.

    https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Conditional_compilation_(Delphi) says no.

    The MSWINDOWS define means "any version of the Windows platform" as opposed to "WIN32" which is for 32-bit Windows environments / binaries, or WIN64 which is for 64-bit Windows environments / binaries. It has nothing to do with a hypothetical MSWINDOWS / MSWINDOWSNT split.

  • (nodebb)

    "The system clock being set to a value that's decades out of whack with reality." A Y2K bug perhaps? The code thinks it's 1926 right now?

  • Foo AKA Fooo (unregistered)

    "Let's see if you can spot what's wrong:"

    
{ Delphi / Kylix Cross-Platform Runtime Library                           }
{ System Utilities Unit                                                   }
{                                                                         }
{ Copyright (c) 1995-2001 Borland Softwrare Corporation                   }

    Indeed, I can.

    Granted, I've seen some crap from 1990s Borland, but mispelling their own company name?

  • Ow! My Legacy (unregistered)

    FAT filesystems have a 2 second modfication date resolution, so updates to files on that type of fs could appeared 'delayed'. I guess it depends on the filesystem driver.

  • (nodebb) in reply to n9ds

    The code thinks it's 1926 right now?

    I said "decades", not "a century". It could be as late as 1979 (which is decades away from us, 4.7 of them, to be precise) and still cause this to fail. Even the other extremity (2108 causing problems) is only 8.2 decades away from us.

    The thing is, the year in a DosFileTime is stored as a 7-bit unsigned bitfield, so is limited to (1980+) 0 to (1980+) 127 ===1980 to 2107. (It's a throwback to the days of MS-DOS.) The NTFS epoch is at the beginning of the 1600s, and its timestamps are just 64-bit offsets in units of 100 ns from the epoch.

    Addendum 2026-09-14 14:36: And what I meant was "something set the system clock to a ridiculous date".

  • (nodebb) in reply to gordonfish

    Haha, I think I'm aware of this, since I have a Borland pig resting on a shelf just left for decades ;-)

  • (nodebb) in reply to Steve_The_Cynic

    As I said in my post, the code shown is from the pre-NT version of Delphi and has nothing to do with the NT version and even less so with the current version - but that is another story with .net actually being modern Delphi, Borland totally getting ditched by Microsoft while playing ball leading up to .net and more interesting old history stuff no longer relevant except ofc if someone is using the wrong compiler for the wrong OS ;-)

  • fulton (unregistered) in reply to Foo AKA Fooo

    { Copyright (c) 1995-2001 Borland Softwrare Corporation }

    Indeed, "Softrare" would be the correct spelling.

  • p (unregistered) in reply to MaxiTB

    Borland totally getting ditched by Microsoft while playing ball leading up to .net and more interesting old history stuff no longer relevant

    It seems very relevant. The lesson is that you should never trust Microsoft, a lesson that people still keep re-learning over and over.

Leave a comment on “I Exist”

Log In or post as a guest

Replying to comment #704303:

Log Out

« Return to Article