On Tue, 1 Oct 2024 00:56 +0100 (BST), John Dallman wrote:
In article <vdfdcj$2dsh2$7@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
On Tue, 1 Oct 2024 00:25 +0100 (BST), John Dallman wrote:
In article <vdf71h$2cn51$17@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
It's not being ignored. The Linux kernel added the option to build a >>>>> 32-bit kernel with time_t having 64 bits
The same has happened for Windows and Apple's operating systems.
A lot of the work for 2038 is already done.
They're not supporting 32-bit code any more. Linux is.
Apple only run 64-bit code on recent OSes, yes, but Windows 11 still
runs 32-bit applications, even though the OS is only available in 64-bit
form.
But those 32-bit Windows apps are not being rebuilt for 64-bit time_t. The option isn’t there.
On 2024-10-01, Lawrence D'Oliveiro wrote:
On Tue, 1 Oct 2024 00:56 +0100 (BST), John Dallman wrote:
Apple only run 64-bit code on recent OSes, yes, but Windows 11 still
runs 32-bit applications, even though the OS is only available in
64-bit form.
But those 32-bit Windows apps are not being rebuilt for 64-bit
time_t. The option isn’t there.
Is Windows really affected in the same way?
According to the last bullet item in [1], WINAPI does not rely on time_t *and* the parts that do have it have built with 64-bit time_t by default
for a while now?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 486 |
Nodes: | 16 (1 / 15) |
Uptime: | 148:48:51 |
Calls: | 9,659 |
Calls today: | 1 |
Files: | 13,708 |
Messages: | 6,168,027 |