• squish

    From Nathan Prugh@1:138/392 to All on Saturday, May 20, 2006 00:07:00
    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)
  • From Alan Ianson@1:153/757 to Nathan Prugh on Saturday, May 20, 2006 09:16:23
    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)
  • From Peter Knapper@3:772/1.10 to Nathan Prugh on Sunday, May 21, 2006 11:30:38
    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)
  • From Bob Jones@1:343/41 to Alan Ianson on Saturday, May 20, 2006 16:54:06
    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)
  • From Fred Riccio@1:132/174 to Nathan Prugh on Sunday, May 21, 2006 15:01:06
    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)
  • From Nathan Prugh@1:138/392 to Fred Riccio on Sunday, May 21, 2006 22:24:00
    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)
  • From Bob Ackley@1:2905/3 to Alan Ianson on Sunday, May 21, 2006 09:06:34
    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)
  • From Alan Ianson@1:153/757 to Bob Jones on Monday, May 22, 2006 15:21:51
    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)
  • From Alan Ianson@1:153/757 to Bob Ackley on Monday, May 22, 2006 15:27:33
    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)
  • From Fred Riccio@1:132/174 to Nathan Prugh on Monday, May 22, 2006 18:26:18
    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)
  • From Bob Jones@1:343/41 to Alan Ianson on Monday, May 22, 2006 23:44:18
    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)
  • From andrew clarke@3:633/267 to Bob Ackley on Tuesday, May 23, 2006 18:24:12
    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)
  • From Nathan Prugh@1:138/392 to Fred Riccio on Tuesday, May 23, 2006 08:55:00
    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)
  • From Fred Riccio@1:132/174 to Nathan Prugh on Tuesday, May 23, 2006 19:44:57
    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)
  • From Sean Dennis@1:18/200 to Fred Riccio on Wednesday, May 24, 2006 15:10:48
    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)
  • From Bob Ackley@1:2905/3 to andrew clarke on Wednesday, May 24, 2006 06:39:58
    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)