Ok. I copied all of my *.BRD and *.MIX files over to my DOS version of
Impulse. I was able to read the messages without them being garbled.
I'm not sure what this means. Maybe, that I need to convert the incoming bundles to DOS format? I tried issuing the "d2u -D" command to the incoming packets, and now they are marked as "bad." Does anyone know how to convert
the bundles after they are extracted? Or, would it be easier just to rewrite/convert the source code to handle Unix format files? I'm not sure how to do this. Any and all help is appreciated.

Thanks,

|09ignatius |07[|15cia|07]

--- Mystic BBS v1.12 A5 (Linux)
* Origin: catch22bbs.com >>> >> > (1:340/800)

01 Mar 16 03:08, you wrote to All:

Ok. I copied all of my *.BRD and *.MIX files over to my DOS version of Impulse. I was able to read the messages without them being garbled.
I'm not sure what this means.

wait! what? are you saying that your linux compiled binary cannot read those messages but the original DOS one has no problems with them?? how are you compiling? are you trying to do 16bit, 32bit or 64bit?? can you be more explicit about "the messages being garbled"?? got pics?

Maybe, that I need to convert the incoming bundles to DOS format? I
tried issuing the "d2u -D" command to the incoming packets, and now
they are marked as "bad." Does anyone know how to convert the bundles after they are extracted? Or, would it be easier just to
rewrite/convert the source code to handle Unix format files? I'm not
sure how to do this. Any and all help is appreciated.

there is no conversion to be done... PKTs are binary and you don't convert them
like that any more than you convert an exe file like that... what are you trying to convert the PKTs to?? the tosser ""converts"" them when it strips off
the PKT header and then imports each message in the PKT into the message base... that's not even a conversion, really...

)\/(ark

Always Mount a Scratch Monkey

... Backup not found: (A)bort (R)etry (S)lap nearest @FN@ ?
---
* Origin: (1:3634/12.73)

|01 ▄▄█▓▀▀▌▀▀▀ ░▀ ░|CR▓▀ quoting |09mark lewis |01on |0903/01/16 |07

wait! what? are you saying that your linux compiled binary cannot read those messages but the original DOS one has no problems with them?? how are you compiling? are you trying to do 16bit, 32bit or 64bit?? can you
be more explicit about "the messages being garbled"?? got pics?

Yes, that's what i'm saying. I'm compiling like this: "ppc386 -Mtp imp.pas". I'm compiling for a 32bit machine. Here's a screenshot: http://www.catch22bbs.com/garbled.png

there is no conversion to be done... PKTs are binary and you don't
convert them like that any more than you convert an exe file like
that... what are you trying to convert the PKTs to?? the tosser ""converts"" them when it strips off the PKT header and then imports
each message in the PKT into the message base... that's not even a conversion, really...

Ahh. I see.

Thanks,

|09ignatius |07[|15cia|07]

--- Mystic BBS v1.12 A5 (Linux)
* Origin: catch22bbs.com >>> >> > (1:340/800)

Something I should mention is, the DOS version I have is version 7.1 and is precompiled for DOS. The source version i'm working on is 7.1b (FPC source).

Thanks,

|09ignatius |07[|15cia|07]

--- Mystic BBS v1.12 A5 (Linux)
* Origin: catch22bbs.com >>> >> > (1:340/800)

01 Mar 16 21:17, you wrote to me:

wait! what? are you saying that your linux compiled binary cannot
read those messages but the original DOS one has no problems with
them?? how are you compiling? are you trying to do 16bit, 32bit or
64bit?? can you be more explicit about "the messages being garbled"??
got pics?

Yes, that's what i'm saying. I'm compiling like this: "ppc386 -Mtp imp.pas". I'm compiling for a 32bit machine. Here's a screenshot: http://www.catch22bbs.com/garbled.png

thanks! do you have a screenshot of that same message in its ungarbled form?? i
have an idea of what's going on but i need to see it ungarbled to be sure or not...

)\/(ark

Always Mount a Scratch Monkey

... Look at it sideways.
---
* Origin: (1:3634/12.73)

|01 ▄▄█▓▀▀▌▀▀▀ ░▀ ░|CR▓▀ quoting |09mark lewis |01on |0903/02/16 |07

thanks! do you have a screenshot of that same message in its ungarbled form?? i have an idea of what's going on but i need to see it ungarbled
to be sure or not...

Ok. I wasn't able to get an "ungarbled" version of that specific message. So here's a picture of a different message, garbled and ungarbled, side by side.

http://www.catch22bbs.com/bleh.png

Thanks,

|09ignatius |07[|15cia|07]

--- Mystic BBS v1.12 A6 (Linux)
* Origin: catch22bbs.com >>> >> > (1:340/800)

02 Mar 16 16:09, you wrote to me:

thanks! do you have a screenshot of that same message in its
ungarbled form?? i have an idea of what's going on but i need to see
it ungarbled to be sure or not...

Ok. I wasn't able to get an "ungarbled" version of that specific
message. So here's a picture of a different message, garbled and 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)

|01 ▄▄█▓▀▀▌▀▀▀ ░▀ ░|CR▓▀ quoting |09mark lewis |01on |0903/03/16 |07

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...

The DOS version isn't Y2K comatible.

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...

The "[cia]" is for my own (stupid) uses. I just needed something to fill the space. It's basically just that, a "note" which is used throughout the board. The reason why it's different on the DOS version, is because, well, I haven't set it to something besides the default. The default is "Impulse Sysop" for
the Sysop of the BBS.

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 believe this is my fault. I used "pipe" codes to display the various attributes (to, from, subject, etc) of the message. And after those "pipe" codes, I used an "esc[7;1H" to anchor the message header. Somehow that ansi code at the end carried over to the "Origin" line. BTW, an EOF character is a arrow pointing to the right :)

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...

