Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Brian White]

Since when does a disk drive decide what is and is not supposed to be
treated as text vs binary data? The application author who decides which
flags to use with open() does that, or the ftp client user does that by
using the bin option *which exists*. The the drive subsystem never ever
decides that.

No one answered the question about the sewing machines which also used
these drives.

"AFAIK "good programming practices and principles" are suggestions and
recommendations, not laws."
Indeed.
1) I never said anything else.
2) Why is a "good practice" good in the first place? For a reason, not
because god said so or something. Something is good or bad because of the
harm it lessens or increases.

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Gary Weber]

Since when is it NOT wrong for TELCOM to disallow recording of  into a
.DO file being downloaded, but it IS wrong for the LaddieAlpha/TS-DOS
combination during the same operation?

On Fri, Feb 15, 2019 at 2:29 AM Brian White  wrote:

> Since when does a disk drive decide what is and is not supposed to be
> treated as text vs binary data? The application author who decides which
> flags to use with open() does that, or the ftp client user does that by
> using the bin option *which exists*. The the drive subsystem never ever
> decides that.
>
> No one answered the question about the sewing machines which also used
> these drives.
>
> "AFAIK "good programming practices and principles" are suggestions and
> recommendations, not laws."
> Indeed.
> 1) I never said anything else.
> 2) Why is a "good practice" good in the first place? For a reason, not
> because god said so or something. Something is good or bad because of the
> harm it lessens or increases.
>
>
>

-- 
Gary Weber
g...@web8201.com

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[John R. Hogerhuis]

On Fri, Feb 15, 2019 at 1:29 AM Brian White  wrote:

> Since when does a disk drive decide what is and is not supposed to be
> treated as text vs binary data? The application author who decides which
> flags to use with open() does that, or the ftp client user does that by
> using the bin option *which exists*. The the drive subsystem never ever
> decides that.
>
>
I've variously called LaddieAlpha.EXE a "tpdd service" "tpdd emulator"
"drive service" "file service". it is a "disk service" but because it runs
on foreign systems

But all versions have to "map" files to the Model T machines. Filenames,
and to various degrees, content. For example, if there is a file in the
directory that LaddieAlpha is serving with a .txt extension, it will
present in TS-DOS as a .D? file, since that is is the only way TS-DOS will
allow loading the file as a text file.

So in that way, LaddieAlpha is not just a disk drive, it is providing the
service of creating a mapping to the files on a foreign system. And, it
must do it all of this automatically because LaddieAlpha is effectively
"headless".  mComm has a GUI, but it also can't put TS-DOS on hold while it
pops a dialog. All TPDD services must respond in real time

CO and BA files (binary files) are not modified. DLPilot had a feature that
allowed macro expansion of DO files. LaddieAlpha never has. I do believe
filtering evil NUL and EOF bytes is the first editing that Laddie series
has acquired.


> No one answered the question about the sewing machines which also used
> these drives.
>
>
Well. When you talk about "these drives" you need to understand that there
are 2 different drives, and 3 protocols and various tpdd services
implementing various protocols.

In short, the protocol that LaddieAlpha implements is not the same protocol
that the sewing machines use.

There is

a) The Brother FB-100 /The Purple Computing Drive The Tandy Portable Disk
Drive
b) The Tandy Portable Disk Drive 2

Protocols:

a) The FB100/TPDD-1 sector access protocol
b) The FB100/TPDD-1 file access protocol
c) The TPDD-2 sector access protocol

A nod to The Known Extensions:

a) Desklink Extensions
b) Ken Pettit and John Hogerhuis extensions

The Brother FB-100, Purple Computing and Tandy Portable Disk Drive are
really all the same drive to my understanding.
The TPDD-2 is the only one that implements its sector access protocol.
AFAIK the only applications that use it are the ones that came with the
drive.

The Brother sewing machines access the drive at a sector level, not a file
system level and read/write hex formatted sector images via the FB100
sector access protol. There are FB100 sector access protocol emulators for
use with the sewing machines. AFAIK there is no overlap in use of emulators
between the Brother sewing community and Model Ts, because of this reason.

That said I believe mComm does implement the FB100 sector access protocol
because it is needed to use the spellcheck dictionary. Maybe that would
make it usable with the sewing machines, but it seems ill advised, as there
are dedicated applications that are supported for that community.

