From: muta...@gmail.com   
      
   On Friday, June 18, 2021 at 2:29:53 PM UTC+10, Grant Taylor wrote:   
      
   > > The trouble is that the system I am most interested in is PDOS/386   
   > > which only supports C90. Well, sort of.   
      
   > Either it does, or it does not.   
      
   You can link against my kernel32.a and have functions   
   to create directories and a little bit more.   
      
   It is only if you link only against msvcrt.a that you are   
   restricted to pure C90.   
      
   > How is an operating system the limiting factor of what level of C is   
   > supported? Shouldn't that be the compiler's job?   
      
   The C standards include libraries, and PDPCLIB has   
   straight C90, no extensions.   
      
   Yes, there's nothing preventing you from using GCC   
   language extensions that don't require library changes.   
      
   > > I want to flesh out what is possible with C90.   
      
   > You're free to impose your own artificial restrictions.   
      
   When I have exhausted what is possible with C90,   
   I will consider relaxing those restrictions.   
      
   Up till now, C90 has covered everything I want to do.   
   You just need to rework your problem to fit the   
   paradigm.   
      
   > > What existing C90 browser do you suggest I use instead of creating   
   > > my own? Preferably one that is public domain.   
      
   > I have no idea what falls within your artificial self imposed restriction.   
      
   It is others who created artificial self-imposed restrictions   
   on their code.   
      
   > I'm quite certain that there's source code for Netscape from the '90s   
   > available on various Linux archives. I'm confident that there is source   
   > code for other browsers.   
      
   And I'm pretty sure it's all going to be wall-to-wall copyrighted.   
   And if it isn't, it's going to be non-C90.   
      
   > > Moving OpenSSL code to the modem means that my OS is uncomplicated.   
      
   > You're committing multiple layering violations for a very questionable idea.   
      
   This "layering" seems to be doing more harm than good.   
      
   > Why don't you stick with a simple computer and a standard modem and move   
   > all the intelligence into the serial cable. }:-) Or better yet, the   
   > phone line.   
      
   So long as I am satisfied with the design of the OS, I   
   don't care if there are bees and antelopes chomping   
   away at the copper wire to make it work.   
      
   > > I don't really give a shit about how crappy the modem is. It can do   
   > > forks and TCP/IP and ioctl and TLS etc.   
      
   > How is a modem going to do a fork?   
      
   The modem is going to look identical to a Windows   
   computer with Cygwin installed.   
      
   Because it is going to be a Windows computer with   
   Cygwin installed.   
      
   Cygwin supports fork().   
      
   > Even if the modem could do a fork, how is the directly attached computer   
   > or the computer at the other end going to deal with what was magical forked?   
      
   It was just an internal implementation possibility. I don't mind   
   downloading some pre-existing code and running it under   
   Cygwin.   
      
   I already have a virtual modem, and it is already dependent   
   on Cygwin.   
      
   > > All I want is my modem back. I never agreed to give it up. Or the   
   > > attached BBS software.   
      
   > What do you mean "want is my modem back"? I don't recall anyone taking   
   > your modem from you.   
      
   Telstra even ripped up the copper wire. You have no   
   choice but to use fiber or 3G.   
      
   So long as I have something on the end of INT 14H that   
   replies "OK", I don't care.   
      
   > > If I choose to learn new stuff, I wish to do it at my own pace.   
      
   > Part of learning things that are new to you is understanding why others   
   > think something can or can't be done, or should or shouldn't be done.   
      
   I post here to hear exactly those things. Otherwise I would   
   just go ahead and code the first thing that comes to my mind.   
      
   > E.g. even if your modem can magically fork and change what it's doing,   
   > how are the computers connected to it, one via serial and the other via   
   > phone, going to change what they are doing to be in sync with the   
   > modem's change?   
      
   I had assumed that a "virtual modem" didn't entail a physical   
   phone line.   
      
   > Similarly, your idea of moving OpenSSL into the modem, how are you going   
   > to communicate all of the parameters that are used to establish SSL /   
   > TLS connections to the modem? How are you going to provide the trusted   
   > root certificate store? Modem's don't have any storage to speak of   
   > (NVRAM is miniscule) and /etc/ssl on my modern system is about half a   
   > MB. How do you manage that certificate store on the modem?   
      
   I have no knowledge of certificates, but I assume Windows   
   has a way of doing that, and the virtual modem will be   
   running under Windows or Linux or BSD or MacOS.   
      
   > How does the OpenSSL on the modem initiate a TCP/IP connection when   
   > modem's don't speak TCP/IP. Or are you throwing that in too?   
      
   Yes, I'm throwing that in too.   
      
   One day someone may produce a physical modem that   
   meets the above criteria and that is the size of a matchbox,   
   but until then, it will look exactly the size of a PC.   
      
   > These are some of your more recent ... ideas. Can they be done?   
   > Theoretically, I suppose. People like to say that with enough time and   
   > money anything is possible. But how practical is it that something can   
   > be done or that you as a single person can do it.   
      
   I kludge things so that I can prove the concept in my   
   lifetime, and developing a matchbox-sized equivalent   
   is someone else's job.   
      
   > > I do expect the modem to be faster and cheaper, and making use of   
   > > fiber instead of copper.   
      
   > See, that's one of those things that seems ... out there. You have   
   > stated that the modem is virtual. Now you are talking as if it is physical.   
      
   Virtual anything still needs something physical, like RAM.   
   I need bluetooth or fiber or something in order to do any   
   sort of communication.   
      
   > to shrink it down to the ~30 kbps (line rate). So ... how are you going   
   > to make a dial up modem faster than physics can allow?   
      
   Believe it or not, even fiber can respond to "ATDE" with "CONNECT".   
   I'm not going to personally inspect the other end of INT 14H and   
   insist that it is made of copper, not fiber.   
      
   > So ... what is going to be faster about your modem?   
      
   100 Mbps.   
      
   > > But all this should be transparent. At least if I follow the rules,   
   > > and even if the rules are only apparent in hindsight. Namely:   
   > >   
   > > 1. Apps should fopen COM1 or preferably a user-defined string to get   
   > > access to the modem,...   
   >   
   > What might the user defined string be? Or more importantly, what might   
   > it represent? What significance does what it represents have?   
      
   ATDAnntp://eternal-september.org   
      
   (I will need that "A" if dialing from my EBCDIC system)   
      
   > > ...so let the OS take care of that.   
   >   
   > Wait a minute. You have been saying that you wanted the modem to take   
   > care of this. Now you are wanting the OS to take care of this. Which   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)