Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: is Vax addressing sane today
Date: Tue, 1 Oct 2024 07:35:17 +0200
Organization: A noiseless patient Spider
Lines: 68
Message-ID: <vdg1mm$2k9bc$1@dont-email.me>
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>
 <3923aa023364c220111ac7e0a7400727@novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 01 Oct 2024 07:35:18 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0681247b7d69e91050c87002c4a95869";
	logging-data="2762092"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/D4vL/cC2JKZ2/5MSKjy8MkrBF3Zw7/C82q+cc8pGkiQ=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.19
Cancel-Lock: sha1:X80EtbB7UwtDTeQgzsg9ui/Uy6k=
In-Reply-To: <3923aa023364c220111ac7e0a7400727@novabbs.org>
Bytes: 3736

MitchAlsup1 wrote:
> On Tue, 1 Oct 2024 0:33:01 +0000, Lawrence D'Oliveiro wrote:
>=20
>> 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 =C3=A2=E2=82=AC=C5=9364-bit=C3=A2=E2=82=AC=C2=
=9D APIs are not entirely=20
>>>> =C3=A2=E2=82=AC=C5=9364-bit=C3=A2=E2=82=AC=C2=9D ...
>>>
>>> They are entirely 64-bit.
>>
>> <https://arstechnica.com/gadgets/2018/05/microsoft-learn-from-apple-ii=
/2/>:=20
>>
>>
>> =C2=A0=C2=A0=C2=A0 Another example; Win32 has a function for getting t=
he size of a
>> =C2=A0=C2=A0=C2=A0 file. File sizes on Windows are limited to 2^64 byt=
es, and so they
>> =C2=A0=C2=A0=C2=A0 need a 64-bit integer to be expressed easily. But t=
he API call to
>> =C2=A0=C2=A0=C2=A0 get the size of a file doesn't give you a 64-bit va=
lue. Instead,
>> =C2=A0=C2=A0=C2=A0 it gives you a pair of 32-bit values that have to b=
e combined in a
>> =C2=A0=C2=A0=C2=A0 particular way.
>=20
> As long as you can embed the API function in a macro that performs
> said combining, it's all OK.
>=20
>  =C2=A0=C2=A0=C2=A0 uint64_T filesize =3D GetFileSize64( whatever );

As I wrote in my other post, the API is in fact directly usable as-is on =

any compiler with 64-bit support.
>=20
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For 32-bit Windows, that's sor=
t of understandable;
>> =C2=A0=C2=A0=C2=A0 32-bit Windows is, well, 32-bit, so you might not e=
xpect to be
>> =C2=A0=C2=A0=C2=A0 able to use 64-bit integers. But if you use the sam=
e API in 64-bit
>> =C2=A0=C2=A0=C2=A0 Windows, it still gives you the pair of numbers, ra=
ther than just
>> =C2=A0=C2=A0=C2=A0 a nice simple 64-bit number. While this made some k=
ind of sense on
>> =C2=A0=C2=A0=C2=A0 32-bit Windows, it makes no sense at all on 64-bit =
Windows, since
>> =C2=A0=C2=A0=C2=A0 64-bit Windows can, by definition, use 64-bit numbe=
rs.
>=20
> Why would you want a 32-bit application to be able to use files
> of 2^64-bits in size ???

Why not? I had both partition and DVD image files larger than 4 GB well=20
before I had Win64, but I still wanted to be able to get my du (disk=20
use) utility to work.

Terje

--=20
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"