I guess if you're trying to find something other than a contrived scenario
where EOF and NUL removal is harmful you need to look for those using TPDD
emulators with other vintage computers. For example, I understand there is
a TPDD client for the Cambridge Z88 and maybe some other machines.

I doubt any other machines use our specific .D* extension filenames. They
probably use 3 character extensions. But who knows.

I haven't been contacted by anyone using LaddieAlpha with any other machine
than the Model Ts or WP-2. But it's possible.

"AFAIK "good programming practices and principles" are suggestions and
> recommendations, not laws."
> Indeed.
> 1) I never said anything else.
> 2) Why is a "good practice" good in the first place? For a reason, not
> because god said so or something. Something is good or bad because of the
> harm it lessens or increases.
>

And something I've learned in my career of  25 years as a programmer is
that those rules balance goods and bads, not just avoid harms. The rules of
thumb/principles interact with each other, with use cases and with
requirements, and interaction issues with systems you cannot control.

A good programmer seeks a balance.

-- John.

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Mike Stein]

- Original Message - 
From: Brian White 
To: m...@bitchin100.com 
Sent: Friday, February 15, 2019 4:28 AM
Subject: Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)


Since when does a disk drive decide what is and is not supposed to be treated 
as text vs binary data? The application author who decides which flags to use 
with open() does that, or the ftp client user does that by using the bin option 
*which exists*. The the drive subsystem never ever decides that.


No one answered the question about the sewing machines which also used these 
drives.

"AFAIK "good programming practices and principles" are suggestions and 
recommendations, not laws."

Indeed.

1) I never said anything else.

2) Why is a "good practice" good in the first place? For a reason, not because 
god said so or something. Something is good or bad because of the harm it 
lessens or increases.
==

Well, there you go; by your definition stripping the EOF is a good thing 
because it *definitely* lessens harm.

As to your sewing (knitting, actually) machine red herring question, we are 
talking about an M100 TPDD emulator, NOT a BROTHER FB-100 emulator. 

You haven't answered any questions or contributed anything positive, so why not 
finally drop this ridiculous argument?

Please?

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Mike Stein]

Strictly speaking, a TPDD is not just a "disk drive" either, it is also a file 
server that translates and converts RS-232 commands into disk drive "commands" 
such as 'direction', 'step', 'write enable' etc., calculates checksums, 
converts raw sectors into blocks of 8-bit data and vice versa, etc.

If we modified the TPDD firmware to match Laddie and handle diskettes created 
by a foreign system, would that also violate the 'principle' the way that 
agitates Brian so?

Should raw sector data including checksums, track & sector number etc. be sent 
to the host to add to processing overhead or does it make more sense to let the 
drive strip off this information and just send the client the data that it has 
requested?

Finally, when the M100 and TPDD were created they were a closed system and you 
didn't have to worry about CR/LF, EOF, NUL etc. because the Model T's were the 
only source of diskette data and they would handle them correctly. Once you 
open the same interface to transfer files created by who-knows-what system, it 
makes sense to take into account any incompatibilities (as TELCOM does to some 
extent).
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Friday, February 15, 2019 12:25 PM
  Subject: Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)






  On Fri, Feb 15, 2019 at 1:29 AM Brian White  wrote:

Since when does a disk drive decide what is and is not supposed to be 
treated as text vs binary data? The application author who decides which flags 
to use with open() does that, or the ftp client user does that by using the bin 
option *which exists*. The the drive subsystem never ever decides that.




  I've variously called LaddieAlpha.EXE a "tpdd service" "tpdd emulator" "drive 
service" "file service". it is a "disk service" but because it runs on foreign 
systems

  But all versions have to "map" files to the Model T machines. Filenames, and 
to various degrees, content. For example, if there is a file in the directory 
that LaddieAlpha is serving with a .txt extension, it will present in TS-DOS as 
a .D? file, since that is is the only way TS-DOS will allow loading the file as 
a text file.

  So in that way, LaddieAlpha is not just a disk drive, it is providing the 
service of creating a mapping to the files on a foreign system. And, it must do 
it all of this automatically because LaddieAlpha is effectively "headless".  
mComm has a GUI, but it also can't put TS-DOS on hold while it pops a dialog. 
All TPDD services must respond in real time

  CO and BA files (binary files) are not modified. DLPilot had a feature that 
allowed macro expansion of DO files. LaddieAlpha never has. I do believe 
filtering evil NUL and EOF bytes is the first editing that Laddie series has 
acquired.
   
