Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!ub.d.umn.edu!rutgers!ub!acsu.buffalo.edu From: cloos@acsu.buffalo.edu (James H. Cloos) Newsgroups: comp.sys.handhelds Subject: Today the subject is libraries (LONG) Keywords: libraries, finally Message-ID: <46387@eerie.acsu.Buffalo.EDU> Date: 15 Nov 90 03:47:24 GMT Sender: news@acsu.Buffalo.EDU Followup-To: comp.sys.handhelds Distribution: comp Organization: State University of New York @ Buffalo Lines: 123 Nntp-Posting-Host: lictor.acsu.buffalo.edu Yup, you guessed it; I spent the last few hours pouring over hex dumps of libraries, both created from directories by usrlib, and some from the bbs. Anyway, this is what I found out: (NB, each of these fields is individually reversed in memory; unlike the dir posting, I'll write these in readable format.) A library looks like this: #02b40 LIB header #nnnnn size of the library, incl this field. #nn the length of the lib's name, in chars (If the lib is unnamed, this is #00 and the next two fields are missing) asciiascii the name of the library #nn the length of the lib's name, again (Now back to always there mode :) #nnn the LIB's id number #nnnnn offset to hash table \ #nnnnn offset to message arry | offsets are from the start of #nnnnn offset to link table | the offset field #nnnnn ofset to config object / the data follows. Named xlibs are stored in the format: #000 or #8 000=ok in alg expressions, 8= not ok in algebraics #nnn lib's id number from above #nnn the xlib's member number the actual object, starting w/ a std type field. (You'll find that lib #002 (the usrlang commands) is stored this way also.) Unnamed xlib's are stored w/o the #000nnnmmm or #8nnnmmm header, so you just start w/ the type field. The config object is what is evaluated after each system halt, and is usually a program. To borrow from the usrlib doc file, make sure this DOES NOT LEAVE ANYTHING ON THE STACK OR DROP ANYTHING THAT WAS THERE. My assumption is that only a ram clear will fix the 48 if there is a lib installed that has a bad config obj, as the post-system-halt routines will probably crash each time you try one. The link table is a hex string (a la a binary integer, but with a max wordsize of 2^5 - 6 nybbles) (proof of that is left as an exersise for the reader). This hex string is 5 nybbles long per XLIB in the library, and each group of 5 nyb's forms an offset from the table to the beginning of the type field of each xlib. These offsets are signed, so if this table is after the actual XLIB's, the offsets will be the complement (as per the NEG key on a binary integer--I'm too tired to figure out if this is 1's or 2's ;) of the actual distance from the field to the XLIB. These are the only signed offsets I'm aware of so far, though maybe all offsets are, check your local saturn guru for details. ;) The message array is a simple array of strings. (Which have the format: #029e8 type of ARRY #nnnnn size of array, incl this field #02a2c type of data in general, #2a2c is string type #nnnnn number of dimentions #nnnnn number of elements in 1st dimention ... #nnnnn '' '' '' '' nth '' data Where data is sum(i=1,no_of_dims,no_of_elem_in_this_dim) elements of the type specified. In the case of strings, each of these looks like a 5 nybble size field (in nyb's incl itself) plus the ascii chars in the string.) This leaves the hash table. This is also a hex string. At the end of this hex string are 5 nyb pointers for each named XLIB which point to that XLIB's name. These names immediately precede the pointers. These offsets, though pointing backwards, are positive (or unsigned?), ie., #00020 would point 32 nybbles back from the start of itself. The names these point to are in the familiar global name format, ie a 2 nybble size field (in char's, excluding itself) followed by that many bytes of ascii (each of course in reverse nybble order). This is followed by a 3 nybble field of that XLIB's member number. Before this is a 5 nyb field that is the length, in nybbles, of itself, & each of the XLIB names (inlc that name's length field and number field). Before all this, in each of the lib's I've looked at, is 85 nybbles of mostly 0's. They seem to be 16 fields of 5 nybbles each (resonable thought) and there would seem to be on the order of 3 or so of these fields that contain any non zero data, this is usually only 2 nybbles. I presume they are some sort of offset, but to where (or from where for that matter) I've no idea. The CONFIG, MESSAGE, LINK, HASH, and each individual XLIB can be, so far as I can tell, in any order, so long as each is itself contiguous ;^) I would presume, however, that there is some performance penalty if they are all mixed around, as minor as that might be (though if you use a XLIB in such a library in a type loop, these penalties could amount to a noticable delay). (My compiler will use a standard order which is the easiest for me to put together. ;) I better leave now, before I go over 900 words; I've already passed 100 lines. Enjoy this info. & like the post on dir's, if you don't understand it, ask & someone (maybe even me) will try to explain it better. This *is* fun. Trust me. Really. Would *I* lie to you? Seriously. As much as this looks sarcastic, it isn't. I promise. BTW, the library: "04B20E10000066600000000000000000000577E" (in ASC format) is nothing but an unnamed lib, lib# = 666h = 1638d, w/o anything in it. ASC\-> will work on the string, resulting in : `Library 1638: ` on the stack (w/o the `'s of course). I'm not going to try installing it, as I don't feel like a mem lost just now. Could someone out there who has a handy archive try this and report on it? L8r, ffolks. -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <> THIS INFORMATION COMES WITHOUT ANY FORM OF WARRENTY, NOT EVEN IMPLIED ONES.