ml>> but then it wouldn't have been storable in a longint ;)

 MK> Do you mean 64 bits?

no... 32bits... isn't that what you been "fussing" about? ;)

in pascal, a longint is a signed 32bit number...

 MK> That would be extremely doable.  Then again it potentially
 MK> could mean 128 bits to a few systems.

 MK> You must be doing 16 bit DOS-think.  ;-)

that's where fido was designed and built ;)

 ml>> ya gotta remember when this stuff was developed and what languages
 ml>> were being used... (borland) pascal was one of the most common...
 ml>> basic and c were also used with c getting more use as time marched
 ml>> on...

 MK> It doesn't matter.  I was working with 64 bit systems back
 MK> then and had to port FORTRAN source from my 386-16, where I
 MK> liked to experiment with ideas, to a 64 bit UNIX enviroment.
 MK> I managed.  What is their excuse?  My best guess is they
 MK> didn't really understand what they were doing.  Has little to
 MK> do with language unless one can't think beyond it's
 MK> "limitiations".

nah, it has everything to do with hobbiests developing and creating the
network we lovingly call fidonet...

 ml>> if one takes a good look at structures for many FTN tools, apps, and
 ml>> even bbs', one can easily see the pascal influence by the data
 ml>> structures used...

 MK> I suppose but most of what I see has little to do with any
 MK> language whatsoever.  Most of the problems relate to lack of
 MK> vision rather then any so-called OS limitation, such as DOS,
 MK> which is obviously still haunting all of us.

that may very well be... today, the problem is "all the old guys"
and not wanting to update or upgrade as well as fear of the unknown...
seems that those remaining who helped develope fidonet have lost their
curiousity in their waning years O:)

 MK> The reason I like perl is that I can easily experiment with
 MK> ideas without jumping through too many hoops and could port
 MK> these scripts to a compilable language without too much
 MK> difficulty.  Also perl kick's butt when compared to other
 MK> scripting languages as far as basic IO goes, as well as the
 MK> availabilty of some truly good modules.

that's wierd... i've seen stuff done in perl (and other similar languages)
to be a lot slower than the same stuff in compiled form from pascal,
delphi, and some of that C stuff ;)

 MK> For instance
 MK> comparing perl to php I have found the same functions are
 MK> vastly superior in perl and yet looking out there on the web I
 MK> see the opposite being employed.  That is one reason I don't
 MK> care much for web interfaces, although there are a few other
 MK> good reasons as well which don't have much to do with perl, so
 MK> I won't bother elaborating.  Anyhow perl works great on the
 MK> console so I am happy with it.

i hear ya there!

 MK> I believe a good perl ftn module would be a desirable
 MK> commodity.  What do you think?

it is possible... then again, i look around and see folk converting their
squish message bases to mbox format and using "stuff" on the
backside to access it... i'm not sure, but i suspect that
fidonet.sensationcontent.??? is doing the same... it's either that or
stuffing it in a sql database and throwing mucho horsepower at it for the
access speed to retrieve it... the connection speed is another factor,
altogether...

i see something very similar, here... we have a 23000+ person genelogy
database that is very fast in several geneology programs... i've pulled a
complete gedcom ("kinda" similar to xml) 5.5 format and have two
different web programs to work with it... one is just for viewing and uses
a cgi .CMD to fire off a modula program for accessing the data... another
is all php and using a mysql database... now, i don't have any of today's
fast horses in the stable, either... the webserver is running on a PII 266
with 96meg of ram and houses a lot of other services... the sql server is
running mandrake linux 7.2 on a P200 no-mmx with 64meg of ram... the
difference is staggering compared with the locally run geneology database
programs... the cgi program is possibly faster than the php app but it
doesn't do anywhere near what the php app does... in fact, the php app is
very close to the LDS PAF program... it allows editing and addition of the
data... however, i believe that there are some things that can be done in
the php program (actually stuff to do with mysql) that can greatly increase
the database access... now, if it'll also just leave the gedcom behind
other than using it solely for importing into the database, i'm sure
that'll increase its speed majorly... FWIW: a gedcom file is a simple ASCII
text file... the one that i'm working with is right at 16meg in size ;)

)\/(ark