No one answered the question about the sewing machines which also used 
these drives.




  Well. When you talk about "these drives" you need to understand that there 
are 2 different drives, and 3 protocols and various tpdd services implementing 
various protocols.

  In short, the protocol that LaddieAlpha implements is not the same protocol 
that the sewing machines use.

  There is 

  a) The Brother FB-100 /The Purple Computing Drive The Tandy Portable Disk 
Drive
  b) The Tandy Portable Disk Drive 2


  Protocols:

  a) The FB100/TPDD-1 sector access protocol
  b) The FB100/TPDD-1 file access protocol
  c) The TPDD-2 sector access protocol

  A nod to The Known Extensions: 


  a) Desklink Extensions
  b) Ken Pettit and John Hogerhuis extensions


  The Brother FB-100, Purple Computing and Tandy Portable Disk Drive are really 
all the same drive to my understanding.
  The TPDD-2 is the only one that implements its sector access protocol. AFAIK 
the only applications that use it are the ones that came with the drive.

  The Brother sewing machines access the drive at a sector level, not a file 
system level and read/write hex formatted sector images via the FB100 sector 
access protol. There are FB100 sector access protocol emulators for use with 
the sewing machines. AFAIK there is no overlap in use of emulators between the 
Brother sewing community and Model Ts, because of this reason.

  That said I believe mComm does implement the FB100 sector access protocol 
because it is needed to use the spellcheck dictionary. Maybe that would make it 
usable with the sewing machines, but it seems ill advised, as there are 
dedicated applications that are supported for that community.



  I guess if you're trying to find something other than a contrived scenario 
where EOF and NUL removal is harmful you need to look for those using TPDD 
emulators with other vintage computers. For example, I understand there is a 
TPDD client for the Cambridge Z88 and maybe some other machines. 

  I doubt any other machines use our specific .D* extension filenames. They 
probably use 3 character extensions. But who knows.

  I haven't been contacted by anyone using

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Brian White]

All else being equal, it IS wrong for telcom not to record whatever bytes
are sent.

It's excuse is, at the time such ideas hadn't been recognized and discarded
yet, and the fact that telcom is part of a very tightly coupled and managed
system. It's not generic software that runs anywhere, it's part of a rom,
and so it's less of a crime to be tightly coupled with the other parts of
that rom, like making presumptions about what kind of data may exist in a
file with a certain kind of name.

The tpdd makes no such presumptions.

Telcom also only ever claimed to operate like a user application that deals
in text just like a text editor. How the text editor and telcom package up
data internally are their own business. They just accept keystrokes and
display characters. That is an entirely different domain.

What you should ask is, when you tell BASIC to read or write from COM:,
does BASIC presume to modify the data?

Similarly would you tolerate a file compressor or other encoder that didn't
spit back out exactly the data you put into it?

Telcom processing the data as though it's text is like an image editor
adding metadata on it's own. It's an allowed part of it's job because it's
job is to deal in displaying a visual image to you, not to hold that data
in trust for something else. IT is the app whose defined role is to
manipulate and process the data.

But then when you take that image data the the image editor made, and put
it into a zip file, and save it to a thumb drive, and then read it back
from a thumb drive, it's entirely wrong for any of those things to output
one single bit different from what they were given.

On Fri, Feb 15, 2019, 5:19 AM Gary Weber  Since when is it NOT wrong for TELCOM to disallow recording of  into
> a .DO file being downloaded, but it IS wrong for the LaddieAlpha/TS-DOS
> combination during the same operation?
>
> On Fri, Feb 15, 2019 at 2:29 AM Brian White  wrote:
>
>> Since when does a disk drive decide what is and is not supposed to be
>> treated as text vs binary data? The application author who decides which
>> flags to use with open() does that, or the ftp client user does that by
>> using the bin option *which exists*. The the drive subsystem never ever
>> decides that.
>>
>> No one answered the question about the sewing machines which also used
>> these drives.
>>
>> "AFAIK "good programming practices and principles" are suggestions and
>> recommendations, not laws."
>> Indeed.
>> 1) I never said anything else.
>> 2) Why is a "good practice" good in the first place? For a reason, not
>> because god said so or something. Something is good or bad because of the
>> harm it lessens or increases.
>>
>>
>>
>
> --
> Gary Weber
> g...@web8201.com
>

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Brian White]

That was an interesting and informative tour. Thank you. You do raise some
points.

