64-bit AmigaDOS operations?

[Minuous]

I know there is now support for >4Gb drives at the trackdisk.device level, however is there support for this via dos.library? Are >4Gb *partitions* supported or only >4Gb *drives*?

(I want to get the remaining free space on a partition in a >4Gb-compliant way. But if there is still a <4Gb-per- partition-limit then it's a non-issue, and would explain the lack of support for it in dos.library.)

If >4Gb partitions are *not* supported, does anyone know whether this will be remedied in OS4?

Thanks.

[Minuous]

ULONG NumBlocksFree;
unsigned long long NumBytesFree;
struct InfoData *id; /* assumed allocated and set up by Info() call */

NumBlocksFree = id->id_NumBlocks - id->id_NumBlocksUsed;
NumBytesFree = (unsigned long long) NumBlocksFree * id->id_BytesPerBlock;

Thanks, I will have to try this out; eventually I will make a version of Report+ with >4Gb support.

[/QUOTE]
>4GB drive usage is not hampered by whether the OS is 32-bit or 64-bit.

There is a limit for 32-bit setups for RAM, being 4GB, but that's because RAM is talked to and referenced differently to hard disks. I can't give you a definitive and correct explanation as to the why's and how's, because I don't know
[/QUOTE]

Sorry, I should have made the question clearer; I was not referring to whether the operating system is a 32- or 64-bit program, but rather whether 64-bit quantities are used as arguments in disk operations.

[Minuous]

Yes, sorry, it's scsi.device and not trackdisk.device of course...

[Minuous]

OK, SAS/C doesn't seem to support long longs, so I have ported the program to StormC 3.0.  All modules compile without errors/warnings, but it won't link, it says things like "Symbol _AllocVec is undefined", "Symbol _AllocAslRequestTags is undefined", etc. but only for some library calls, not for all of them.

This is a bit odd because the code compiled and linked fine under SAS/C. I am reasonably sure that I am using the right pragmas, etc.? So what else would be causing this problem? It was not mentioned in the section of the StormC manual about "Porting from SAS/C". Is there something obvious that I am overlooking?

How I determine what linker libraries are being linked in with the program? (I assume stormc.lib and amiga.lib are being inked, but there doesn't seem to be a way of checking and/or changing what linker libraries are included?) This wasn't explained in the manual either :-(

Thanks.

[Minuous]

Yes, I thought amiga.lib might have something to do with it, that is why I was wondering how to check what is being linked in...now I know: you just use the 'Add library' menu item to add them. It was crashing before whenever I tried this. But I reinstalled StormC and it seemed to work, this has also fixed the other problem about the pragmas, I think I was using the NDK includes rather than those that are provided with StormC.

I'm not using any printf()-style functions for the 64-bit output, I've written a custom function which inserts thousands separators, etc. as necessary. And the user is already able to choose to view sizes in bytes, kilobytes, megabytes, or blocks.

Thanks to all those who have helped out...

[Minuous]

Several days of trying to get StormC to compile and link correctly, then when it finally executes it crashes instantly and the debugger does not even correctly show the location of the fault. I don't have the time or inclination to fix bugs which were introduced by StormC, whereas it worked perfectly under SAS/C.

So until H&P fix their lame compiler I will be using SAS/C. And since SAS/C doesn't support long longs neither will Report+.