In response to Mike. I got your entoke.exe file, but it on a Win10 computer and it only works on 32-bit computers. Have a Win95 computer here, so maybe I'll give it a go on it. If Win95 isn't 16-bit.... Looking forward to Bob's version!
Curtis On Thu, Oct 21, 2021 at 1:18 PM John R. Hogerhuis <[email protected]> wrote: > The closest thing to a perfect solution... that just works... is for the > disk service to present the proper extension instead of the incorrect one. > That's what Laddiealpha does. It peeks at beginning of the file to see if > it's a binary file and automatically presents a correct extension to TSDOS. > Whether the user knows how to load that file is a separate concern. But I > figure people will simply ask on list. > > Other ways to go: > > Do not present the file at all in the directory if a mismatch is detected. > The user will see it as a mystery but they can read their documentation or > ask on list and the mystery will be resolved. Another idea would be to > rename it in some way to be clearly bad like "FILE.><" So it's not just > missing. > > Present the filename as is. But when at the protocol level the file is > opened or on the first read then an error is returned based on inspection > of the file. TSDOS or whatever will report the error and the user may > figure it out or they will ask on list. I haven't explored this but > theoretically it should be feasible. > > Embed a tokenizer in the file server to automatically make the content > match the extension. This won't always work. And it would have to be laptop > model aware since 100 vs NEC tokens. > > -- John. > >
