[Info-vax] Re; Spiralog, RMS Journaling (was Re: FREESPADRIFT)
johnwallace4 at yahoo.co.uk
johnwallace4 at yahoo.co.uk
Tue Jun 28 00:09:03 EDT 2016
On Monday, 27 June 2016 18:41:58 UTC+1, Bob Koehler wrote:
> In article <00B0B3EA.9F7943FA at SendSpamHere.ORG>, VAXman- @SendSpamHere.ORG writes:
> >
> > OK... So we should all toss fixed, VFC, VAR, STM and STMCF formats and use
> > STMLF exclusively.
> >
> > Again, the filesize (in bytes) CAN be had but they'll not mean what you want
> > them to mean to your protocol transfer. Again, I don't see that as any VMS
> > problem; I see it as a protocol limitation imposed by all of the *ixers out
> > there that have, parochially, defined these protocols RFCs.
>
> Hm. Windows stores text lines with CRLF separators, so that's 2
> bytes meta-data per line of text. VAR stores text with leaing
> lengths in 16 bit words, so that's 2 bytes meta-data per line of
> text.
>
> Would seem to me that VAR isn't even a problem. When you do the
> conversion to the protocol's CRLF separators, you get the same total
> bytes.
Are you sure "Windows stores text lines with CRLF separators"?
Or do you mean "(some) Windows applications can correctly process text lines with CRLF separators"?
Windows has no built in record management layer. To some that's a good thing.
It also means that the behaviour of two allegedly similar Windows apps (e.g. two text editors) when fed the exact same file may be different depending on what's in the data on the disk.
A specific example of two Microsoft-authored applications which exhibit this: the behaviour of Wordpad is (was?) different from that of Notepad when fed a file which contains <text><LF><text> etc.
One program does what you might expect. The other doesn't. Which one is right? Who knows.
See e.g.
http://superuser.com/questions/362087/notepad-ignoring-linebreaks
More information about the Info-vax
mailing list