Hi, Bob.

BL>          I'm looking at pkt2qwk and the qwk format, and I've come up
BL>against the .ndx files.

BL>  These have a message pointer in BasicReal. It continues to amaze me
BL>how stupid programmers can be. For a pointer with a maximum value of
BL>4096 (for a 500Kb pkt), firstly, they use a 4-byte number when an
BL>plain integer would have done nicely, and then they use a code they
BL>call the BASIC MKS$ format. Loonies!

I guess they were writing it in an earlier BASIC. I think I saw
something to the effect that you tried it in GWBASIC and that was indeed
the format of their reals.

BL>  To top it all, it isn't even BASIC MKS$. When I try MKS$ and its
BL>friend CVS in VB, I get the wrong answer.

MKS$ didn't exist then, I guess.

BL>  The QWK spec has a program written in Pascal to do the conversion,
BL>but it leaves me gasping, in particular $007FFFFF, $00800000, and $ff.
BL>WTF does this mean? Are they hex numbers like 0x in C? Or octal? Or
BL>what? My Pascal books don't mention it. My guess is that it is so
BL>basic that they assume everyone knows it. Not me...

A gremlin has stolen all my source and notes since I was working on my
own mail reader, 12+ months ago. Hopefully on tape somewhere, must have
a look before they disappear forever. Yes they are hex numbers, and if
you have a non-Turbo Pascal reference they may not be mentioned.

BL>  Invalue shr 24 worries me too. That's a hell of a shift right.

It's sucking out the exponent, the left-most byte of a 4-byte number.

From memory, and confirmed by the code you posted below, the exponent is
stored in the first byte, with an "offset" of 152. (Hmmm, that sounds a
bit strange, I would have expected 128. Oh, no it doesn't, I see what
they're doing - the 152-128=24 extra is to 'normalise' the 24 bit
number you get from the next bit.) The sign of the mantissa is in the
next bit, the mantissa itself in the low-order 23 bits. So if you think
of it as

               EESnNNNNN
               | ||
               | |+--- 23 bits mantissa, assume binary
               | |        point at left (M)
               | +--- 1 bit sign (S)
               +--- 8 bits exponent (E)

then the number is (-1)^S * M * 2^(E-128) and that's what that code
below calculates.

BL>  Here is the .ndx QWK spec and the Pascal program:

[chomp]

I'll keep that, for when I revisit that project. Thanks.

BL>A quick and dirty conversion (handles positive numbers only) is possible
BL>with the following expression:

BL>MKSToNum := ((x AND NOT $ff000000) OR $00800000)
BL>             SHR (24 - ((x SHR 24) AND $7f));

Well, it'll handle some cases. :-) Probably all the ones you'll
encounter in QWKs and NDXs.

BL>      Some message readers will reformat the *.NDX files so that the
BL>      MsgPointer becomes a LongInt fileseek position (using a record
BL>      size of 1).  To determine which type of index you are reading
BL>      you should look at the size of the number.  Any BasicReal will
BL>      appear as a huge number that would unlikely ever be a byte
BL>      seek positon.

Sure, but what a kludge!

I think you've now been pointed to the bit of C which implements this.

Regards, FIM.

 * * What we DON'T need is more liberalism!!!
@EOT:

---