-- 
bkw

On Fri, Feb 15, 2019, 12:26 PM John R. Hogerhuis 
>
> On Fri, Feb 15, 2019 at 1:29 AM Brian White  wrote:
>
>> Since when does a disk drive decide what is and is not supposed to be
>> treated as text vs binary data? The application author who decides which
>> flags to use with open() does that, or the ftp client user does that by
>> using the bin option *which exists*. The the drive subsystem never ever
>> decides that.
>>
>>
> I've variously called LaddieAlpha.EXE a "tpdd service" "tpdd emulator"
> "drive service" "file service". it is a "disk service" but because it runs
> on foreign systems
>
> But all versions have to "map" files to the Model T machines. Filenames,
> and to various degrees, content. For example, if there is a file in the
> directory that LaddieAlpha is serving with a .txt extension, it will
> present in TS-DOS as a .D? file, since that is is the only way TS-DOS will
> allow loading the file as a text file.
>
> So in that way, LaddieAlpha is not just a disk drive, it is providing the
> service of creating a mapping to the files on a foreign system. And, it
> must do it all of this automatically because LaddieAlpha is effectively
> "headless".  mComm has a GUI, but it also can't put TS-DOS on hold while it
> pops a dialog. All TPDD services must respond in real time
>
> CO and BA files (binary files) are not modified. DLPilot had a feature
> that allowed macro expansion of DO files. LaddieAlpha never has. I do
> believe filtering evil NUL and EOF bytes is the first editing that Laddie
> series has acquired.
>
>
>> No one answered the question about the sewing machines which also used
>> these drives.
>>
>>
> Well. When you talk about "these drives" you need to understand that there
> are 2 different drives, and 3 protocols and various tpdd services
> implementing various protocols.
>
> In short, the protocol that LaddieAlpha implements is not the same
> protocol that the sewing machines use.
>
> There is
>
> a) The Brother FB-100 /The Purple Computing Drive The Tandy Portable Disk
> Drive
> b) The Tandy Portable Disk Drive 2
>
> Protocols:
>
> a) The FB100/TPDD-1 sector access protocol
> b) The FB100/TPDD-1 file access protocol
> c) The TPDD-2 sector access protocol
>
> A nod to The Known Extensions:
>
> a) Desklink Extensions
> b) Ken Pettit and John Hogerhuis extensions
>
> The Brother FB-100, Purple Computing and Tandy Portable Disk Drive are
> really all the same drive to my understanding.
> The TPDD-2 is the only one that implements its sector access protocol.
> AFAIK the only applications that use it are the ones that came with the
> drive.
>
> The Brother sewing machines access the drive at a sector level, not a file
> system level and read/write hex formatted sector images via the FB100
> sector access protol. There are FB100 sector access protocol emulators for
> use with the sewing machines. AFAIK there is no overlap in use of emulators
> between the Brother sewing community and Model Ts, because of this reason.
>
> That said I believe mComm does implement the FB100 sector access protocol
> because it is needed to use the spellcheck dictionary. Maybe that would
> make it usable with the sewing machines, but it seems ill advised, as there
> are dedicated applications that are supported for that community.
>
> I guess if you're trying to find something other than a contrived scenario
> where EOF and NUL removal is harmful you need to look for those using TPDD
> emulators with other vintage computers. For example, I understand there is
> a TPDD client for the Cambridge Z88 and maybe some other machines.
>
> I doubt any other machines use our specific .D* extension filenames. They
> probably use 3 character extensions. But who knows.
>
> I haven't been contacted by anyone using LaddieAlpha with any other
> machine than the Model Ts or WP-2. But it's possible.
>
> "AFAIK "good programming practices and principles" are suggestions and
>> recommendations, not laws."
>> Indeed.
>> 1) I never said anything else.
>> 2) Why is a "good practice" good in the first place? For a reason, not
>> because god said so or something. Something is good or bad because of the
>> harm it lessens or increases.
>>
>
> And something I've learned in my career of  25 years as a programmer is
> that those rules balance goods and bads, not just avoid harms. The rules of
> thumb/principles interact with each other, with use cases and with
> requirements, and interaction issues with systems you cannot control.
>
> A good programmer seeks a balance.
>
> -- John.
>

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Gary Weber]

  GW>> Since when is it NOT wrong for TELCOM to disallow recording of 
