Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Tue, 1 Oct 2024 10:57:25 +0300
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <20241001105725.0000771d@yahoo.com>
References: <vd9udm$1dgsp$9@dont-email.me>
	<memo.20240929205155.19028a@jgd.cix.co.uk>
	<vdcusa$1unhf$4@dont-email.me>
	<20240930111505.000018a3@yahoo.com>
	<vdffvs$2ec8o$3@dont-email.me>
	<vdg1e5$2k7ph$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 01 Oct 2024 09:56:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="310e328aa2bec287637029b107cc8443";
	logging-data="2791374"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+L/63oTOETL6m8DqWkKDg/auZ9YHS1UXA="
Cancel-Lock: sha1:PSzmLGLR9r2n1mEL0AZMTvB2CyA=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 4037

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:
> >  =20
> >> On Mon, 30 Sep 2024 01:28:42 -0000 (UTC)
> >> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> >> =20
> >>> Also the fact that those =C3=A2=E2=82=AC=C5=9364-bit=C3=A2=E2=82=AC=
=C2=9D APIs are not entirely
> >>> =C3=A2=E2=82=AC=C5=9364-bit=C3=A2=E2=82=AC=C2=9D ... =20
> >>
> >> They are entirely 64-bit. =20
> >=20
> > <https://arstechnica.com/gadgets/2018/05/microsoft-learn-from-apple-ii/=
2/>:
> >=20
> >      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. =20
>=20
> 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.
>=20
> The second potential issue is with the definition of LARGE_INTEGER:
>=20
> 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?
>=20

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=20
> little endian, so that is much less of a problem, and the docs tell
> you to
>=20
> "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."
>=20
> Yeah, not too pretty, but also not a real/important problem.
>=20
> Terje
>=20