Re: is Vax addressing sane today

On Tue, 1 Oct 2024 07:30:45 +0200
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

Lawrence D'Oliveiro wrote:

On Mon, 30 Sep 2024 11:15:05 +0300, Michael S wrote:
 

On Mon, 30 Sep 2024 01:28:42 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
 

Also the fact that those “64-bit” APIs are not entirely
“64-bit” ... 

>
They are entirely 64-bit. 

 
<https://arstechnica.com/gadgets/2018/05/microsoft-learn-from-apple-ii/2/>:
 
     Another example; Win32 has a function for getting the size of a
     file. File sizes on Windows are limited to 2^64 bytes, and so
they need a 64-bit integer to be expressed easily. But the API call
to get the size of a file doesn't give you a 64-bit value. Instead,
     it gives you a pair of 32-bit values that have to be combined
in a particular way. For 32-bit Windows, that's sort of
understandable; 32-bit Windows is, well, 32-bit, so you might not
expect to be able to use 64-bit integers. But if you use the same
API in 64-bit Windows, it still gives you the pair of numbers,
rather than just a nice simple 64-bit number. While this made some
kind of sense on 32-bit Windows, it makes no sense at all on 64-bit
Windows, since 64-bit Windows can, by definition, use 64-bit
numbers. 

 
The first issue here is that the original API defined the return
value as 32-bit, with an optional pointer to another variable to
receive the high part, but they came up with the GetFileSizeEx()
function decades ago, and that one gets the file size as a
LARGE_INTEGER. Nobody uses anything else afair.
 
The second potential issue is with the definition of LARGE_INTEGER:
 
It is as as you say defined as a pair of 32-bit values, overlayed
with a LONGLONG which can only work on a little-endian cpu since the
low part is followed by the high, right?
 

It seems to me that back when Windows still supported Big Endian
targets (PPC) there was #ifdef in the relevant header, so on PPC the
order of low and high parts was opposite to the rest of targets.
The remnants of that are more likely to be found in DDK headers than in
Windows SDK headers.

Turns out every single Win32-system in existence/in regular use is
little endian, so that is much less of a problem, and the docs tell
you to
 
"The LARGE_INTEGER structure is actually a union. If your compiler
has built-in support for 64-bit integers, use the QuadPart member to
store the 64-bit integer. Otherwise, use the LowPart and HighPart
members to store the 64-bit integer."
 
Yeah, not too pretty, but also not a real/important problem.
 
Terje