into a .DO file being downloaded, but it IS wrong for the
LaddieAlpha/TS-DOS combination during the same operation?
  BW>  the fact that telcom is part of a very tightly coupled and managed
system. It's not generic software that runs anywhere

You have clearly, and strongly, stated the some very sound engineering
principles.   Honestly I doubt anyone (or at least many) would question the
principles in the universal generic sense.

But I would assert LaddieAlpha is not universal or generic.  It has a very
defined stated purpose, and has always made specific concessions for Model
Ts & WP2s.   Using it outside of this context is at your own peril, so to
speak.  And you're bringing up not just edge cases but actually *corner*
cases to the usage model.

Secondly, TELCOM doesn't know where data is coming from via the COM: port,
so I question the claim that it is part of a very tightly coupled and
managed system in the context of how it downloads data.  Rather, it filters
the data to be appropriate to the machine.  The LaddieAlpha/TS-DOS coupling
is no more nefarious than this, and to knowingly permit that combination to
crash the machine, while TELCOM protects the machine, would not only be
silly, it would be irresponsible.

Unless the user directs it to do so of course, whereby my
--allow_file_system_corruption switch would suffice.  ;-)


On Fri, Feb 15, 2019 at 11:31 AM Brian White  wrote:

> All else being equal, it IS wrong for telcom not to record whatever bytes
> are sent.
>
> It's excuse is, at the time such ideas hadn't been recognized and
> discarded yet, and the fact that telcom is part of a very tightly coupled
> and managed system. It's not generic software that runs anywhere, it's part
> of a rom, and so it's less of a crime to be tightly coupled with the other
> parts of that rom, like making presumptions about what kind of data may
> exist in a file with a certain kind of name.
>
> The tpdd makes no such presumptions.
>
> Telcom also only ever claimed to operate like a user application that
> deals in text just like a text editor. How the text editor and telcom
> package up data internally are their own business. They just accept
> keystrokes and display characters. That is an entirely different domain.
>
> What you should ask is, when you tell BASIC to read or write from COM:,
> does BASIC presume to modify the data?
>
> Similarly would you tolerate a file compressor or other encoder that
> didn't spit back out exactly the data you put into it?
>
> Telcom processing the data as though it's text is like an image editor
> adding metadata on it's own. It's an allowed part of it's job because it's
> job is to deal in displaying a visual image to you, not to hold that data
> in trust for something else. IT is the app whose defined role is to
> manipulate and process the data.
>
> But then when you take that image data the the image editor made, and put
> it into a zip file, and save it to a thumb drive, and then read it back
> from a thumb drive, it's entirely wrong for any of those things to output
> one single bit different from what they were given.
>
> On Fri, Feb 15, 2019, 5:19 AM Gary Weber 
>> Since when is it NOT wrong for TELCOM to disallow recording of  into
>> a .DO file being downloaded, but it IS wrong for the LaddieAlpha/TS-DOS
>> combination during the same operation?
>>
>> On Fri, Feb 15, 2019 at 2:29 AM Brian White  wrote:
>>
>>> Since when does a disk drive decide what is and is not supposed to be
>>> treated as text vs binary data? The application author who decides which
>>> flags to use with open() does that, or the ftp client user does that by
>>> using the bin option *which exists*. The the drive subsystem never ever
>>> decides that.
>>>
>>> No one answered the question about the sewing machines which also used
>>> these drives.
>>>
>>> "AFAIK "good programming practices and principles" are suggestions and
>>> recommendations, not laws."
>>> Indeed.
>>> 1) I never said anything else.
>>> 2) Why is a "good practice" good in the first place? For a reason, not
>>> because god said so or something. Something is good or bad because of the
>>> harm it lessens or increases.
>>>
>>>
>>>
>>
>> --
>> Gary Weber
>> g...@web8201.com
>>
>

-- 
Gary Weber
g...@web8201.com

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Brian White]

By tightly coupled, I mean that Telcom has inside  knowledge of the rest of
the system.

The tpdd does not.

