***************************************************************************
Format of dos32 v3.5 executable              v1.0
by jonas lund aka whizzter of woorlic

(note: at the relase of wext i looked at this file again, there is info
        missing about the packing and the packing is not in the loader.
        next version might include an unpacked and this document will have
        info about the packing algo, thanks to Darkfiber for the unpacker)

things i dug out during a night just after midsummer(and some partying :)

***************************************************************************
Header of EXEC

Area:      Type:     Desc:

(-?)-(-1)  (stub)    Stubloader

 00-03      AsciiSTR  "Adam" - signature
 04-05      BCD       Extender version desired
 06-07      BCD       _??_Linker version used_??_
 08-11      DWORD     dos32 Executable data size (reloc+exec data)
 12-15      DWORD     dos32 Executable total size (header+exec+reloc)
 16-19      DWORD     Header size
 20-23      DWORD     Starting EIP
 24-27      DWORD     Size of startup mem (rounded to next 4k(4096) boundary)
 28-31      DWORD     Un-initialized data (stack pointer?)
 32-35      DWORD     Start of reloc table in exec(=size of exec data)
 ???

***************************************************************************
relocation table
---------------------------------------------------------------------------
ok, this is written at 3:30 in the morning so bear with my bad english
and possible errors
---------------------------------------------------------------------------
 the relocation table starts relative to the start of the executable data
 at a position given on location (32-35) in the executable header,
 and goes to the end of the file

 all relocations are linked so the next relocation is at last+value
 so for example if we would have relocations at:

 offset
   5
   10
   20
   50
   ..

 then the relocation table would have values like this:

 offset   value
   5        5    (added from start of exec (0))
   10       5    (5+5=10)
   20       10   (10+10=20)
   50       30   (20+30=50)
   ...      ...  ...etc..

 you get the picture..

---------------------------------------------------------------------------
 this would be nice, BUT.. oh no.. adam just HAS to make this table as small
 as possible so you will need to unpack it.
 the table is packed by checking how many bits are used and the number of
 bytes is never to high.

 7  lsig bits   = 1 byte
 14 lsig bits   = 2 bytes
 21 lsig bits   = 3 bytes
 .................etc..

 layout:
 data:             bitpos:
 4 least sig at    4-7
 3 most sig at     0-2
 more bytes flag   3

 confusing? .. luckily i was looking at the data in a hex editor :),
 i would not have figured it out otherwise.

 how to read?

 do this algorithm:(Pseudo)

 until all numbers finished
  {
   (totalvalue) +=(value & 0x3f) * (128^(bytes after this))
   next number
  }

 so if we just have 1 number for example:
  0x91 then we would get 0x19 as a real number, then 25 dec

  so 25*128^0=25

  just 25 then

 but if we have several it would be:

  for 0x99 0x20  we would get the 2 numbers, 0x19 (99 but with the more bytes flag masked off)
  and 0x2 (0x20)

  19 hex = 25 dec
  2  hex = 2  dec

  25*(128^1)=  3200
  02*(128^0)=     2
        total: 3202

 ... etc...

 confusing?
 well here is some examples

        (bitform: msig-lsig)

 packed(hex):  hex:  packed bits:                 unpacked bits:       dec:
   90          9      10010000                     00001001             9
   91          19     10010001                     00011001             25
   18 70       87     00011000 01110000            10000111             135    (1*128+7)
   28 40       104    00101000 01000000            100000100            260    (2*128+4) 
   69 5f 10    5ba81  01101001 01011111 0001000    1011011101010000001  375425 ((22*128^2)+(117*128^1)+(1*128^0))



  / Jonas Lund aka Whizzter of Woorlic
