4 ms·

This is a corner case which could have just as well occurred on Windows (or a similar kind of bug), though. It's not the expected usage.

by the_af 4y ago

shadowgovt 4y ago
The 2038 bug is definitely expected, and unlike in Linux, with its highly distributed and composable architecture, management of fonts on Windows is a responsibility of the monolithic operating system maintained by one company. It's not out of the realm of possibility, but I'd be a little startled if Windows hasn't already been gone over with a fine tooth comb for Y-2038 issues.
- lazide 4y ago
  Considering how many crazy bugs are getting introduced now in windows, I wouldn’t be that surprised.
- taeric 4y ago
  Pretty sure one of the things they did in windows land was to just stop supporting 32 bit software.
  - asddubs 4y ago
    but windows still supports 32 bit executables, I'm pretty sure?
    - taeric 4y ago
      You could probably guess I don't claim to be authoritative here. :D I just recall there was a story not long ago about them doing some hard decisions going into 64 bit. https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/compatibility-limitations-32-bit-programs-64-bit-system https://learn.microsoft.com/en-us/troubleshoot/windows-serve... seems to indicate that you should mostly expect it to work. Odds are high I just saw the headlines about how they are stopping 32 bit sales of their OS. Though, I couldn't tell you for sure what I was misremembering.
    - sgerenser 4y ago
      Windows stopped supporting 32-bit Windows (i.e., Windows 11 is 64-bit only). They still fully support 32-bit apps, of which a lot still exist. Visual Studio 2022 is the first version of Microsoft’s flagship IDE that is 64-bit, for example!
      - asddubs 4y ago
        yup, which is different from the claim that was made. TFA incidentally also was caused because of 32 bit software running on a 64 bit linux system.
    - rbanffy 4y ago
      Apps will still overflow if they try to parse a 64-bit Unix timestamp using a 32-bit integer. If that's the case, I imagine they'll break in interesting ways.
userbinator 4y ago
Windows' native API for dates consists of the types FILETIME and SYSTEMTIME which will handle 5-digit years, and even the old MS-DOS FAT timestamp goes up to 2107. The 2038 problem came from Unix and applications which use 32-bit Unix epoch time.
- int_19h 4y ago
  To be fair, there's no shortage of native Windows apps that use time_t instead of Win32 API.
- Asooka 4y ago
  It's entirely possible somewhere in the stack of a 32-bit Windows application sits a DLL that uses POSIX time, stat, etc. functions and will fail in a similar way.

This is a corner case which could have just as well occurred on Windows (or a similar kind of bug), though. It's not the expected usage.

by the_af 4y ago

This is a corner case which could have just as well occurred on Windows (or a similar kind of bug), though. It's not the expected usage.

shadowgovt 4y ago

The 2038 bug is definitely expected, and unlike in Linux, with its highly distributed and composable architecture, management of fonts on Windows is a responsibility of the monolithic operating system maintained by one company. It's not out of the realm of possibility, but I'd be a little startled if Windows hasn't already been gone over with a fine tooth comb for Y-2038 issues.

lazide 4y ago
Considering how many crazy bugs are getting introduced now in windows, I wouldn’t be that surprised.
taeric 4y ago
Pretty sure one of the things they did in windows land was to just stop supporting 32 bit software.
- asddubs 4y ago
  but windows still supports 32 bit executables, I'm pretty sure?
  - taeric 4y ago
    You could probably guess I don't claim to be authoritative here. :D I just recall there was a story not long ago about them doing some hard decisions going into 64 bit. https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/compatibility-limitations-32-bit-programs-64-bit-system https://learn.microsoft.com/en-us/troubleshoot/windows-serve... seems to indicate that you should mostly expect it to work. Odds are high I just saw the headlines about how they are stopping 32 bit sales of their OS. Though, I couldn't tell you for sure what I was misremembering.
  - sgerenser 4y ago
    Windows stopped supporting 32-bit Windows (i.e., Windows 11 is 64-bit only). They still fully support 32-bit apps, of which a lot still exist. Visual Studio 2022 is the first version of Microsoft’s flagship IDE that is 64-bit, for example!
    - asddubs 4y ago
      yup, which is different from the claim that was made. TFA incidentally also was caused because of 32 bit software running on a 64 bit linux system.
  - rbanffy 4y ago
    Apps will still overflow if they try to parse a 64-bit Unix timestamp using a 32-bit integer. If that's the case, I imagine they'll break in interesting ways.

userbinator 4y ago

Windows' native API for dates consists of the types FILETIME and SYSTEMTIME which will handle 5-digit years, and even the old MS-DOS FAT timestamp goes up to 2107. The 2038 problem came from Unix and applications which use 32-bit Unix epoch time.

int_19h 4y ago
To be fair, there's no shortage of native Windows apps that use time_t instead of Win32 API.
Asooka 4y ago
It's entirely possible somewhere in the stack of a 32-bit Windows application sits a DLL that uses POSIX time, stat, etc. functions and will fail in a similar way.