Quote:
Originally Posted by Don_Adan
This is easy, if this LONG is equal (-1) $ffffffff, then this is extended FileInfoBlock structure.
|
That doesn't make applications work that expect (correctly so) a LONG there. They will understand this as -1, with whatever consequences this may have. The interface is "this is a LONG", like it or not, and existing programs have been implemented under the assumption that it is a LONG, with whatever consequences this has - for example, using signed comparisons.
All these ideas would work if you would have a living software ecosystem where you could tell authors "please recompile your software", but we don't. This design is *stuck*. You can create a new "Examine64()/ExNext64()" with a new fib structure, but that does not say what legacy applications see with Examine()/ExNext() on a large file. There are only bad options - either fail, or report a wrong result, again with very little gains for practical Amiga applications. A 4GB file on such an old system? What for?
Quote:
Originally Posted by Don_Adan
1st. Expansion library must be available to close like every standard Amiga library.
|
Expansion library *can* be closed. It cannot be flushed, and that is quite like *every other ROM-based library* (but unlike intuition). Neither graphics, dos, exec can be flushed. What for?
Quote:
Originally Posted by Don_Adan
2nd. Allocaction memory must be changed from chip mem (D1=2) to any mem (D1=1).
|
Expansion is allocated with MEMF_ANY. Of course it is. The only reason why it pops up in chip memory *on some machines* is because there is no other memory available at the time expansion is initialized, and expansion is responsible for configuring additional memory. The reason why the Blizzard 1230 has *also* exec in chip memory is because it does not have autoconfig memory at all. Its fast RAM is some kind of hacky "P5" construction which is likely added through a resident module in the debug ROM, and that is initialized after expansion and exec. If things had been done properly, at least exec would be in fast ram and we would not have this thread.
Quote:
Originally Posted by Don_Adan
Then first opening will be for chip mem, and after closing this lib. Expansion.library will be opened in fast mem (if available).
|
Which does not work, because it still needs access to the scanned expansions, which it won't.
Anyhow, this is again one of these pointless discussions. a) this is not the AmigaOs development forum, b) I'm not an AmigaOs developer, c) the ratio between "investment of time" is no useful ratio to the result (saving less than 1K of chip RAM on some systems). expansion, in particular, is very hard to debug because it is so early in bootstrapping the system, and the chance for breaking anything for saving so little RAM is quite high. If there is any advice to give then that: "By all means, do not touch expansion without really good reason", and this is not even a mediocre reason. It is close to "no reason at all".