anyone have good programs to handle *.lng messages?

on squish, how can i fix 4 digits zone number since squish that I have (Squish 1.11) is fussy about it has to be 999: or under...


thanks....

--- SLMAIL v5.1 (#SLO409KEDG15G098)
* Origin: bbs.internetking.com.mx (1:138/392)

Nathan Prugh wrote to All:

anyone have good programs to handle *.lng messages?

HPT from the husky project handles large messages OK. It's not as easy
to setup as Squish though.

I'm hoping one day Squish can be updated but we'll have to see.
The Win32 & linux versions could likely be updated but it will be
a challenge to find devs who have the tools to compile new DOS &
OS/2 executibles.

on squish, how can i fix 4 digits zone number since squish that I have (Squish 1.11) is fussy about it has to be 999: or under...

That is a big zone isn't it.. :) I've never tried to use a zone that
big so I'm not sure but HPT may do that too. Gert might know about
that.

Ttyl :-),
Al

... My computer has a nut loose on the keyboard.

--- MBSE BBS v0.83.18 (GNU/Linux-i386)
* Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)

Hi Nathan,

anyone have good programs to handle *.lng messages?

No idea there sorry...

on squish, how can i fix 4 digits zone number since
squish that I have (Squish 1.11) is fussy about it has
to be 999: or under...

The origin of this restriction in Squish comes down to the Fidonet packet formats, as the Zone field in some parts of Fidonet is only 1 byte, so it can only be 0 - 255. To handle a zone above 255 you would need all the data storage/handling formats to change as well, and that would depend heavily on the software that you used.

One way you may be able to get Squish to work is to see if it can be made Zone agnostic, IE see if you can get it to ignore Zones completely, but then you would need to manage the Zone issue externally.

Cheers............pk.


--- Maximus/2 3.01
* Origin: Another Good Point About OS/2 (3:772/1.10)

The Win32 & linux versions could likely be updated but it will be
a challenge to find devs who have the tools to compile new DOS &
OS/2 executibles.

Due to contract work and related potential for IP issues, I haven't worked on the maximus / squish code for a while..... There is now the Open Watcom compiler. Since Max and Squish were originally compilable for Dos, Win and OS/2 using the predecessor to this compiler, there is hope.... But I believe the latest version in the sourceforge archive has only been compiled for Linux and related systems.... Note: The source for Squish is part of the Maximus source code.....

on squish, how can i fix 4 digits zone number since
squish that I have
(Squish 1.11) is fussy about it has to be 999: or under...

Something tells me the 4 digit zone number is breaking some FTSC standard.....

That is a big zone isn't it.. :) I've never tried to use a zone that
big so I'm not sure but HPT may do that too. Gert might know about
that.

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Hello Nathan!

19 May 06 23:07, Nathan Prugh wrote to All:

anyone have good programs to handle *.lng messages?

Exactly what are you looking for? A tosser that can handle longer messages or a utility that can get the long messages out of the *.Lng files?

What operating system? If you are looking for a DOS or Win app, I might be able to help.


More questions...

What version of Squish are you running?

16 or 32 bit?

What BUFFERS setting do you have in Squish.Cfg?



Sq386 and Sq386P with BUFFERS LARGE can handle messages up to 256K !



Regards,
Fred

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Hello Nathan!

19 May 06 23:07, Nathan Prugh wrote to All:

anyone have good programs to handle *.lng messages?

Exactly what are you looking for? A tosser that can handle longer messages
or a utility that can get the long messages out of the *.Lng files?

a utility because i have it set as Large as my buffer but it would not process the packet I get several *.lng messages a month from my hub probslly stats or listings....

As well I would like to be able to split messages because my bbs goes up to 1000 lines and I would like to be able to have it check for legith of messages before tossing into my bbs.... how can I do that? :-) if it did toss to the bbs
it usually truncate the message to fit in the space.

What operating system? If you are looking for a DOS or Win app, I might be
able to help.

I am using windows xp but would like it to be processed in shell so i can automate things by batch files. :-)

More questions...

What version of Squish are you running?

16 or 32 bit?

I am usimg squish 386 file to process the mail.

What BUFFERS setting do you have in Squish.Cfg?

Large.

Sq386 and Sq386P with BUFFERS LARGE can handle messages up to 256K !

usually more than that if I get a long %list.

Regards,
Fred

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)
SEEN-BY: 10/3 17/23 106/2000 6018 109/568 120/544 134/77 138/142 146 390 391
SEEN-BY: 138/392 140/1 2 153/7715 250/501 292/854 342/5 343/41 382/61 772/1
SEEN-BY: 3828/7 7105/1

