Re: is Vax addressing sane today

MitchAlsup1 wrote:

On Tue, 1 Oct 2024 0:33:01 +0000, 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.

 As long as you can embed the API function in a macro that performs
said combining, it's all OK.
      uint64_T filesize = 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.

 

                    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.

 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 before I had Win64, but I still wanted to be able to get my du (disk use) utility to work.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"