02 Mar 16 16:09, you wrote to me:   
      
    ml>> thanks! do you have a screenshot of that same message in its   
    ml>> ungarbled form?? i have an idea of what's going on but i need to see   
    ml>> it ungarbled to be sure or not...   
      
    jl> Ok. I wasn't able to get an "ungarbled" version of that specific   
    jl> message. So here's a picture of a different message, garbled and   
    jl> ungarbled, side by side.   
      
   ok... there is defnintely a byte offset problem... one says it is message 1 of   
   5 and the other 1 of 6... what i'm suspecting is a problem of dealing with   
   ANSI in the message... either that or a counting problem where one array is   
   zero based and the other counting from 1... that would indicate that maybe   
   there is a difference between the size of an (eg) integer which leads to the   
   difference between the way an integer is defined... again, that's only an   
   example and why i asked about 16, 32 and 64 bit stuffings earlier...   
      
   the reason i mention a possible problem with ansi is because of the ansi   
   fluff'n'stuff in all three images... there's ansi stuff on the end of each   
   line on the left side as well as some sort of ansi mess on the right... the   
   differences between the two message rendering in the latest image plainly show   
   the that there's problem in rendering the message...   
      
   individual line breakdown:   
   1. looking at the first line, there's a problem with the date on the left and   
   the number of messages on the right...   
   2. the second line has dropped the first character of the sender... that's at   
   least a one byte difference at that point...   
   3. the third line has dropped the entire "To  : " preamble and that indicates   
   that there's six bytes that have been missed...   
   4. the fourth line is missing the "BBS'" on the left side and the following   
   NOTE portion is missing the 6 bytes making up the "[cia] " portion that is not   
   even show on the right...   
   5. then there's the STAT line which doesn't even depict the same byte values   
   and on the right the "local" attribute is depicted with a EOF character...   
      
   i'm not so sure that ansi is involved now that i look closer but there is   
   definitely a byte count problem somewhere... you need to look deeper at what   
   bytes are being seen by both flavors of the tosser because something is not   
   reading the bytes properly for display or is not writing them properly to the   
   message base... or maybe both... that 4th line showing "[cia]" on the left and   
   "impulse sysop" on the right confuses me right now... one or both should   
   contain more or at least parts of the other... the real question is what the   
   original packed message in the PKT looks like and were does that "[cia]"   
   portion come from with... with or without the trailing space...   
      
   )\/(ark   
      
   Always Mount a Scratch Monkey   
      
   ... "Joyeux Noel et Bonne Annee." - French Christmas   
   ---   
    * Origin:  (1:3634/12.73)