On 10/21/2012 03:08 PM, mark lewis -> Nicholas Boel wrote:   
      
    NB>> I'm using jand have the sourc 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   
      
   That's odd. Most of my source files are dated Oct 16-20, 2004.   
      
    >    nntpserv.h  ( version )   
    >    nntpserv.c  ( don't remember and can't find obvious changes :/ )   
      
    > so i might not have ever changed anything...   
      
    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 ;)   
      
   Unfortunately, that is one of 4 Mystic and/or general BBS support echos where   
   Mystic is discussed, but he answers any questions on all of them, for the most   
   part.   
      
    > 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...   
      
   True. And your paragraph here reminds me.. would packing Mystic's message   
   bases have anything to do with, at the very least, the fact that the Subject   
   line and some parts of the body would be messed up?   
      
    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]...   
      
   Well, in my case, I believe Mystic was written in FPC, and JamNNTPd would be C?   
      
    > [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]   
      
   And in non-programmer terms you would say that this would be an issue I might   
   be having here? :)   
      
   --    
   Nick   
      
   --- Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120923 Thunderbird/15.0.1   
    * Origin: The Pharcyde -- Purgatory Newsreader in Wisconsin (1:154/10.1)