Quote:
Originally Posted by Don_Adan
Which old software You want to fix? And for what?
Same bug/limitation was for HD partition sizes, it was defined as LONG not ULONG.
Then for older kicks You can see negative values as partition sizes.
For all partitions greater than 2GB.
Someone fixed old software which shows wrong partition sizes?
No. Except new programs or new program versions.
Same will be for 2GB limit for file sizes.
Newest programs can handle (show) file sizes as ULONG, even if this is buggy declared as LONG in dos.h.
This is called progress.
|
There is progress and there is learning to walk on broken glass and not minding the injuries, the loss of blood, the danger of infection and the pain...
Data structures succeed in shaping code more than code in turn manages to shape data structures. We are stuck with operating system components, on multiple levels, which were designed to use signed 32-bit integers to represent anything between quantities, positions and distances.
While the constraints imposed by having to use signed numbers are not beyond fixing and even clever workarounds, it is ugly business even trying to make progress.
New fixes for old code will not translate into more robust or predictable behaviour unless that old code is rebuilt from the source code, or maybe patched in the right places. Such fixes, for example if file size reporting is concerned, will have to work in context with the code that builds upon them. For example, the runtime library that ships with your 'C' compiler will expect signed integers for size and position information and glitch into undefined behaviour without even trying. You could fix that, but you would have to go over the runtime library source code (if you have it) with a microscope and somebody to assist you in verifying that the changes are sound. Sounds like
work to me (avoid it if you can). There is the potential that such fixes and workarounds will get you somewhere, and you better consider how much this effort will be worth it to you.
Retroactively changing data structures and APIs is unlikely to yield improvements because software just does not expect such changes to be possible. Furthermore, software and even operating system code, as a rule, practically never ever checks if the parameters for an arithmetic operation to perform are in the expected range, or if the operation results in an arithmetic overflow. Mostly, such code assumes that the parameter values will be in range because, for example, a storage device will never be so large that its size cannot be reliably represented by a signed 32-bit integer (largest disk size for a 1986 era Amiga was 26 * 512 * 8 blocks, i.e. 106,496 * 512 = 54 MBytes). Indeed, the Amiga operating system was not designed to be stable or resilient. There was just not enough RAM or ROM space available to make it so. Also, the burden to restart the system after even the nastiest avoidable crash was rather low (if you could stand the sound of the disk likely getting sawed in half by the Disk-Validator while the boot process was still in progress).
The "prime example" for that is the RAM handler which is expected to run out of available memory long before unchecked integer arithmetic overflows will start to bite. This was a reasonable assumption in 1986 and still is, but long before signed/unsigned 32-bit integer arithmetic trouble enters from stage left, you are already deep into undefined behaviour because RAM handler will have stopped making sense of its own bookkeeping information. This is the "default mode" for the Amiga default ROM file system, too, and reliably unreliable tools such as HDToolbox.
Up until fairly recently, HDToolbox did not know its own limitations and just went over the rails instead, corrupting your hard disk partition information like it was supposed to do that. The same can still be said about the Amiga default ROM file system. Same goes for the scsi.device and the trackdisk.device. Turns out you can ship an operating system if you just stop checking for so many error conditions, freeing up enough ROM space for everything to fit into it. This puts the burden on the developer to be extra cautious and make no mistakes whatsoever when writing the code, avoiding the conditions under which undefined behaviour will invariably result. Guess who knew that these rules applied or managed to apply them
So, what can you do? Make the software and the ROM code more resilient, have it validate the parameters it receives before blindly committing to them and making a mess. That is doable, but will invariably eat either RAM or ROM space like popcorn. Add new APIs and data structures which complement and extend the existing ones, avoiding the ambiguity that comes with signed/unsigned integer operations. This is what was done in the AmigaOS4 dos.library, which has replacements for the signed 32-bit-integer-constrained Examine/ExNext/ExAll functions, etc.
Invariably, you will have to go through the entire operating system and its tools & shell commands, cleaning them up. That takes the kind of grit and courage which is easily mistakable for stupidity