(nor the dvi, and I'd put money on the chipmunk too)

The only reason you can produce examples of other software and systems
doing things like that, is because it's something that used to be very
common, and even today every new programmer takes some time to learn
better, and some never do. But by now it is recognized as an antipattern.
After Joe-self-taught-teenager-programmer-from-the-70s-80s writes a bunch
of such stuff, it's all fine at first, and only later he discovers that he
has written an unmaintainable and unportable brick. Customer wants the
tiniest change and it's practically impossible, because the code is riddled
with assumptions that should never have been made.


John did raise some points that no tpdd emulator to date has emulated the
drive *really* though, else they would use disk images instead of files.
And the knitting machines don't use files either.

I personally don't think that's a strong enough argument, but it is at
least an argument. I think that just means a tpdd emulator is a filesystem
instead of a disk. OK, so I would not tolerate a filesystem that modified
the files either.


As to Mikes point about causing harm:

Preserving data is never causing harm.

If there is harmful data, then the harm was caused by the thing that
created that harmful data.

I see that as "two wrongs don't make a right".

If a text editor added eof, that was a bad text editor, and it's more
helpful to the user to have the bad data and thus indirectly the cause of
the bad data, be exposed and corrected, rather than silently allowed to
persist and even propagate over time. So that you go on thinking you
actually have good data when you don't and it just fails tomorrow in any
other context.

-- 
bkw


On Fri, Feb 15, 2019, 2:44 PM Gary WeberGW>> Since when is it NOT wrong for TELCOM to disallow recording of
>  into a .DO file being downloaded, but it IS wrong for the
> LaddieAlpha/TS-DOS combination during the same operation?
>   BW>  the fact that telcom is part of a very tightly coupled and managed
> system. It's not generic software that runs anywhere
>
> You have clearly, and strongly, stated the some very sound engineering
> principles.   Honestly I doubt anyone (or at least many) would question the
> principles in the universal generic sense.
>
> But I would assert LaddieAlpha is not universal or generic.  It has a very
> defined stated purpose, and has always made specific concessions for Model
> Ts & WP2s.   Using it outside of this context is at your own peril, so to
> speak.  And you're bringing up not just edge cases but actually *corner*
> cases to the usage model.
>
> Secondly, TELCOM doesn't know where data is coming from via the COM: port,
> so I question the claim that it is part of a very tightly coupled and
> managed system in the context of how it downloads data.  Rather, it filters
> the data to be appropriate to the machine.  The LaddieAlpha/TS-DOS coupling
> is no more nefarious than this, and to knowingly permit that combination to
> crash the machine, while TELCOM protects the machine, would not only be
> silly, it would be irresponsible.
>
> Unless the user directs it to do so of course, whereby my
> --allow_file_system_corruption switch would suffice.  ;-)
>
>
> On Fri, Feb 15, 2019 at 11:31 AM Brian White  wrote:
>
>> All else being equal, it IS wrong for telcom not to record whatever bytes
>> are sent.
>>
>> It's excuse is, at the time such ideas hadn't been recognized and
>> discarded yet, and the fact that telcom is part of a very tightly coupled
>> and managed system. It's not generic software that runs anywhere, it's part
>> of a rom, and so it's less of a crime to be tightly coupled with the other
>> parts of that rom, like making presumptions about what kind of data may
>> exist in a file with a certain kind of name.
>>
>> The tpdd makes no such presumptions.
>>
>> Telcom also only ever claimed to operate like a user application that
>> deals in text just like a text editor. How the text editor and telcom
>> package up data internally are their own business. They just accept
>> keystrokes and display characters. That is an entirely different domain.
>>
>> What you should ask is, when you tell BASIC to read or write from COM:,
>> does BASIC presume to modify the data?
>>
>> Similarly would you tolerate a file compressor or other encoder that
>> didn't spit back out exactly the data you put into it?
>>
>> Telcom processing the data as though it's text is like an image editor
>> adding metadata on it's own. It's an allowed part of it's job because it's
>> job is to deal in displaying a visual image to you, not to hold that data
>> in trust for something else. IT is the app whose defined role is to
>> manipulate and process the data.
>>
>> But then when you take that image data the the image editor made, and put
>> it into a zip file, and save it to a thumb drive

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Kevin Becker]

Please make it stop


