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

[Brian White]

That, (other systems), is a great example of yet another unpredicted yet
valid situation.

What if one reads the description on the tin for the tpdd emulator, which
says it emulates a tpdd...
So they try to use it with a Brother sewing machine. Is it harmless to
upper-case the filenames or modify the contents of files in that case?
Maybe the sewing machine doesn't happen to use files named *.DO, or maybe
it does, or maybe the names can be anything including .DO with no special
meaning?

Someone also mentioned upper-casing the filenames. Since when is that an
automatic safe assumption? I can create filenames with lower case letters
perfectly fine on a real machine.

All of the situations mentions where the munging is supposedly helpful, are
what's called shims, and the only reason a shim is needed is because some
other program did something bad, and now you have to do something bad as
well, in the opposite direction, just to get the final result that is the
same as if neither thing had done something bad, IE even the shim admirer
is working towards un-munging data that someone else munged, and therefore
admits the goal of not munging data!

The text editor example is just like ftp. Ancient text editors did that
(and really crappy current ones), like ancient ftp. Since then, the idea
has been recognized as more harmful than helpful, and nobody does it any
more. ftp clients still do it because they are just adhering to the
original standard. But the standard is old, and newer standards don't do
it. http does not do it. (http clients & servers may negotiate things like
gzip compression in-flight, but the data going in one end comes out the
other end faithfully)

That behavior of some old text editors to re-write line-endings or append
an eof, exists, but is also recognized as a *bad* thing, which is why
anyone doing any kind of actual work with tex files, not just programmers
but anything like examining EDI transactions or literally anything, are
told not to use notepad.exe, but to install notepad++ or any "prgrammer"
editor. none of vi, vim, emacs etc do such things, etc. Why not? Is it
because in 40 years no one has gotten around to adding this clearly helpful
feature?

Wherever you feel a need for a shim, it's a necessity to correct for
someone/something else's undesireable behavior, not a supporting argument
for doing the same thing some more.

It's bad enough that we do some other smoke & mirrors with special
filenames in order to implement subdirectory support. I don't remember
off-hand if foo.<> is a possible legal filename that a M100 could create or
not. It's a very useful feature to be able to have subdirectories, but even
this could theoretically screw something up that was otherwise legal. For
instance, is it legal/possible for a program to create a file named foo.<>
which is just used internally by the program, never loaded in TEXT or
TELCOM etc? If so, next question can that file be saved & restored to a
real disk the same as any other file? If so, then is that application
simply broken and unusable with any tpdd emulators that implement TS-DOS
directories? Are there any safe assumptions about filenames like that wrt
other clients like sewing machines and synthesizers? It's such a useful
feature, and it's been a de rigueur standard for so long by now that even
*I* would not suggest that any sane tpdd emulator should remove it. :)

I don't remember from last time I was looking, maybe that theoretical
possibility is actually allowed for by the tpdd server recognizing, or
failing to, that the client supports or expects the feature, and maybe NOT
treating those filenames specially, or sending filenames like that to show
directories, if the client is not TS-DOS?

-- 
bkw


On Wed, Feb 13, 2019 at 4:53 PM Kevin Becker  wrote:

> An option to not crash the system but also account for some of the
> scenarios Brian suggested would be to create a log file that details any
> file manipulations that happen during a transfer.  That could be useful to
> some developer trying to write a TPDD emulator for some other platform in
> the future.
>
> On Feb 13, 2019, at 4:30 PM, Gary Weber  wrote:
>
>
> Good point, Mike.   I actually think I support the opt-out feature, just
> as long as the name of the switch on the LaddieAlpha.exe command line is
> --allow_file_system_corruption
>
>
> On Wed, Feb 13, 2019 at 2:20 PM Mike Stein  wrote:
>
>> Give up, John; just add a -EOF CLI option as requested and let the user
>> guess which one will crash the system, or better yet a checkbox:
>>
>> "Crash system after loading (Y/N)?"
>>
>> Most ridiculous argument I've read in a long time; why burden an
>> inexperienced user with a choice that he/she might not understand when one
>> of the two options will crash the system?
>>
>> A good program IMO does its job with as little confusion and/or risk for
>> the user as possible, regardless of some irrelevant CS101 "principle."
>>
>> Maybe just mentioning in the documentation that an 

