4 ms·
The only place where this is relevant for me is running old Windows games via wine. Wonder how wine is handling this? Might as well re-map the date for 32bit wi
by panzi 2y ago
The only place where this is relevant for me is running old Windows games via wine. Wonder how wine is handling this? Might as well re-map the date for 32bit wine to the late 90s/early 2000s, where my games are from. Heck, with faketime I can do that already, but don't need it yet.
- account42 2y agoWin32 doesn't use time_t internally and has had 64-bit FILETIME since Windows 95 (counting 100-nanoseconds since 1601) as well as 64-bit performance counters (ticks) which are often used by games. Similarly, SYSTEMTIME has a 16-bit unsigned year field so should be good for a while. There is also an older GetTickCount() with 32-bit times but it is less problematic since a) it counts (milliseconds) since system startup and b) it is typically used to determine the time between two points (e.g. one frame to the next) so wraparound is not as much of an issue. time_t is provided in the C-library but many Windows programs don't end up using it. The CRT also has had __time64_t for a long time now for this purpose. 16-bit Windows/DOS programs often use the FAT filetime format which can store dates until 2099. TL;DR Windows/Wine internally does not need to change anything for a long time. Of course inevitably some applications will use 32-bit time_t or other 32-bit integers to store timestamps internally and will require workarounds.