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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)