> On Feb 15, 2019, at 10:56 PM, Brian White  wrote:
> 
> By tightly coupled, I mean that Telcom has inside  knowledge of the rest of 
> the system.
> 
> The tpdd does not.
> 
> (nor the dvi, and I'd put money on the chipmunk too)
> 
> The only reason you can produce examples of other software and systems doing 
> things like that, is because it's something that used to be very common, and 
> even today every new programmer takes some time to learn better, and some 
> never do. But by now it is recognized as an antipattern. After 
> Joe-self-taught-teenager-programmer-from-the-70s-80s writes a bunch of such 
> stuff, it's all fine at first, and only later he discovers that he has 
> written an unmaintainable and unportable brick. Customer wants the tiniest 
> change and it's practically impossible, because the code is riddled with 
> assumptions that should never have been made.
> 
> 
> John did raise some points that no tpdd emulator to date has emulated the 
> drive *really* though, else they would use disk images instead of files. And 
> the knitting machines don't use files either.
> 
> I personally don't think that's a strong enough argument, but it is at least 
> an argument. I think that just means a tpdd emulator is a filesystem instead 
> of a disk. OK, so I would not tolerate a filesystem that modified the files 
> either.
> 
> 
> As to Mikes point about causing harm:
> 
> Preserving data is never causing harm.
> 
> If there is harmful data, then the harm was caused by the thing that created 
> that harmful data.
> 
> I see that as "two wrongs don't make a right".
> 
> If a text editor added eof, that was a bad text editor, and it's more helpful 
> to the user to have the bad data and thus indirectly the cause of the bad 
> data, be exposed and corrected, rather than silently allowed to persist and 
> even propagate over time. So that you go on thinking you actually have good 
> data when you don't and it just fails tomorrow in any other context.
> 
> -- 
> bkw
> 
> 
> On Fri, Feb 15, 2019, 2:44 PM Gary Weber   wrote:
>   GW>> Since when is it NOT wrong for TELCOM to disallow recording of  
> into a .DO file being downloaded, but it IS wrong for the LaddieAlpha/TS-DOS 
> combination during the same operation?
>   BW>  the fact that telcom is part of a very tightly coupled and managed 
> system. It's not generic software that runs anywhere  
> 
> You have clearly, and strongly, stated the some very sound engineering 
> principles.   Honestly I doubt anyone (or at least many) would question the 
> principles in the universal generic sense.  
> 
> But I would assert LaddieAlpha is not universal or generic.  It has a very 
> defined stated purpose, and has always made specific concessions for Model Ts 
> & WP2s.   Using it outside of this context is at your own peril, so to speak. 
>  And you're bringing up not just edge cases but actually *corner* cases to 
> the usage model.
> 
> Secondly, TELCOM doesn't know where data is coming from via the COM: port, so 
> I question the claim that it is part of a very tightly coupled and managed 
> system in the context of how it downloads data.  Rather, it filters the data 
> to be appropriate to the machine.  The LaddieAlpha/TS-DOS coupling is no more 
> nefarious than this, and to knowingly permit that combination to crash the 
> machine, while TELCOM protects the machine, would not only be silly, it would 
> be irresponsible.  
> 
> Unless the user directs it to do so of course, whereby my 
> --allow_file_system_corruption switch would suffice.  ;-) 
> 
> 
> On Fri, Feb 15, 2019 at 11:31 AM Brian White  > wrote:
> All else being equal, it IS wrong for telcom not to record whatever bytes are 
> sent.
> 
> It's excuse is, at the time such ideas hadn't been recognized and discarded 
> yet, and the fact that telcom is part of a very tightly coupled and managed 
> system. It's not generic software that runs anywhere, it's part of a rom, and 
> so it's less of a crime to be tightly coupled with the other parts of that 
> rom, like making presumptions about what kind of data may exist in a file 
> with a certain kind of name. 
> 
> The tpdd makes no such presumptions.
> 
> Telcom also only ever claimed to operate like a user application that deals 
> in text just like a text editor. How the text editor and telcom package up 
> data internally are their own business. They just accept keystrokes and 
> display characters. That is an entirely different domain.
> 
> What you should ask is, when you tell BASIC to read or write from COM:, does 
> BASIC presume to modify the data?
> 
> Similarly would you tolerate a file compressor or other encoder that didn't 
> spit back out exactly the data you put into it?
> 
> Telcom processing the data as though it's text is like an image editor adding 
> metadata on it's own. It's an allowed part of it's job because it's job is to 
> deal in displaying a visu

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[Brian White]

Make what stop? And why? It's a technical discussion of a techinal topic on
a technical topic mail list. Why be on a mail list about a computer if you
don't like hashing out computery details like that?

-- 
bkw

