• Squish on Linux (compile errors)

    From Oliver Thuns@2:280/464.47 to All on Wed Nov 20 16:02:23 2019
    Hello!

    Is anyone using Squish on Linux? The sources from github [1] don't build with any recent gcc (I even trid gcc4.9). Compile errors an a ton of warnings.

    [1] https://github.com/sdudley/maximus

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Alan Ianson@1:153/757 to Oliver Thuns on Wed Nov 20 07:52:24 2019
    Is anyone using Squish on Linux? The sources from github [1] don't build with any recent gcc (I even trid gcc4.9). Compile errors an a ton of warnings.

    Not since around 2004, maybe.

    [1] https://github.com/sdudley/maximus

    I never knew it was on github but that's where everything seems to be
    today. I used the 3.03 sources from sourceforge.net and the sources at
    github look much the same.

    Back then I think gcc was at version 2.95 or somewhere there abouts.

    I didn't use squish a lot but it seemed to work the way it always did in
    DOS and OS/2. I vaguely recall some visual glitches but functionality
    seemed to be good, at that time.

    Ttyl :-),
    Al

    --- MagickaBBS v0.13alpha (Linux/x86_64)
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Oliver Thuns@2:280/464.47 to Alan Ianson on Thu Nov 21 18:23:14 2019
    Is anyone using Squish on Linux? The sources from github [1]
    don't build with any recent gcc (I even trid gcc4.9). Compile
    errors an a ton of warnings.

    Not since around 2004, maybe.

    [1] https://github.com/sdudley/maximus

    I never knew it was on github but that's where everything seems to be today.

    I don't like the Github monoculture, but everything is better than Sourceforge.
    I'm using Gitlab for my own projects.

    I used the 3.03 sources from sourceforge.net and the sources at
    github look much the same.

    I think they are the same.

    Back then I think gcc was at version 2.95 or somewhere there abouts.

    IIRC there were some commits for compatibility with gcc 3 (dot something). Unfortunetely I don't know enough of C / C++ to fix the errors and warnings properly. I don't think it would be hard for a C coder, but it seems nobody is interested in Squish and Maximus on Linux anymore. Or should I ask in the TUB echo?

    I didn't use squish a lot but it seemed to work the way it always did
    in DOS and OS/2. I vaguely recall some visual glitches but
    functionality seemed to be good, at that time.

    I used Squish and Maximus in the 90s and it still can compete with recent Fido software. I managed to compile parts of it on the Raspberry a while ago, but was not sure if my changes were correct or would cause other problems at runtime.

    There was problem with rescanned echoareas I received from my uplink. Because todays computers and drives are so much faster, all .pkt files had the same timestamp. Squish tries to toss .pkt files chronologically, but fails misserably in that case and tosses the .pkt files in random order.

    Do I have to learn C or write my own tosser in REXX? ;)


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Oliver Thuns on Thu Nov 21 20:44:25 2019
    Hi Oliver,

    On 2019-11-21 18:23:14, you wrote to Alan Ianson:

    There was problem with rescanned echoareas I received from my uplink. Because todays computers and drives are so much faster, all .pkt files
    had the same timestamp. Squish tries to toss .pkt files
    chronologically, but fails misserably in that case and tosses the .pkt files in random order.

    There's also the problem that the squish message base stores date/time stamps with a resolution of 2 seconds. That has been causing problems in the past where a squish system forwarded messages to its other links with the date/times
    changed from the original, and so causing undetected dupes on some systems.

    This is of course only a problem if you have more than 1 link to an echomail area. Which is never (or shouldn't) be the case for a point system. ;)

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Oliver Thuns@2:280/464.47 to Wilfred van Velzen on Thu Nov 21 20:56:36 2019
    Hallo Wilfred!

    There's also the problem that the squish message base stores date/time stamps with a resolution of 2 seconds. That has been causing problems
    in the past where a squish system forwarded messages to its other
    links with the date/times changed from the original, and so causing undetected dupes on some systems.

    This might be a problem with some tossers, but it's not a problem with the Squish specification itself. It would surprise me, if Squish didn't use the original date for rescanned messages.

    Quote from the Squish Developers Kit Version 2.00:

    __ftsc_date char[20] 218 FTS-0001 compatible date. Squish
    applications should not access this
    field directly. This field is used
    exclusively by tossers and scanners
    for preserving the original ASCII
    message date. Squish applications
    should use the binary dates in
    date_written and date_arrived to
    retrieve the message date.


    I suspect hpt from the husky project. In scanarea.c, function makeMsg:

    sc_time((union stamp_combo *) &(xmsg.date_written), (char *)msg->datetime)


    This is of course only a problem if you have more than 1 link to an echomail area. Which is never (or shouldn't) be the case for a point system. ;)

    I'm a node in the othernet ;)

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: (2:280/464.47)
  • From Wilfred van Velzen@2:280/464 to Oliver Thuns on Fri Nov 22 12:06:07 2019
    Hi Oliver,

    On 2019-11-21 20:56:36, you wrote to me:

    There's also the problem that the squish message base stores
    date/time stamps with a resolution of 2 seconds. That has been
    causing problems in the past where a squish system forwarded messages
    to its other links with the date/times changed from the original, and
    so causing undetected dupes on some systems.

    This might be a problem with some tossers, but it's not a problem with the Squish specification itself. It would surprise me, if Squish didn't use
    the
    original date for rescanned messages.

    Quote from the Squish Developers Kit Version 2.00:

    __ftsc_date char[20] 218 FTS-0001 compatible date. Squish
    applications should not access this
    field directly. This field is used
    exclusively by tossers and scanners
    for preserving the original ASCII
    message date. Squish applications
    should use the binary dates in
    date_written and date_arrived to
    retrieve the message date.

    Looks good (if it's used when forwarding mail).

    I suspect hpt from the husky project. In scanarea.c, function makeMsg:

    sc_time((union stamp_combo *) &(xmsg.date_written), (char *)msg->datetime)

    I don't remember what tosser the guilty system used, when we found out...

    This is of course only a problem if you have more than 1 link to an
    echomail area. Which is never (or shouldn't) be the case for a point
    system. ;)

    I'm a node in the othernet ;)

    Are you a "leaf" node, or do you have multiple links?

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From mark lewis@1:3634/12.73 to Oliver Thuns on Fri Nov 22 14:38:36 2019

    On 2019 Nov 21 20:56:36, you wrote to Wilfred van Velzen:

    There's also the problem that the squish message base stores
    date/time stamps with a resolution of 2 seconds. That has been
    causing problems in the past where a squish system forwarded messages
    to its other links with the date/times changed from the original, and
    so causing undetected dupes on some systems.

    This might be a problem with some tossers, but it's not a problem with
    the Squish specification itself. It would surprise me, if Squish
    didn't use the original date for rescanned messages.

    it cannot because it cannot store it properly... seriously, it uses the file time record which only has 2 second seconds capability in DOS... it should be using a different time record but...

    )\/(ark

    Once men turned their thinking over to machines in the hope that this would set
    them free. But that only permitted other men with machines to enslave them. ... Charp - The green, mutant potato chip found in every bag.
    ---
    * Origin: (1:3634/12.73)
  • From Oliver Thuns@2:280/464.47 to mark lewis on Fri Nov 22 23:32:18 2019
    This might be a problem with some tossers, but it's not a problem
    with the Squish specification itself. It would surprise me, if
    Squish didn't use the original date for rescanned messages.

    it cannot because it cannot store it properly... seriously, it uses
    the file time record which only has 2 second seconds capability in
    DOS... it should be using a different time record but...

    seriously, you are wrong :-P


    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: (2:280/464.47)
  • From mark lewis@1:3634/12.73 to Oliver Thuns on Fri Nov 22 19:19:14 2019

    On 2019 Nov 22 23:32:18, you wrote to me:

    This might be a problem with some tossers, but it's not a problem
    with the Squish specification itself. It would surprise me, if
    Squish didn't use the original date for rescanned messages.

    it cannot because it cannot store it properly... seriously, it uses
    the file time record which only has 2 second seconds capability in
    DOS... it should be using a different time record but...

    seriously, you are wrong :-P

    you might want to look at those sources again, sir... we specifically tracked this modified time stamp problem down several years ago... every message coming
    via squish had the seconds in multiples of two... no odd numbers at all...

    the DateTime record is a four byte packed longint... it is not a unix time number... in C one would break it apart like so...

    with the packed time in lTime:

    sec = ((lTime>>0) & 0x1f)*2; // 0..60, only even values
    min = (lTime>>5) & 0x3f; // 0..59
    hour = (lTime>>11) & 0x1f; // 0..23
    day = (lTime>>16) & 0x1f; // 1..31
    month = (lTime>>21) & 0xf; // 1..12
    year = ((lTime>>25) & 0x7f) + 1980; // 1980..2108

    i repeat, squish is using the DOS filesystem datetime format for the message date/time fields... the DOS filesystem datetime format is limited to 2 second increments...

    sorry to be the bearer of bad news...

    )\/(ark

    Once men turned their thinking over to machines in the hope that this would set
    them free. But that only permitted other men with machines to enslave them. ... People who put beanz in chili, who knows WHAT they'll do?
    ---
    * Origin: (1:3634/12.73)
  • From Oliver Thuns@2:280/464.47 to mark lewis on Sat Nov 23 11:18:39 2019
    Hi mark,

    it cannot because it cannot store it properly... seriously, it
    uses the file time record which only has 2 second seconds
    capability in DOS... it should be using a different time record
    but...

    seriously, you are wrong :-P

    you might want to look at those sources again, sir... we specifically tracked this modified time stamp problem down several years ago...
    every message coming via squish had the seconds in multiples of two...
    no odd numbers at all...

    I don't know if there are older Squish versions that have this problem or what tossers or other programs were involved when you tracked down the problem. Squish (1.12 from Maximus 3.02) does not modify the time for pass-through or (re)scanned messages. It also uses "one-second granularity" for dupe checking.

    the DateTime record is a four byte packed longint... it is not a unix
    time number... in C one would break it apart like so...

    with the packed time in lTime:

    sec = ((lTime>>0) & 0x1f)*2; // 0..60, only even values
    min = (lTime>>5) & 0x3f; // 0..59
    hour = (lTime>>11) & 0x1f; // 0..23
    day = (lTime>>16) & 0x1f; // 1..31
    month = (lTime>>21) & 0xf; // 1..12
    year = ((lTime>>25) & 0x7f) + 1980; // 1980..2108

    i repeat, squish is using the DOS filesystem datetime format for the message date/time fields... the DOS filesystem datetime format is
    limited to 2 second increments...

    Yes, it does, but it also stores the original FTS-0001 datetime string. Yes, the time that is displayed in the editor has only two-second granularity, but a
    squish tosser can (and should) use the __ftsc_date field.

    sorry to be the bearer of bad news...

    Don't be sorry, the bad news is not true.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)
  • From Oliver Thuns@2:280/464.47 to Wilfred van Velzen on Sat Nov 23 11:16:21 2019
    This is of course only a problem if you have more than 1 link to
    an echomail area. Which is never (or shouldn't) be the case for
    a point system. ;)

    I'm a node in the othernet ;)

    Are you a "leaf" node, or do you have multiple links?

    I had multiple links for a short time, but "leaf" node fits best. Nevertheless,
    even as point I don't want to use software that would cause problems in a "Fidoweb" configuration. It may come handy in the future.

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: * nigirO (2:280/464.47)