Text 8912, 115 rader
Skriven 2007-01-11 08:55:00 av bob klahn
     Kommentar till en text av ROSS CASSELL
Ärende: here again
==================
 RC> Hello bob!

 RC> 05 Jan 07 12:02, you wrote to me:

 RC>>> The way the data is stored in the file.

 RC>>> messages.dat is a binary data file, each message is stored
 RC>>> in records that are 128k max.

 bk>>  Every damn thing on your computer is binary.

 RC> Let me put it to you in simple language..

 I have read your message. I am still waiting for the simple
 language.

 RC> Reading in a text file is done differently than a file that
 RC> is a typed binary file, with multiple records.

 Typed binary file?????

 RC> While my programming skills are limited and majority of it
 RC> was dealing with TP7 under DOS for BBS and door programs,
 RC> the way I would parse a text config file to read in data
 RC> was alot different from reading in data from various
 RC> variables from a individual record from a file that
 RC> contained many records.

 And I recently wrote a program to sort through saved fido
 messages, to determine how many had certain text. Very easy to
 do. Written in basic, I didn't even bother to compile it.

 And reading in variables has little to do with text files in
 Fido. All you need is beginning and ending markers, and not even
 that if you start each msg with data identifying the length of
 the msg. Then all you need is a start identifier. Only for the
 first msg if you really want to do it that way.

 RC> Think of these files as a single file, each record
 RC> represents a single page of data, so these files have many
 RC> pages.

 RC> A simple text file and a great example of one would be a
 RC> common batch file or if you run a Windows NT variant,
 RC> AUTOEXEC.NT, the whole file is one single page.

 RC> Under linux, fstab is a great example of a plain text file
 RC> as well as the myriad of *.rc files you would find in your
 RC> ~ directory.

 RC> Here is a source code snippet to read in messages.dat..

 RC> Type Array25 = Array[1..25] of Char;
 RC>      HdrRec = Record

 ...

 RC> end.

 RC> But this is only the begining, you will need to read in all
 RC> the message as 128 byte blocks and convert it for editing.
 RC> It's an array of char, not strings, and it uses #227 for an
 RC> End of Line, rather then the conventional carriage
 RC> return/line feed.

 What an overcomplicated piece that is.

 RC> Sorry Bob, pure text files dont take this compexity.

 Nor does messages.dat. Just convert the #227 to cr/lf and you
 got it.

 Guthrie's Change.exe changes &HE3 to &H0D&H0A with no problem.
 Giving you cr/lf.

 Now there is an &HE1&H0A near the beginning of every msg. Just
 take that as a message marker, and count back the number of
 lines preceeding that in every msg, a constant, and you have
 your text file markers. You could write every msg as a seperate
 file if you wanted. There is also a number before the &E1*0A
 that appears to relate to the length of the file, but I didn't
 bother to determine whether that was the whole file length or
 just the message text length.

 All doable with a simple basic language program.

 bk>>  Anyway you want to define it, they use plain text some of the
 bk>>  time at least.

 RC> I was disputing file types, not the appearance of data.

 And you overcomplicated it.

 RC> you can put literally any EXE file on your computer into a
 RC> file viewer and see ascii text, the presence of ascii text
 RC> does not make it a ascii text file.

 When all the information is ascii of some sort, and serves no
 purpose other than displaying the data to read, it's ascii.

 RC>>> Why are you being obtuse.

 bk>>  Why are you being nasty?

 RC> Didnt know I was.

 I wasn't being obtuse. I happen to disagree with you.


BOB KLAHN bob.klahn@sev.org   http://home.toltbbs.com/bobklahn

... Sometimes you are sad....and no one sees your tears.
 * Silver Xpress V4.5/P [Reg]
--- Platinum Xpress/Win/WINServer v3.0pr5a
 * Origin: FidoTel & QWK on the Web! www.fidotel.com (1:275/311)