home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.development      Operating system development chatter      4,255 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,210 of 4,255   
   mutazilah@gmail.com to All   
   Re: com port   
   03 Aug 22 15:36:27   
   
   From: muta...@gmail.com   
      
   On Wednesday, August 3, 2022 at 10:59:45 PM UTC+8, JJ wrote:   
   > On Tue, 2 Aug 2022 12:45:53 -0700 (PDT), muta...@gmail.com wrote:   
   > >   
   > > You just described what currently happens.   
   > >   
   > > I just described what could happen, including the ability to seek.   
   > >   
   > > Is there a reason why my proposal wouldn't work?   
   > >   
   > > Assuming my proposal would work,   
   > > does it provide a new conceptual model   
   > > for accessing external files?   
   > >   
   > > Perhaps the simplest form of networking?   
   > To achieve what you want, there has to be an application at each endpoint.   
   > The implementation can not be done only at one endpoint. There has to be at   
   > least the server and the client part to communicate between endpoints, since   
   > serial port has no concept of file size (and file pointer).   
   >   
   > Serial port's lines/statuses are meant for handling the communication   
   > between two serial port endpoints, which includes data flow. While they can   
   > be used for application level communication, it would decrease the   
   > communication handling capability. e.g. no way to know whether the other   
   > endpoint is ready to receive data or not; or no way to interrupt and notify   
   > the other endpoint that, the received data is corrupted and needs to be   
   > resent.   
   >   
   > Since `file` exists in application level implementation, anything related to   
   > it should be implemented at application level rather than hardware level.   
   > Hardware things have their own purposes for good reasons. Reusing them for   
   > application things would decrease the hardware's basic capability and/or   
   > performance. That should only be done if the two endpoints is connected   
   > using only 3-wires cable, instead of the full e.g. 7-wires cable. It's not   
   > wrong, but it should be avoided.   
      
   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?   
      
   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.   
      
   The hardware could also have been designed with   
   another wire if you think the existing wires cannot be   
   repurposed.   
      
   It's a good point that with a serial cable you could   
   have data corruption so ideally you want a crc and error   
   correction. When that is added do you end up   
   with SLIP/PPP?   
      
   Maybe this crude method, relying on error-free   
   communication, could be used while waiting for   
   SLIP/PPP to be implemented?   
      
   Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca