NB> I'm using jamnntpd-1.0b5, and have the source to it that I'm using   
    NB> to compile, if that's what you're looking for?   
      
   i'm using the plain old v1.0 stuff... i made a small change or two to it and   
   so bumbed the version number in my copy when i compiled it with EMX for my   
   OS/2 system... all of my .c and .h files are dated 2005 Jan 11 except for   
   those i made changes to   
      
     nntpserv.h  ( version )   
     nntpserv.c  ( don't remember and can't find obvious changes :/ )   
      
   so i might not have ever changed anything...   
      
    > i would say that jamnntpd has it right, though... my ancient   
    > RemoteAccess BBS, FrontDoor editor, TimED, Fastecho all share my   
    > JAMbases with my jamnntpd using the same files and paths... those are   
    > all 16bit programs and i'm going to step out on a limb and say that   
    > Mystic BBS may be using larger (bytewise) versions of those numerical   
    > variables...   
      
    NB> That's very possible. James has been doing quite a bit of work on   
    NB> it this year, and compatibility with 32bit and 64bit systems was on   
    NB> that list.    
      
   yep... i carry and read that echo, too ;)   
      
    > *IF* this is the problem, then fixing it in Mystic BBS /will/ absolutely   
    > trash the current JAMbases as they are _not_ compatible with the   
    > original 16bit JAMbase definitions...   
      
    NB> Understood.   
      
   i just wanted to make sure that was known... especially since we may be   
   altering the storage format of the message number or even the offset counter   
   into the header or body file...   
      
    > i am not aware of anyone having made a "super"JAMbase format that uses   
    > 32bit or 64bit nomenclature where a word is a different sized storage   
    > bucket than 2bytes (16bits)... but the main thing is that the standard   
    > JAMbase files are 16bit... now, if Mystic BBS /IS/ using larger storage   
    > buckets, then jamnntpd may be able to be recompiled using them, too...   
    > then those two can work together BUT those bases would not be able to be   
    > simply copied to another machine with other JAMbase software and work   
    > properly...   
      
    NB> I'll have to ask the author if he changed anything in the JAM   
    NB> format. He may very well have changed it unknowingly while working   
    NB> on something else, too.. Thanks for the heads up. I'll see what I   
    NB> can dig up.   
      
   it is also quite possible that he didn't change anything but the compiler is   
   using a larger byte count for a type of the same name... this was an early   
   problem that should never have come up but folks wanted to be able to compile   
   in newer larger bit formats without changing their code... then they found out   
   that that was not a very good idea... so now, as pure examples, we have things   
   like this...   
      
       Size  ³          Range         ³  TP6     ³  FPC    
     ÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍØÍÍÍÍÍÍÍÍÍÍ   
       8-bit ³       -128..127        ³ Shortint ³ Shortint   
      16-bit ³     -32768..32767      ³ Integer  ³ Smallint   
      32-bit ³-2147483648..2147483647 ³ Longint  ³ Longint   
      32-bit ³          0..4294967295 ³          ³ Longword   
       8-bit ³          0..255        ³ Byte     ³ Byte   
      16-bit ³          0..65535      ³ Word     ³ Word   
      
               
   so a program written in TP6 using the "integer" type will /have/[1] to be   
   adjusted to use "smallint" when compiled with FPC (Free Pascal Compiler)... in   
   the above chart, you can see that the unsigned range of 0..4294967295 does not   
   exist in TP6... it gets deeper when trying to choose the proper one to use   
   between C and pascal and other languages *as well as* taking the platform into   
   consideration[2]...   
      
      
   [1] well, the FPC guys are really good at doing "compiler magic" and so have   
   aliased integer to smallint so that things don't bite one's arse...   
      
   [2] this quote snip from http://www.sandroid.org/TurboC/functionlist.html   
   [quote]   
     #define long int32_t   
      
   (You may wonder why there's a macro for long, since it's a 32-bit datatype on   
   both Turbo C and gcc. If so, you've fallen into the Turbo-thinking trap! The   
   long datatype is 64-bit for some CPU types supported by gcc.)   
   [/quote]   
      
      
      
   )\/(ark   
      
    * Origin:  (1:3634/12)