From Newsgroup: comp.os.linux.advocacy

In comp.os.ms-windows.advocacy Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Tue, 12 May 2026 12:27:27 +0800, makendo wrote:

Given the conservativeness of Microsoft on technical decisions
back then (they even went for 32-bit longs on 64-bit platforms
at the C ABI level) ...

Which was a bloody stupid thing to do. Dave Cutler was supposed to be creating a ?New Technology? OS, supposedly to be portable across
multiple architectures from that point on into the foreseeable future.
Didn?t he notice that 64-bit architectures were already making an
appearance in the Unix world?

Note that makendo was referring to the C ABI. Within the Windows API,
64 bit integers were there all along, so both 32 bit and 64 bit programs
just specify whether they want a 32 bit or 64 bit integer. All that
happened with 64 bit was adding pointer size integer types (DWORD_PTR et
al.)

I'd quibble with the idea that POSIX was more forward looking at the
time. Compare time_t to FILETIME, for example - NT used 64 bit time on
a 32 bit system and didn't have a binary compatibility break to deal
with 2038. File sizes were also 64 bit from the start, whereas POSIX
ended up with _FILE_OFFSET_BITS and a different ABI for programs with
64 bit file size support. Linux moved from 16 bit UIDs to 32 bit in
2001 (another ABI break), etc, etc.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Sun, 24 May 2026 04:10:50 -0000 (UTC), malxau wrote:

Within the Windows API, 64 bit integers were there all along, so
both 32 bit and 64 bit programs just specify whether they want a 32
bit or 64 bit integer.

Not really, no. For example, there is a function to return a file
size, I think it is. It can cope with 64-bit sizes. But in the Win32
API, it returns the high half and low half as separate 32-bit
quantities. And it still does this even when running supposedly 64-bit
native code.

That’s the kind of stupidity I mean.

I'd quibble with the idea that POSIX was more forward looking at the
time. Compare time_t to FILETIME, for example - NT used 64 bit time
on a 32 bit system and didn't have a binary compatibility break to
deal with 2038. File sizes were also 64 bit from the start, whereas
POSIX ended up with _FILE_OFFSET_BITS and a different ABI for
programs with 64 bit file size support. Linux moved from 16 bit UIDs
to 32 bit in 2001 (another ABI break), etc, etc.

None of this was dictated or limited by POSIX. It simply gave
implementations the freedom to choose the appropriate sizes for each
of these types.

As you pointed out, 32-bit Linux used 32-bit time_t for a long time,
but now that it looks like such systems won’t disappear completely in
favour of 64-bit for some time yet, it makes sense to introduce a new
ABI with 64-bit time_t.

All these changes just needed a recompile with appropriate compiler
flags to choose different ABIs. All the necessary integer sizes are
handled natively in all cases, without the need for fudges as with
Windows.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

In comp.os.ms-windows.advocacy Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

Not really, no. For example, there is a function to return a file
size, I think it is. It can cope with 64-bit sizes. But in the Win32
API, it returns the high half and low half as separate 32-bit
quantities. And it still does this even when running supposedly 64-bit
native code.

It's true that GetFileSize returns two 32 bit values. GetFileSizeEx
returns a single 64 bit value. That API has been there since Windows
2000. (And I agree it should have been done sooner; the underlying NT
API is NtQueryInformationFile + FileStandardInformation, which used LARGE_INTEGER from the start.)

it makes sense to introduce a new ABI with 64-bit time_t...

All these changes just needed a recompile with appropriate compiler
flags to choose different ABIs. All the necessary integer sizes are
handled natively in all cases, without the need for fudges as with
Windows.

Windows added native 64 bit integers to LARGE_INTEGER without needing to
change ABIs or recompile. It was defined as a 32 + 32 struct so that 64
bit native types could be added in a compatible way once compiler
support was added, which happened around one year after the initial
Win32/NT API. Once the compiler supported it, 32 bit programs can just manipulate the 64 bit value.

It's true that not every API dealing with 64 bit values used
LARGE_INTEGER, and those APIs didn't last well; but LARGE_INTEGER was
always the design that the core components followed from day one.

Note that POSIX also ended up with structs that split values into 32 bit
types, such as timeval. Any interface that preceeds native 64 bit types
is going to look similar. What LARGE_INTEGER was doing was providing a migration path to a single integer when compiler support arrived.
That's not possible with things like timeval.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.linux.advocacy

On Sun, 24 May 2026 08:41:02 -0000 (UTC), malxau wrote:

Note that POSIX also ended up with structs that split values into 32
bit types, such as timeval. Any interface that preceeds native 64
bit types is going to look similar.

But in 1993, we were already seeing the introduction of 64-bit
architectures -- e.g. DEC Alpha. Windows NT supported Alpha from the
beginning, but it had to do it in a clunky way -- by running in 32-bit “TASO” mode, pretending it was only a 32-bit machine.

And weren’t they already talking about Itanium at that stage?

You’d think Microsoft would have been sufficiently farsighted as to
figure out there would be more of this sort of thing in the future,
not less.
--- Synchronet 3.22a-Linux NewsLink 1.2