Talk:83Plus:OS:Variable Storage in the User Archive

Application size

BrandonW had this to say on the page:

<BrandonW> That "401Ch" thing for the app size, that's completely wrong.
<BrandonW> You have to use the field search routines to find it.
<BrandonW> Just because it's at 401Ch on one doesn't mean it'll be there on another.

It'd be nice if someone who know about this sort of thing to explain how to do this in more detail. For that, we need more general information on parsing headers. Dr. D'nar 22:17, 10 October 2009 (UTC)

As far as I know, every fields in app header (save for the date stamp) start with $80 and a byte whose first nibble indicate field type and second nibble indicate field size. The only exception appears to be the two fields of size four for which the "size nibble" if F... Some investigation in the OS implementation of field search might clarify this... User:fullmetalcoder 14:59 13 October 2009 (GMT+2)

The boot code provides lots of routines for searching through app headers (83Plus:BCALLs:805A, 83Plus:BCALLs:805D, 83Plus:BCALLs:8075, 83Plus:BCALLs:80AB, ...) In fact, the OS uses these boot code routines whenever it needs to find data in an app header, certificate, or the OS header.

It is absolutely not safe to assume anything about the addresses or lengths of app header fields, apart from the fact that the header is required to be at most 128 bytes in total (so that it fits in a single link packet.) As I recall, WabbitSign provides some excellent examples of how not to read app headers.

FloppusMaximus 02:09, 14 October 2009 (UTC)

It is safe enough to assume understanding of the "field metadata" byte however. I had figured out most of its meaning, just did not know about the extra two possibilities (word and byte sizes indicated by E and D lower nibble respectively but I finally found them in BootFree source so I can write bcall-free app search routines now yay!)User:fullmetalcoder 22:18 26 October 2009 (GMT+1)