Again, that's for my arbitrary purposes. It has absolutely nothing to do with the message packet or bundle.

Thanks for your time in studying this problem.

|09ignatius |07[|15cia|07]

--- Mystic BBS v1.12 A6 (Linux)
* Origin: catch22bbs.com >>> >> > (1:340/800)

03 Mar 16 00:17, you wrote to me:

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...

The DOS version isn't Y2K comatible.

how is it not y2k compatible? does it emit or expect three digits for two digit
years?

eg: 2016 - 1900 = 116 when 16 is the expected result...

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...

The "[cia]" is for my own (stupid) uses. I just needed something to
fill the space. It's basically just that, a "note" which is used throughout the board. The reason why it's different on the DOS
version, is because, well, I haven't set it to something besides the default. The default is "Impulse Sysop" for the Sysop of the BBS.

so this is not a side by side comparison of the exact same message in the exact
same message base by two different flavors of the software???

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 believe this is my fault. I used "pipe" codes to display the various attributes (to, from, subject, etc) of the message. And after those
"pipe" codes, I used an "esc[7;1H" to anchor the message header.
Somehow that ansi code at the end carried over to the "Origin" line.
BTW, an EOF character is a arrow pointing to the right :)

oops... yeah... it was very late for me when i wrote that...

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...

Again, that's for my arbitrary purposes. It has absolutely nothing to
do with the message packet or bundle.

the point is that if the exact same message in the exact same message base is depicted one way in one flavor of the software, it should be depicted pretty much the same by another flavor of the software... if you are using two different copies of the messages in two different versions of the message bases
then this is going to be really tough to diagnose... you really should have one
copy of the message in one message base that is read by both flavors of the software... that way the differences between them can be easier to see...

Thanks for your time in studying this problem.

you're welcome but i'm not sure that i'm really being all that much help in this case :(

)\/(ark

Always Mount a Scratch Monkey

... Press <Ctrl-Alt-Del> now to access the pirated GIFS! ;*)
---
* Origin: (1:3634/12.73)

|01 ▄▄█▓▀▀▌▀▀▀ ░▀ ░|CR▓▀ quoting |09mark lewis |01on |0903/03/16 |07

how is it not y2k compatible? does it emit or expect three digits for
two digit years?

It doesn't display the year in the traditional sense. Ie, "January 1st 2016", it displays "Jan 1 1800". Also, I have to set the date to a pre-2000 date in order for the BBS software to start, otherwise it complains.

"
Please set the date & time, it is required for operation.

"

so this is not a side by side comparison of the exact same message in
the exact same message base by two different flavors of the software???

Correct. The DOS version uses an older version of the code base. The version i'm using is the latest code available. As far as the messages go, I copied the actual message files over to the DOS port. Like you said, there must be a problem, because the count of messages is off by 1. In that certain base
which I posted a screenshot of. I _tried_ copying over the mail?.pas files
over to the Linux side, and compiled it, and i'm still having the same
problems with garbled screens. I'm not so sure the problem lies in the mail?.pas files. _Maybe_ it's "records.pas"?? I have no idea. But, I hope I solve this problem soon. :(

the point is that if the exact same message in the exact same message
base is depicted one way in one flavor of the software, it should be depicted pretty much the same by another flavor of the software... if
you are using two different copies of the messages in two different versions of the message bases then this is going to be really tough to diagnose... you really should have one copy of the message in one
message base that is read by both flavors of the software... that way
the differences between them can be easier to see...

Nod. Like I said I copied the (same) messages over to the DOS version. So,
both "flavors" of the software are rendering the messages differently. Again, i'm not so sure the problem lies in the message base code.

you're welcome but i'm not sure that i'm really being all that much help in this case :(

It's much appreciated. I'm sure we'll eventually figure this out.

Thanks,

|09ignatius |07[|15cia|07]

--- Mystic BBS v1.12 A6 (Linux)
* Origin: catch22bbs.com >>> >> > (1:340/800)

|01 ▄▄█▓▀▀▌▀▀▀ ░▀ ░|CR▓▀ quoting |09joseph larsen |01on |0903/04/16 |07

It's much appreciated. I'm sure we'll eventually figure this out.

I also just tried another tosser, Crashmail II. Hoping it might be a tosser-related issue. It isn't. :(

|09ignatius |07[|15cia|07]

--- Mystic BBS v1.12 A6 (Linux)
* Origin: catch22bbs.com >>> >> > (1:340/800)