[M100] Option Rom Cover with DVI Cut Out

[Greg Swallow]

All:

Am wondering, thought maybe some long time ago there was mention of how to cut 
an Option ROM cover to allow for the DVI cable. Am looking, but have not been 
able to find anything. Would anyone have a link or such info?


Thanks,

GregS <><

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

[Kurt McCullum]

Thanks John. Not sure if I'll tweak anything since you have a good
solution already but I'll look at it when I have some time.
Kurt


On Wed, Feb 13, 2019, at 3:54 PM, John R. Hogerhuis wrote:
> 
> 
> On Wed, Feb 13, 2019 at 3:50 PM Kurt McCullum
>  wrote:>> __
>> Hey Jim,
>> 
>> Not having a WP-2 I would have no way of debugging the issues, so
>> definitely stick with LaddieAlpha for that. If I even come by one
>> I'll look at it but it's really not even on my radar right now.>> 
> 
> The unique bits with the WP-2 are the 8.1 names, and the fact that
> unlike TS-DOS, the WP-2 uses dir-prev. So if you enumerate the
> directory, and use arrows on the WP-2 to move backward through the
> directory, the WP-2 will send a dir-prev.> 
> Other than that, I don't remember.
> 
> -- John. 

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

[John R. Hogerhuis]

8.2 names.

-- John.

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

[John R. Hogerhuis]

On Wed, Feb 13, 2019 at 3:50 PM Kurt McCullum  wrote:

> Hey Jim,
>
> Not having a WP-2 I would have no way of debugging the issues, so
> definitely stick with LaddieAlpha for that. If I even come by one I'll look
> at it but it's really not even on my radar right now.
>
>
The unique bits with the WP-2 are the 8.1 names, and the fact that unlike
TS-DOS, the WP-2 uses dir-prev. So if you enumerate the directory, and use
arrows on the WP-2 to move backward through the directory, the WP-2 will
send a dir-prev.

Other than that, I don't remember.

-- John.

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

[Kurt McCullum]

Hey Jim,

Not having a WP-2 I would have no way of debugging the issues, so
definitely stick with LaddieAlpha for that. If I even come by one I'll
look at it but it's really not even on my radar right now.
Kurt


On Wed, Feb 13, 2019, at 3:45 PM, Jim Anderson wrote:
>> -Original Message-
>> 
>> You can indicate whether to map to 6.2 or 8.2 names.
> 
> As a WP-2 owner I really appreciate the 8.2 filename support and solid
> connectivity.  (Unfortunately, in spite of my love for mComm it
> doesn't work 100% with the WP-2... saves files OK but things get super
> weird when you try loading.  Sorry Kurt, I don't know if you'd be
> happy or sad that I've never reported this to you...)> 
>> In actuality there is some real functionality behind it.
>> Turning if OFF>> actually closes and powers down the serial port circuitry. 
>> So
>> it saves>> some battery and allows you to reset the serial port.
>> 
>> But mostly I just added it because I thought it was funny.
> 
> As a palm user from the last century, I love the joke & totally
> understand why it was needed.  :)> 
> 
> 
> 
> 
> 
> 
> jim

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

[Jim Anderson]

> -Original Message-
> 
> You can indicate whether to map to 6.2 or 8.2 names.

As a WP-2 owner I really appreciate the 8.2 filename support and solid 
connectivity.  (Unfortunately, in spite of my love for mComm it doesn't work 
100% with the WP-2... saves files OK but things get super weird when you try 
loading.  Sorry Kurt, I don't know if you'd be happy or sad that I've never 
reported this to you...)

> In actuality there is some real functionality behind it. Turning if OFF
> actually closes and powers down the serial port circuitry. So it saves
> some battery and allows you to reset the serial port.
> 
> But mostly I just added it because I thought it was funny.

As a palm user from the last century, I love the joke & totally understand why 
it was needed.  :)







jim

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

[John R. Hogerhuis]

On Wed, Feb 13, 2019 at 2:37 PM Kurt McCullum  wrote:

> John, you added the --win32 mode a few years back because the newer
> drivers were running too slow with the Prolific USB-Serial adapters. It
> allowed the cheap devices to respond fast enough so that TS-DOS was happy.
>
> Kurt
>
>
>
Oh yeah! Thanks for the reminder :-)