On Fri, Feb 15, 2019, 11:28 PM Kevin Becker  Please make it stop
>
>
> On Feb 15, 2019, at 10:56 PM, Brian White  wrote:
>
> By tightly coupled, I mean that Telcom has inside  knowledge of the rest
> of the system.
>
> The tpdd does not.
>
> (nor the dvi, and I'd put money on the chipmunk too)
>
> The only reason you can produce examples of other software and systems
> doing things like that, is because it's something that used to be very
> common, and even today every new programmer takes some time to learn
> better, and some never do. But by now it is recognized as an antipattern.
> After Joe-self-taught-teenager-programmer-from-the-70s-80s writes a bunch
> of such stuff, it's all fine at first, and only later he discovers that he
> has written an unmaintainable and unportable brick. Customer wants the
> tiniest change and it's practically impossible, because the code is riddled
> with assumptions that should never have been made.
>
>
> John did raise some points that no tpdd emulator to date has emulated the
> drive *really* though, else they would use disk images instead of files.
> And the knitting machines don't use files either.
>
> I personally don't think that's a strong enough argument, but it is at
> least an argument. I think that just means a tpdd emulator is a filesystem
> instead of a disk. OK, so I would not tolerate a filesystem that modified
> the files either.
>
>
> As to Mikes point about causing harm:
>
> Preserving data is never causing harm.
>
> If there is harmful data, then the harm was caused by the thing that
> created that harmful data.
>
> I see that as "two wrongs don't make a right".
>
> If a text editor added eof, that was a bad text editor, and it's more
> helpful to the user to have the bad data and thus indirectly the cause of
> the bad data, be exposed and corrected, rather than silently allowed to
> persist and even propagate over time. So that you go on thinking you
> actually have good data when you don't and it just fails tomorrow in any
> other context.
>
> --
> bkw
>
>
> On Fri, Feb 15, 2019, 2:44 PM Gary Weber 
>>   GW>> Since when is it NOT wrong for TELCOM to disallow recording of
>>  into a .DO file being downloaded, but it IS wrong for the
>> LaddieAlpha/TS-DOS combination during the same operation?
>>   BW>  the fact that telcom is part of a very tightly coupled and managed
>> system. It's not generic software that runs anywhere
>>
>> You have clearly, and strongly, stated the some very sound engineering
>> principles.   Honestly I doubt anyone (or at least many) would question the
>> principles in the universal generic sense.
>>
>> But I would assert LaddieAlpha is not universal or generic.  It has a
>> very defined stated purpose, and has always made specific concessions for
>> Model Ts & WP2s.   Using it outside of this context is at your own peril,
>> so to speak.  And you're bringing up not just edge cases but actually
>> *corner* cases to the usage model.
>>
>> Secondly, TELCOM doesn't know where data is coming from via the COM:
>> port, so I question the claim that it is part of a very tightly coupled and
>> managed system in the context of how it downloads data.  Rather, it filters
>> the data to be appropriate to the machine.  The LaddieAlpha/TS-DOS coupling
>> is no more nefarious than this, and to knowingly permit that combination to
>> crash the machine, while TELCOM protects the machine, would not only be
>> silly, it would be irresponsible.
>>
>> Unless the user directs it to do so of course, whereby my
>> --allow_file_system_corruption switch would suffice.  ;-)
>>
>>
>> On Fri, Feb 15, 2019 at 11:31 AM Brian White  wrote:
>>
>>> All else being equal, it IS wrong for telcom not to record whatever
>>> bytes are sent.
>>>
>>> It's excuse is, at the time such ideas hadn't been recognized and
>>> discarded yet, and the fact that telcom is part of a very tightly coupled
>>> and managed system. It's not generic software that runs anywhere, it's part
>>> of a rom, and so it's less of a crime to be tightly coupled with the other
>>> parts of that rom, like making presumptions about what kind of data may
>>> exist in a file with a certain kind of name.
>>>
>>> The tpdd makes no such presumptions.
>>>
>>> Telcom also only ever claimed to operate like a user application that
>>> deals in text just like a text editor. How the text editor and telcom
>>> package up data internally are their own business. They just accept
>>> keystrokes and display characters. That is an entirely different domain.
>>>
>>> What you should ask is, when you tell BASIC to read or write from COM:,
>>> does BASIC presume to modify the data?
>>>
>>> Similarly would you tolerate a file compressor or other encoder that
>>> didn't spit back out exactly the data you put into it

Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

[John R. Hogerhuis]

On Fri, Feb 15, 2019, 8:28 PM Kevin Becker  Please make it stop
>

I agree the discussion has probably reached the point of diminishing
returns.

-- John.