Valid points Brian. An emulator should just emulate. The differences in line endings between, Mac, Linux, and Windows can be a real pain. Without a ^Z at the end of a file you are basically dead in the water when trying to load a .DO file. If you have a standard text file that is generated on a Linux machine and you rename it to a .DO, you end up with a file that you cannot load onto your Model-T due to the line endings and the lack of EOF. Having the ability to "Fix" the file so it doesn't break the machine would be nice since doing it by hand is a pain. But as you have stated, it leads to corrupt files being propagated all over the place.
If I happen to make a change to mComm for Android, I would most likely have the default behavior as it is now and add a checkbox setting which would turn on the ability to fix line endings and file endings. Kurt On Tue, Dec 24, 2019, at 2:21 PM, Brian White wrote: > > > On Mon, Dec 23, 2019, 9:02 PM Kurt McCullum <ku...@fastmail.com> wrote: >> __ >> Willard >> >> I just checked the mComm Android code. Unfortunately, it does not modify the >> existing files to check for proper EOL and EOF characters. It gives you a >> byte for byte representation of the file. > > > THIS is what it should do. Please don't inject a 2nd mystery to correct some > other mystery. > > Consider: Why do these files currently have bad bytes in them? We don't know, > but you can ask yourself this: Did any M100 ever create them with those > incorrect bytes? > > No M100 ever did that. That means, aside from text files created from scratch > elsewhere and named *.do, some other bit of software somewhere sometime > thought it was being "helpful" and modified them along the way. > > That other software, like an ftp client or a Windows text editor, thought it > was "fixing" something when it munged the data, just like you are considering > and like John already did, but all it did was create these bad files. > > This is a case of "two wrongs don't make a right". > > It is insane to have a file transfer utility modifying the data along the > way. You have to be able to trust that your lower layers are not changing > things under your feet. > > It's really a disservice that John made Laddie munge the data, because now > you have different tpdd servers that claim to perform the same function, but > which produce different results from the same data. And Laddie is the > deviant, not everything else. > > Now we have a world where one person using Laddie will assume they know what > a proper .do file must look like, because they tested it and it worked. > Another person will fail with the same files because they aren't using Laddie > and wonder what the hell is wrong. They might even come to the conclusion > that all other tpdd servers are broken because only Laddie "works"... or they > may think that they must have somehow messed up the files when they > downloaded them or something, because they aren't working... > > Meanwhile, a real tpdd, which a tpdd server purports to emulate, does NOT > munge the data. If you saved a file from a M100 to a real drive and then > looked at it from any other tpdd client like TpddTool.py, it will be exactly > as it was on the M100. > > Going the other way, If you copied a file from a host to a real disk with > tpddtool and then loaded that file on a M100 from a real drive, neither > tpddtool nor the real drive will have munged the data. > > The "I know this file is good because it worked 500 times" file is in fact a > bad file. But because it "worked", it ends up proliferating and being > documented as a proven working example, and archived, saved on web sites and > archive.org, all while wrong. > > It's saner to simply document what a .do file is supposed to look like, and > it should simply look like that anywhere it exists, be it on a M100 or on a > pc or on a web site. > > There are also intentionally malformed files that are broken if you "fix" > them. Or there could be. It's not a disk drive's place to assert any > knowledge of what the bytes in the files it stores mean. If disk drives > "fixed" invalid .ba files a lot of things would break. > > -- > bkw > > > >> I may have some time of Christmas to add that in for you. I'll keep you >> posted. >> >> The current version is 1.9 and if you want I can email that directly to you >> since the members file area is down. >> >> Kurt >> >> On Mon, Dec 23, 2019, at 4:55 PM, Willard Goosey wrote: >>> In article <3d9d68de-1198-44da-bfa1-b9e15da6b...@www.fastmail.com>, >>> Kurt McCullum <ku...@fastmail.com> wrote: >>> > Are you using the latest version of mComm for Android, or an early one? >>> >>> An early one. 1.41 IIRC. Works fine for me! >>> >>> It just happens to be the version I had saved locally. No particular other >>> reason, except that club100 member files are still down. >>> >>> Debugging php is probably bad for you, Ken may have to wait for his doctor >>> to clear him for such pain. ;-) >>> >>> Willard >>> >>> -- >>> Willard Goosey goo...@sdc.org >>> Socorro, New Mexico, USA >>> I search my heart and find Cimmeria, land of Darkness and the Night. >>> --Robert E. Howard >>> >>