Moral of the story, use FTDI devices because one day John might rip out
some code forgetting why he put it there ;-)

-- John.

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

[Kurt McCullum]

John, you added the --win32 mode a few years back because the newer
drivers were running too slow with the Prolific USB-Serial adapters.
It allowed the cheap devices to respond fast enough so that TS-DOS
was happy.
Kurt


On Wed, Feb 13, 2019, at 2:34 PM, John R. Hogerhuis wrote:
> "  Brian suggested would be to create a log file that details any file
> manipulations that happen during a transfer"> 
> Maybe one day when LaddieAlpha gets a proper log file.
> 
> I don't mind adding a "Dangerous EOF/NUL removed from inloaded file...
> you're welcome" to the "standard output" noise.> And there are comments in 
> the source code.
> 
> So I wouldn't hold your breath for a "make it work" or in this case
> "crash me" option to LaddieAlpha.> 
> There are only a few options and parameters as it is now. Today, you
> can provide a serial device, or tcp socket as a parameter. You can
> indicate whether to map to 6.2 or 8.2 names. And you can put the code
> in a --win32 mode. Which at the moment I can't even remember why I
> added. I think it makes it work on older versions of the Windows .NET
> framework. And the switch functionality is pretty rudimentary, so it's
> not super easy to add new command line switches at the moment. That is
> likely to change over time.> 
> As a matter of principle I don't add "make it work" buttons. Well
> except as programmer jokes. My first TPDD emulator, DLPilot ran on the
> Palm Pilot, so it had a GUI. It simulates the appearance of a TPDD
> drive with a flashing activity indicator. It has a little OFF/ON
> button. If you don't turn it on, it doesn't work! Which is silly.> 
> In actuality there is some real functionality behind it. Turning if
> OFF actually closes and powers down the serial port circuitry. So it
> saves some battery and allows you to reset the serial port.> 
> But mostly I just added it because I thought it was funny.
> 
> Now DLPilot really got crazy on the "modify the user data" stuff since
> it supported some macros. You could for example, load a file with a
> escaped date-time macro that got expanded as the file loaded.> -- John.

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

[John R. Hogerhuis]

" Brian suggested would be to create a log file that details any file
manipulations that happen during a transfer"

Maybe one day when LaddieAlpha gets a proper log file.

I don't mind adding a "Dangerous EOF/NUL removed from inloaded file...
you're welcome" to the "standard output" noise.
And there are comments in the source code.

So I wouldn't hold your breath for a "make it work" or in this case "crash
me" option to LaddieAlpha.

There are only a few options and parameters as it is now. Today, you can
provide a serial device, or tcp socket as a parameter. You can indicate
whether to map to 6.2 or 8.2 names. And you can put the code in a --win32
mode. Which at the moment I can't even remember why I added. I think it
makes it work on older versions of the Windows .NET framework. And the
switch functionality is pretty rudimentary, so it's not super easy to add
new command line switches at the moment. That is likely to change over time.

As a matter of principle I don't add "make it work" buttons. Well except as
programmer jokes. My first TPDD emulator, DLPilot ran on the Palm Pilot, so
it had a GUI. It simulates the appearance of a TPDD drive with a flashing
activity indicator. It has a little OFF/ON button. If you don't turn it on,
it doesn't work! Which is silly.

In actuality there is some real functionality behind it. Turning if OFF
actually closes and powers down the serial port circuitry. So it saves some
battery and allows you to reset the serial port.

But mostly I just added it because I thought it was funny.

Now DLPilot really got crazy on the "modify the user data" stuff since it
supported some macros. You could for example, load a file with a escaped
date-time macro that got expanded as the file loaded.

-- John.

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

[Mike Stein]

- Original Message - 
From: "Jim Anderson" 
To: 
Sent: Wednesday, February 13, 2019 1:46 PM
Subject: Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)


> Maybe there should be an option to enable transfer of files without 
> modification, and maybe there shouldn't.  John's making software to help 
> users transfer files, so these choices are really up to him.
---

Apparently not; apparently John's  refusal to add a "Crash and Corrupt 
Filesystem after Load" option demonstrates his "ignorance" and "lack of 
integrity."

We're talking about a file server program for a very specific set of clients 
and models that solves two particularly insidious issues that cause problems 
for users over and over again, usually leading to the loss of (sometimes 
important!) data. 

