ml>> yes, i've been aware of this stuff, too... i remember that many
ml>> "howled" that JAM was designed based on squish... i'm
not privy to
ml>> the internals of how the JAMm team came up with the JAM format but
ml>> it might be that this is/was true... in any case, JAM has more
ml>> "features" and is a bit easier, in my mind, to work with...

 ac> The main benefit of running Squish bases was because they
 ac> could auto-pack themselves.

the bases, themselves, can't but the software (squish) that manipulates them can...

 ac> I don't think JAM was designed to do this.

sure it can... its just a matter of coding it in the utils...

 ac> But now that disk space is virtually free,
 ac> presumably nobody cares, so there's no real benefit using one
 ac> over the other, except for the fact that you have a Squish API
 ac> library (SMAPI/XMSGAPI) that is virtually portable to
 ac> anywhere, as opposed to the original JAM API (which presumably
 ac> nobody even uses).

i dunno... i use mark may's pascal OOP libraries with my fixes and enhancements...

 RT>> For the above reasons I hope Andrew changes his mind.

ml>> you're not the only one... my entire system is JAM... several
ml>> hundred bases...

 ac> You could convert all of these to Squish format using FmaCopy.

and loose access to them from my BBS software and my (current preferred)
mail reader? no thanks...

besides, i've my own utils to convert them that do a more accurate job than
others i've seen and used...

ml>> i've a few SDM (*.MSG) bases but not for normal bases... they're
ml>> only for OT-Track and then my master netmail area in my frontdoor...
ml>> i'd like to be able to move things to native linux flavors at
ml>> some point in time and retain my existing software... however, i
ml>> know that this won't happen with RA and i doubt that FE and FD
ml>> will come out with *nix flavors... so that leaves me with remote
ml>> accessing over the LAN and that takes local readers like TimED...
ml>> too bad i don't know C stuff any more than i do ;-(

 ac> I don't see the point

many times we don't see others points or understand why they'd want to do
something...

 ac> of running a Linux version of timEd if
 ac> all of your other software runs under DOS/Windows, unless you
 ac> want to use it remotely, in which case you can probably run
 ac> your DOS software under DOSEMU or WINE.

nope... that machine isn't ballsy enough for that (for one thing) and
several utils that i use won't run under DOSEMU... i don't do win* unless i
have to... i won't even speak about the trouble to move everything from one
machine to another... drives C-H on the existing and working machine and no
more room in the linux box that can't handle any drives larger than already
in there not to mention the cost of additional drives and hardware, etc,
etc, etc...

its just too much trouble... much easier to leave the server(s) as they are
and access from other machines as needed...

)\/(ark