Talk:83Plus:OS:Variable Storage in the User Archive - Revision history

Fullmetalcoder: /* Application size */

2009-10-26T21:21:37Z

‎Application size

FloppusMaximus at 02:09, 14 October 2009

2009-10-14T02:09:24Z

Fullmetalcoder: /* Application size */

2009-10-13T13:01:36Z

‎Application size

Fullmetalcoder: /* Application size */

2009-10-13T13:01:20Z

‎Application size

Dr. D'nar at 22:17, 10 October 2009

2009-10-10T22:17:53Z

Dr. D'nar: Application size

2009-10-10T22:17:34Z

Application size

New page

== 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.

← Older revision		Revision as of 21:21, 26 October 2009
Line 13:		Line 13:
	: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.		: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.
	:[[User:FloppusMaximus\|FloppusMaximus]] 02:09, 14 October 2009 (UTC)		:[[User:FloppusMaximus\|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)

← Older revision		Revision as of 02:09, 14 October 2009
Line 9:		Line 9:

	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)		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.
		+	:[[User:FloppusMaximus\|FloppusMaximus]] 02:09, 14 October 2009 (UTC)

← Older revision		Revision as of 13:01, 13 October 2009
Line 8:		Line 8:
	[[User:Dr. D'nar\|Dr. D'nar]] 22:17, 10 October 2009 (UTC)		[[User:Dr. D'nar\|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:~~fuulmetalcoder~~]] 14:59 13 October 2009 (GMT+2)	+	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)

← Older revision		Revision as of 13:01, 13 October 2009
Line 7:		Line 7:
	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.		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.
	[[User:Dr. D'nar\|Dr. D'nar]] 22:17, 10 October 2009 (UTC)		[[User:Dr. D'nar\|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:fuulmetalcoder]] 14:59 13 October 2009 (GMT+2)

@@ Line 2: / Line 2: @@
 BrandonW had this to say on the page:
-<BrandonW> That "401Ch" thing for the app size, that's completely wrong.
+ <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> 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.
+ <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.