This is a very good thing IMO. Why on earth make usage more complicated by 
offering options that will cause harm and should never be chosen?

If you really want to purposely crash the system and lose your data, feel free 
to use any of the other less friendly transfer options.

m

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

[Kevin Becker]

An option to not crash the system but also account for some of the scenarios 
Brian suggested would be to create a log file that details any file 
manipulations that happen during a transfer.  That could be useful to some 
developer trying to write a TPDD emulator for some other platform in the future.

> On Feb 13, 2019, at 4:30 PM, Gary Weber  wrote:
> 
> 
> Good point, Mike.   I actually think I support the opt-out feature, just as 
> long as the name of the switch on the LaddieAlpha.exe command line is  
> --allow_file_system_corruption
> 
> 
> On Wed, Feb 13, 2019 at 2:20 PM Mike Stein  > wrote:
> Give up, John; just add a -EOF CLI option as requested and let the user guess 
> which one will crash the system, or better yet a checkbox:
>  
> "Crash system after loading (Y/N)?"
>  
> Most ridiculous argument I've read in a long time; why burden an 
> inexperienced user with a choice that he/she might not understand when one of 
> the two options will crash the system?
>  
> A good program IMO does its job with as little confusion and/or risk for the 
> user as possible, regardless of some irrelevant CS101 "principle."
>  
> Maybe just mentioning in the documentation that an inappropriate CTL-Z will 
> be stripped and the extension changed if necessary will satisfy the zealots...
>  
> Sheesh!
> - Original Message -
> From: John R. Hogerhuis 
> To: m...@bitchin100.com 
> Sent: Wednesday, February 13, 2019 2:14 AM
> Subject: Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)
> 
> "That places the obligation on the wrong party."
> 
> It's not a legal issue. It's just functionality.
> 
> Arguing on other turf (FTP, or checksum algorithms, etc) is to totally ignore 
> the issue.
> 
> But really, you're arguing on the basis of principle that I agree with in 
> principle, but in real life an engineer weighs the issues and can set ANY 
> principle aside. 
> Yes my decision will violate your assumptions in a hypothetical scenario. I 
> guess.
> 
> That's what I did here, I set a principle aside, because there is zero, or 
> really, negative, value in inloading a character that crashes the machine.
> 
> The exception to the rule serves the greater good, such as it is with our 
> little hobby. But I make decisions just like this in work, and it is part of 
> what makes me a good engineer.
> 
> -- John.
> 
> 
> -- 
> Gary Weber
> g...@web8201.com 

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

[Josh Malone]

Open-source convention would have the argument called   --dont-blame-laddiealpha

:)


On Wed, Feb 13, 2019 at 4:30 PM Gary Weber  wrote:
>
>
> Good point, Mike.   I actually think I support the opt-out feature, just as 
> long as the name of the switch on the LaddieAlpha.exe command line is  
> --allow_file_system_corruption

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

[Gary Weber]

Good point, Mike.   I actually think I support the opt-out feature, just as
long as the name of the switch on the LaddieAlpha.exe command line is
--allow_file_system_corruption


On Wed, Feb 13, 2019 at 2:20 PM Mike Stein  wrote:

> Give up, John; just add a -EOF CLI option as requested and let the user
> guess which one will crash the system, or better yet a checkbox:
>
> "Crash system after loading (Y/N)?"
>
> Most ridiculous argument I've read in a long time; why burden an
> inexperienced user with a choice that he/she might not understand when one
> of the two options will crash the system?
>
> A good program IMO does its job with as little confusion and/or risk for
> the user as possible, regardless of some irrelevant CS101 "principle."
>
> Maybe just mentioning in the documentation that an inappropriate CTL-Z
> will be stripped and the extension changed if necessary will satisfy the
> zealots...
>
> Sheesh!
>
> - Original Message -
> *From:* John R. Hogerhuis 
> *To:* m...@bitchin100.com
> *Sent:* Wednesday, February 13, 2019 2:14 AM
> *Subject:* Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)
>
> "That places the obligation on the wrong party."
>
> It's not a legal issue. It's just functionality.
>
> Arguing on other turf (FTP, or checksum algorithms, etc) is to totally
> ignore the issue.
>
> But really, you're arguing on the basis of principle that I agree with in
> principle, but in real life an engineer weighs the issues and can set ANY
> principle aside.
> Yes my decision will violate your assumptions in a hypothetical scenario.
> I guess.
>
> That's what I did here, I set a principle aside, because there is zero, or
> really, negative, value in inloading a character that crashes the machine.
>
> The exception to the rule serves the greater good, such as it is with our
> little hobby. But I make decisions just like this in work, and it is part
> of what makes me a good engineer.
>
> -- John.
>
>

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

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

