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 2,874 of 4,255    |
|    mutazilah@gmail.com to Scott Lurndal    |
|    Re: news galore    |
|    17 Oct 21 00:11:59    |
   
   From: muta...@gmail.com   
      
   I was getting ready to implement my zmodem file transfer   
   using the new fopen("COM1", "r+b") when I realized that   
   sometimes you want to read from stdin and write to stdout.   
   So it is better to encapsulate the opening of the COM port.   
      
   And in fact, for some reason you may wish to read from   
   COM1 and write to COM2, or write to PRT (maybe it is   
   faster). If the user has the ability to wire these things up,   
   e.g. maybe the TX pin is broken on COM1, then the software   
   should probably be flexible enough to support two   
   comms lines.   
      
   On a mainframe this is particularly important as you can't   
   have a read and write active at the same time. I guess that   
   means it is not full duplex.   
      
   And then I was reminded of this:   
      
      
   On Wednesday, October 13, 2021 at 11:16:00 AM UTC+11, Scott Lurndal wrote:   
      
      
   > cp->sd = socket(AF_INET, SOCK_STREAM, 0);   
   > if (cp->sd == -1) {   
   > fprintf(stderr, "%s: Unable to create socket: %s\n",   
   > myname, strerror(errno));   
   > return NULL;   
   > }   
   >   
   > fprintf(stderr, "Connecting to %s using port %d\n",   
   > cp->hostname, port);   
   > addr.sin_family = hp->h_addrtype;   
   > addr.sin_port = port;   
   > fprintf(stderr, "IP address is %u.%u.%u.%u\n",   
   > (unsigned char)hp->h_addr[0], (unsigned char)hp->h_addr[1],   
   > (unsigned char)hp->h_addr[2], (unsigned char)hp->h_addr[3]);   
   > memcpy((char *)&addr.sin_addr, *hp->h_addr_list, hp->h_length);   
   >   
   > diag = connect(cp->sd, (struct sockaddr *)&addr, sizeof(addr));   
   > if (diag == -1) {   
   > fprintf(stderr, "%s: Unable to establish connection: %s\n",   
   > myname, strerror(errno));   
   > close(cp->sd);   
   > return NULL;   
   > }   
   >   
   > cp->reader = fdopen(cp->sd, "rb");   
   > if (cp->reader == NULL){   
   > fprintf(stderr, "%s: Unable to reopen file: %s\n",   
   > myname, strerror(errno));   
   > close(cp->sd);   
   > return NULL;   
   > }   
   >   
   > cp->writer = fdopen(cp->sd, "wb");   
   > if (cp->writer == NULL){   
   > fprintf(stderr, "%s: Unable to reopen file: %s\n",   
   > myname, strerror(errno));   
   > close(cp->sd);   
   > return NULL;   
   > }   
   > setvbuf(cp->writer, (char *)NULL, _IOLBF, 0);   
      
      
   Shouldn't there exist a function such as fopen4 so that   
   you can do:   
      
   fopen4("COM1", "rb", &file_reader, "PRT", "w", &file_writer);   
      
   or:   
      
   fopen3("eternal-september:119", "r+b", &file_reader, &file_writer);   
      
   and in both cases, you may get NULL for the second file,   
   which means that the first file needs to be treated as a   
   "r+b" meaning you need to do your own fseek when   
   switching between read and write. The reason for this is   
   to make it easy to add these new functions even if the   
   existing OS only has the ability to operate on a single   
   stream.   
      
   Any thoughts?   
      
   BFN. 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