--- SLMAIL v5.1 (#SLO409KEDG15G098)
* Origin: bbs.internetking.com.mx (1:138/392)

Replying to a message of Alan Ianson to Nathan Prugh:

Nathan Prugh wrote to All:

anyone have good programs to handle *.lng messages?

HPT from the husky project handles large messages OK. It's not as easy
to setup as Squish though.

I'm hoping one day Squish can be updated but we'll have to see.
The Win32 & linux versions could likely be updated but it will be a challenge to find devs who have the tools to compile new DOS & OS/2 executibles.

If people would write (only) ANSI standard code this wouldn't be an issue as any compiler that conforms to ANSI standards (and AFAIK most do) on any OS would work just fine.

--- FleetStreet 1.19+
* Origin: Bob's Boneyard, Emerson, Iowa (1:2905/3)

Bob Jones wrote to Alan Ianson:

Due to contract work and related potential for IP issues, I haven't worked on the maximus / squish code for a while..... There is now the Open Watcom compiler. Since Max and Squish were originally compilable for Dos, Win and OS/2 using the predecessor to this compiler, there is hope.... But I believe the latest version in the sourceforge archive has only been compiled for Linux and related systems.... Note: The source for Squish is part of the Maximus source code.....

That is good news.. I hope you can manage it..

Something tells me the 4 digit zone number is breaking some FTSC standard.....

That could be I'm not sure. I'm happy enough with three digit zones
myself.. :)

Ttyl :-),
Al

... SYSOP (n): A being that never sleeps, eats, or has money.

--- MBSE BBS v0.83.18 (GNU/Linux-i386)
* Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)

Bob Ackley wrote to Alan Ianson:

I'm hoping one day Squish can be updated but we'll have to see.
The Win32 & linux versions could likely be updated but it will be a challenge to find devs who have the tools to compile new DOS & OS/2 executibles.

If people would write (only) ANSI standard code this wouldn't be an issue as any compiler that conforms to ANSI standards (and AFAIK most do) on
any OS would work just fine.

Squish & Maximus were originaly OS/2 programs that were then compiled
for DOS, and then later for Win/NT IIRC. Now it's being compiled on
*nix too. There must be quite a mix of stuff in there by now.. :)
I'm not a coder myself, I don't know if it's ANSI complient or not.

Ttyl :-),
Al

... As a computer, I find your faith in technology amusing.

--- MBSE BBS v0.83.18 (GNU/Linux-i386)
* Origin: The Rusty MailBox - Penticton, B.C. Canada - trmb.ca (1:153/757)

Hello Nathan!

21 May 06 21:24, Nathan Prugh wrote to Fred Riccio:

Exactly what are you looking for? A tosser that can handle longer
messages or a utility that can get the long messages out of the *.Lng
files?

a utility because i have it set as Large as my buffer but it would
not process the packet I get several *.lng messages a month from my
hub probslly stats or listings....

I can probably throw something together that will do what you want. Zip up a couple of those .Lng files and send them to me so I have something to test with.


Regards,
Fred

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Squish & Maximus were originaly OS/2 programs that were then compiled
for DOS, and then later for Win/NT IIRC. Now it's being compiled on
*nix too. There must be quite a mix of stuff in there by now.. :)
I'm not a coder myself, I don't know if it's ANSI complient or not.

ANSI C? Ha, ha, ha, ha, ha.....

I suspect Maximus version 1 predates the common usage of the ANSI C standard.... Working with the segmented architecture of the 8086 / 8088 processor causes usage of some non-standard C coding conventions, especially when it comes to needing to handle data (messages) over 64Kb in size....

On a more pratical note, any code that properly handels a modem via a serial port probably has at least some code that is not portable, and probably not ANSI C. Maximus has some assembly code in some of the target systems. It has hooks to seperately compiled DLL's in OS/2, and I think also for WIN based systems..... There is conditional compile stuff.... The code running on Linux
is a probably bit better for being ANSI C compliant. I believe the person who put the initial effort into the port even has it running on a 64 bit system, so
it is better that it was.... But there are tricks used that aren't ANSI C at some points..... Part of the "fun" to get it to compile under Linux is to get the right set of definitions and macros defined to clear certain declarations that are needed in a segmented environment....

Bob Jones, 1:343/41

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)

Sun 2006-05-21 08:06, Bob Ackley (1:2905/3) wrote to Alan Ianson:

I'm hoping one day Squish can be updated but we'll have to see.
The Win32 & linux versions could likely be updated but it will be a
challenge to find devs who have the tools to compile new DOS & OS/2
executibles.