[Mike Stein]

Give up, John; just add a -EOF CLI option as requested and let the user guess 
which one will crash the system, or better yet a checkbox:

"Crash system after loading (Y/N)?"

Most ridiculous argument I've read in a long time; why burden an inexperienced 
user with a choice that he/she might not understand when one of the two options 
will crash the system?

A good program IMO does its job with as little confusion and/or risk for the 
user as possible, regardless of some irrelevant CS101 "principle."

Maybe just mentioning in the documentation that an inappropriate CTL-Z will be 
stripped and the extension changed if necessary will satisfy the zealots...

Sheesh!
  - Original Message - 
  From: John R. Hogerhuis 
  To: m...@bitchin100.com 
  Sent: Wednesday, February 13, 2019 2:14 AM
  Subject: Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)


  "That places the obligation on the wrong party."

  It's not a legal issue. It's just functionality.

  Arguing on other turf (FTP, or checksum algorithms, etc) is to totally ignore 
the issue.

  But really, you're arguing on the basis of principle that I agree with in 
principle, but in real life an engineer weighs the issues and can set ANY 
principle aside. 
  Yes my decision will violate your assumptions in a hypothetical scenario. I 
guess.

  That's what I did here, I set a principle aside, because there is zero, or 
really, negative, value in inloading a character that crashes the machine.


  The exception to the rule serves the greater good, such as it is with our 
little hobby. But I make decisions just like this in work, and it is part of 
what makes me a good engineer.

  -- John.

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

[Jim Anderson]

> -Original Message-
> 
> The operating system A files compatible with operating system B
> seems to be more of a job for a translator, not a disk emulator.

Here's the thing - it's both.  If it were purely a disk emulator, it'd put the 
files into a 200k disk image file on the PC end of things and we'd get to treat 
it like a black box, or maybe some kind soul would write another utility to 
copy and translate text files in and out of the disk image files.  LaddieAlpha 
is a translator in the sense that it's taking files and folders from whatever 
filesystem the host OS uses and making them visible to the Model T DOS in a 
form it will understand.  Among other things, this means translating filenames 
to uppercase, truncating filenames to 6.2 characters in length, possibly more 
filename mangling if said truncation results in namespace collision, etc.

I like data integrity as much as the next guy, but having said that, there's a 
place for 'low level' software that preserves the data integrity 100%, and then 
there's a place for software which does whatever it can to make life easier for 
the user, including making assumptions that .DO files should contain text and 
should not contain an extraneous EOF if its presence in a text document on a 
Model T leads more or less immediately to filesystem corruption.

Maybe there should be an option to enable transfer of files without 
modification, and maybe there shouldn't.  John's making software to help users 
transfer files, so these choices are really up to him.







jim

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

[Rick Shear]

I tend to fall on the side of adding a command line switch to turn off the
function if not desired, but the default could be to strip/modify.  The
operating system A files compatible with operating system B seems to be
more of a job for a translator, not a disk emulator.  However if the disk
emulator wishes to perform this function, I see no problem with it.  I
would just think having a command line switch to turn off the function if
so desired, would allow for any type of situation should someone choose to
do so.

Just my 2 cents worth.  Ultimately, it is the software author that makes
these decisions, so I'm not going to gripe either way.  After all, for what
he charges :D, I won't be picky and just be happy to have a utility that
works as well as his software does.  If I feel the need to send over
something as a test like Brian was speaking of, I'll just use an older
version that wouldn't strip the characters.

Rick

On Wed, Feb 13, 2019 at 7:28 AM Jeffrey Birt  wrote:

