From: muta...@gmail.com   
      
   On Friday, August 12, 2022 at 11:57:37 PM UTC+8, s_dubrovich@yahoo.com wrote:   
   > On Tuesday, August 9, 2022 at 2:52:09 PM UTC-5, muta...@gmail.com wrote:    
   > > On Wednesday, August 10, 2022 at 1:32:26 AM UTC+8, s_dub...@yahoo.com   
   wrote:    
   > > > On Thursday, August 4, 2022 at 9:36:39 PM UTC-5, muta...@gmail.com   
   wrote:    
   > > > > On Thursday, August 4, 2022 at 10:04:54 PM UTC+8, JJ wrote:    
   > > > > > On Wed, 3 Aug 2022 15:36:27 -0700 (PDT), muta...@gmail.com wrote:    
   > > > > > >    
   > > > > > > Hi JJ. Thanks for your thoughtful response.    
   > > > > > >    
   > > > > > > Do you think, with the benefit of hindsight, there should have   
   been a    
   > > > > > > mechanism for what we now know as host file access?    
   > > > >    
   > > > > > It would be nice, but don't you think it's too late for that?    
   > > > > No. I am trying to extract philosophy.    
   > > > >    
   > > > > If you think this would be nice, then what    
   > > > > would you propose exactly?    
   > > > >    
   > > > > And could this have been figured out decades ago?    
   > > > >    
   > > > > Or was something missing?    
   > > > >    
   > > > > At the same time you can solve the problem of    
   > > > > people in real life, for years, taking their chances    
   > > > > with line noise. Before error-correcting modems.    
   > > > > Does error-correction belong in modems or applications,    
   > > > > as happened in real life?    
   > > > >    
   > > > > Or does it belong in the os?    
   > > > Here is where a driver for the device is useful. The OS should only get   
   notification of device error.    
   > > > The driver for the device would be the place to attempt error   
   correction, at the least, return a fail status to the OS.    
   > > Ok, good point. I don't really understand drivers.   
   > Think 'Device Control'. A device driver is the controlling code for the   
   device, that is, the device specific code.   
   > > So far in pdos I have not attempted or needed such a concept.    
   > > > >    
   > > > > If someone types:    
   > > > >    
   > > > > rm -fr /scratch    
   > > > >    
   > > > > And line noise of "enter" happens after    
   > > > > the "/", who failed to think things through?    
   > > > The shell. It's design fails to catch that and issue a warning and a   
   confirm request, istm.    
   > > > Your example uses the keyboard to communicate to the console through the   
   'shell'.    
   > > > Very early on, before the ibm pc this was handled through the i8255,   
   with the pc this changed.    
   > > > reference note of modes of operation..    
   > > > https://en.wikipedia.org/wiki/Intel_8255    
   > > >    
   > > > The OS kernel should not have to deal with these low level details, a   
   specific driver should handle it.    
   > > > Same with error detection and attempted correction. It should be handled   
   by the specific driver.    
   > > So for example, if an app does an fseek of a com    
   > > Port to an earlier position, what I want is for the com port    
   > > to be reset, which Bochs detects and does a rewind    
   > > of the host file, then reads done from the com port to    
   > > get to the right position. That is something that would go    
   > > into a driver?   
   > Yes. Bochs has provided a driver for you.    
   > From your description, Bochs is treating the COM: as a rewindable Mag Tape   
   device, by chance.    
   > Generally though, COM: has a device attached that is not rewindable.    
   > A Modem, paper tape reader RDR:, paper tape punch PUN:, a console, provide a   
   data stream that is not rewindable. (A limited cheat would be to write the   
   input stream to a temporary file, and perform the seek on the temporary file.   
   The temp file would    
   need to be in fast memory, a huge ring buffer basically).    
   >    
   > Each of these devices require code specific to the device, a device driver.   
   > > > > > Serial port is    
   > > > > > now considered as a legacy (but not dead yet) communication port.   
   It's no    
   > > > > > longer in development and it's no longer widely used except in   
   industrial    
   > > > > > and business fields. What's your intended use case scenario for it,   
   anyway?    
   > > >    
   > > > > Host file access is what I am after right now.    
   > > > What is this 'Host'? Bochs? -- or are you calling your OS the host? -or-   
   ?    
   > > I am running pdos under Bochs on an Android phone.    
   > >    
   > > Pdos is the guest os and the android is the host.    
   > >    
   > > I thought this was standard terminology?   
   > It is, but I didn't see mention of Android.    
   > I didn't know you could do what you're doing on the Android phone. Kudos to   
   you!   
   > > > > > Cause I could think that it's for a special use case only.    
   > > > > I'm more interested in the philosophy of    
   > > > > external communication.    
   > > > You develop in C I think, so dig into the topic of streams.    
   > > > -- It's likely you have, forgive me for being a dunce.    
   > > > In addition to stdin, stdout, stderr, you could add stdtmp where stdtmp   
   is a file already in an opened state, like the others, to catch COM1: input   
   stream through the stdtmp driver.    
   > > I don't have a problem at this level.    
   > > For the purposes of this conversation I am happy    
   > > to do an fopen of com1 r+b    
   > > > The hard part is determining End Of Transmission.    
   > > For normal com port usage I would rely on the    
   > > Bios timeout. When I am accessing a host file,    
   > > I expect Bochs to give a timeout at EOF.    
   > > > Perhaps the stdtmp driver has a time-out function to catch EOT.    
   > > > When the simplest protocol is the case, where COM1: just takes byte   
   data, no control bytes are allowed to be embedded. The risk of errors is low   
   if stored in memory, or a thumb-drive.    
   > > > The risk is high if the device is slower than COM1: such as a floppy   
   drive.    
   > > > Early on, all devices were slow, so some form of transmission protocols   
   were developed.    
   > > > So think in terms a byte being converted into two bytes, each an ASCII   
   nibble.    
   > > > Prepend some ascii info and trailing check sum and you have a Intel .HEX   
   record.    
   > > > https://en.wikipedia.org/wiki/Intel_HEX    
   > > >    
   > > > Since ASCII HEX restricts bytes into the printable range, bytes outside   
   this range can be used for control.    
   > > > For example, 07h aka byte value 7, where value 7 is not printable if   
   handled by the console.    
   > > > But causes the console to 'beep'.    
   > > > The ASCII form of 07h is 30,37.    
   > > > > > > The method above, abusing the hardware, is not the only    
   > > > > > > method I have used. My pdos-generic code is already capable of    
   > > > > > > this, but relies on a cooperative bios.    
   > > > > > That's expected, since it's not part of the standard specification.   
   Though,    
   > > > > > BIOS modification is not actually required, since what's needed can   
   be    
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)