If people would write (only) ANSI standard code this wouldn't be
an issue as any compiler that conforms to ANSI standards (and
AFAIK most do) on any OS would work just fine.

You make it sound so easy! The Squish and Maximus code dates back to the early
1990s. It's a bit unrealistic to expect 15 year old DOS-based code to be ANSI/ISO C standard conformant. If they were to be rewritten from scratch I suspect this would not be much of a problem, although they would probably be rewritten in C++ or Python now.

In any case, there are some things you can't do solely with ANSI/ISO C/C++, eg.

- findfirst/findnext (eg. Squish processing *.PKT and *.pkt), although you can do this with less-portable POSIX calls

- serial port I/O (OS dependant) (required for Maximus)

- enhanced text mode display (required for Maximus but not Squish) (OS dependant - requires Curses, OS/2 Vio* or Win32 console subsystem calls)

- probably a few other things that don't spring to mind

-- mail@ozzmosis.com

--- timEd/FreeBSD 1.11.b2
* Origin: Blizzard of Ozz, Melbourne, Victoria, Australia (3:633/267)

I can probably throw something together that will do what you want. Zip up
a couple of those .Lng files and send them to me so I have something to
test with.

Will do, what's your email address?

thanks...

--- SLMAIL v5.1 (#SLO409KEDG15G098)
* Origin: bbs.internetking.com.mx (1:138/392)

Hello Nathan!

23 May 06 07:55, Nathan Prugh wrote to Fred Riccio:

I can probably throw something together that will do what you want. Zip
up a couple of those .Lng files and send them to me so I have something
to test with.

Will do, what's your email address?

Just file attach them to 1:132/174. The modem is kinda cranky. Your best bet would be BinkP


Regards,
Fred

--- Msged/NT 6.0.1
* Origin: Somewhere in New Hampshire's White Mountains (1:132/174)

Hello, Fred.

Replying to a message of Fred Riccio to Nathan Prugh:

The modem is kinda cranky.

Modems like to do that in their old age. <G>

Later,
Sean

//sean@outpostbbs.net | http://outpostbbs.net | ICQ: 19965647

--- FleetStreet 1.27.1
* Origin: Outpost BBS - 423.926.0556 - bbs.outpostbbs.net (1:18/200)

Replying to a message of andrew clarke to Bob Ackley:

If people would write (only) ANSI standard code this wouldn't be
an issue as any compiler that conforms to ANSI standards (and
AFAIK most do) on any OS would work just fine.

You make it sound so easy! The Squish and Maximus code dates back to
the early 1990s. It's a bit unrealistic to expect 15 year old
DOS-based code to be ANSI/ISO C standard conformant. If they were to
be rewritten from scratch I suspect this would not be much of a
problem, although they would probably be rewritten in C++ or Python
now.

Back in the hoary days of my past, we were *required* to use only ANSI
standard code because one basic requirement of the software was that it
be portable (at the time there were five different companies making mainframes, none of them were compatible with each other but *all* were ANSI
compliant, we had to be able to compile our (COBOL) programs on any
of them).

While each of those five companies were basically ANSI compliant, all had 'quirks'
added (that we weren't supposed to use) to their systems.

In any case, there are some things you can't do solely with ANSI/ISO C/C++, eg.

- findfirst/findnext (eg. Squish processing *.PKT and *.pkt), although
you can do this with less-portable POSIX calls

I haven't looked into it, but I would imagine that it's possible to write such a function in ANSI standard code. Not necessarily easy, but possible.

- serial port I/O (OS dependant) (required for Maximus)

- enhanced text mode display (required for Maximus but not Squish) (OS dependant - requires Curses, OS/2 Vio* or Win32 console subsystem
calls)

- probably a few other things that don't spring to mind

My bottom line point is that if the users *demanded* ANSI compliance and refused to purchase or lease software that wasn't compliant, the various software outfits would become compliant. Even if new ANSI standards have
to be developed. And I doubt that it's going to happen.

Way back in the 70's there were over seventy different firms making Intel based
microcomputers. All of them had their own operating systems and disk formats and most of them were incompatible with the others - and apps had to be written for each disk format and for each OS. Somewhere around here is a CP/M program that allows my Heath H-89 to read and write in over seventy different (soft sector)
disk formats. Then Gary Kildall brought out CP/M, which standardized the API and
made software development and distribution MUCH easier. Perhaps something similar could be done WRT handling video displays - a standard API but the other
end modified for whatever OS its running under?

And my system runs Maximus (but not Squish).

--- FleetStreet 1.19+
* Origin: Bob's Boneyard, Emerson, Iowa (1:2905/3)