> I have read most of these posts with a mixture of sadness and amusement.
> Sadness because people get so upset over something like this and amusement
> for the same reason.
>
>
>
> Starting from the begging, I open my text editor and type in my text. I
> save it and magically an EOF character is appended to the end of the file.
> I did not ask for it to be there, there was no dialog box or warning that
> it was going to happen. It is an artifact of how the system work. When I
> open that text file, I only see my text, the EOF has been stripped from my
> file. Again, it is how the system is designed work.
>
>
>
> Making system A talk to system B is all about data manipulation. After all
> they are two different beasts with different expectations and so the
> program that is designed to communicate between them should seamlessly and
> silently handle these differences for the user.
>
>
>
> For example, an EOF is a valid character on system A but not on system B
> so if reading a file on A and sending to B I would not send the EOF. I
> might replace it instead with what system B expects to mark the EOF (which
> if my faulty early morning memory serves, if you are using a terminal
> program to transfer a file you have to hit CTRL-C, or something, to let the
> Model T know the EOF has been reached. In effect you are mapping control
> characters form system A to system B.
>
>
>
> Years ago, I wrote a program to drip-feed GCode to a CNC machine whose
> controller had some particular requirements in both the data itself and
> handshaking. So, I read in a text file and ‘manipulated’ the data so it
> could be sent to the controller without incident. There were no check boxes
> to not ‘manipulate’ the data as that was one of the main purposes of the
> program and to not do so meant most likely locking up the CNC controller
> whilst cutting a part, which is BAD.
>
>
>
> Carrying an ideal like “don’t manipulate the data” past any sort of
> logical consideration is encroaching on the border of zealotry.
>
>
>
> Jeff_Birt
>
>
>
> *From:* M100  *On Behalf Of *John R.
> Hogerhuis
> *Sent:* Wednesday, February 13, 2019 1:14 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)
>
>
>
> "That places the obligation on the wrong party."
>
> It's not a legal issue. It's just functionality.
>
> Arguing on other turf (FTP, or checksum algorithms, etc) is to totally
> ignore the issue.
>
> But really, you're arguing on the basis of principle that I agree with in
> principle, but in real life an engineer weighs the issues and can set ANY
> principle aside.
> Yes my decision will violate your assumptions in a hypothetical scenario.
> I guess.
>
>

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

[Jeffrey Birt]

I have read most of these posts with a mixture of sadness and amusement. 
Sadness because people get so upset over something like this and amusement for 
the same reason.

 

Starting from the begging, I open my text editor and type in my text. I save it 
and magically an EOF character is appended to the end of the file. I did not 
ask for it to be there, there was no dialog box or warning that it was going to 
happen. It is an artifact of how the system work. When I open that text file, I 
only see my text, the EOF has been stripped from my file. Again, it is how the 
system is designed work.

 

Making system A talk to system B is all about data manipulation. After all they 
are two different beasts with different expectations and so the program that is 
designed to communicate between them should seamlessly and silently handle 
these differences for the user. 

 

For example, an EOF is a valid character on system A but not on system B so if 
reading a file on A and sending to B I would not send the EOF. I might replace 
it instead with what system B expects to mark the EOF (which if my faulty early 
morning memory serves, if you are using a terminal program to transfer a file 
you have to hit CTRL-C, or something, to let the Model T know the EOF has been 
reached. In effect you are mapping control characters form system A to system B.

 

Years ago, I wrote a program to drip-feed GCode to a CNC machine whose 
controller had some particular requirements in both the data itself and 
handshaking. So, I read in a text file and ‘manipulated’ the data so it could 
be sent to the controller without incident. There were no check boxes to not 
‘manipulate’ the data as that was one of the main purposes of the program and 
to not do so meant most likely locking up the CNC controller whilst cutting a 
part, which is BAD.

 

Carrying an ideal like “don’t manipulate the data” past any sort of logical 
consideration is encroaching on the border of zealotry. 

 

Jeff_Birt

 

From: M100  On Behalf Of John R. Hogerhuis
Sent: Wednesday, February 13, 2019 1:14 AM
To: m...@bitchin100.com
Subject: Re: [M100] Weird "bug" with TS-DOS 4.0 (ROM version)

 

"That places the obligation on the wrong party."

It's not a legal issue. It's just functionality.

Arguing on other turf (FTP, or checksum algorithms, etc) is to totally ignore 
the issue.

But really, you're arguing on the basis of principle that I agree with in 
principle, but in real life an engineer weighs the issues and can set ANY 
principle aside. 
Yes my decision will violate your assumptions in a hypothetical scenario. I 
guess.