From: gtaylor@tnetconsulting.net   
      
   On 6/17/21 3:48 PM, muta...@gmail.com wrote:   
   > I don't understand this comment. Do you mean fork an existing browser   
   > that isn't Chromium-based?   
      
   I would rather you contribute to an existing open source browser.  My   
   pesronal preference would be something other than Chrom.  IMHO there are   
   enough people working on Chrome and other browsers could use some help.   
      
   Especially if your efforts can be contributed to a larger project where   
   your specific desires could be enabled via compile time option.   
      
   > And you don't seem to like this slide and suffering, while at the   
   > same time I shouldn't create a rival to all this?   
      
   Modern web browsers are extremely complex, especially when considering   
   contemporary cryptography and security.  I would prefer to avoid   
   fracturing efforts further.   
      
   > 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.   
      
   How is an operating system the limiting factor of what level of C is   
   supported?  Shouldn't that be the compiler's job?   
      
   > I want to flesh out what is possible with C90.   
      
   You're free to impose your own artificial restrictions.   
      
   > 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.   
      
   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.   
      
   > Moving OpenSSL code to the modem means that my OS is uncomplicated.   
      
   You're committing multiple layering violations for a very questionable idea.   
      
   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.   
      
   > 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?   
      
   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?   
      
   > 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.   
      
   > People are invalidating my software and my knowledge.   
      
   Your more recent ideas have been further and further out there.  Some so   
   far out there that I question what bases them in reality.   
      
   > 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.   
      
   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?   
      
   Could something like that be done?  Probably.  Does anything even   
   remotely like that exist today?  Not that I'm aware of.  --  My   
   ignorance of such does not preclude it from existing.  --  So you are   
   going to need to deal with the software component on both sides of the   
   modem in addition to dealing with the modem.   
      
   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?   
      
   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?   
      
   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.   
      
   The more that you talk about your modem, the more that I think of the   
   3172 / 3174 communications controller from IBM.  The thing is that it   
   did some of the things you mention, but the ironic part is it used   
   external modems.   
      
   > In the meantime I am perfectly happy writing C90 code to control a   
   > modem.   
      
   I don't see anything at all wrong with that.  More power to you and your   
   C90 code.   
      
   > 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.   
      
   I admit that the term "modem" can mean a few different things;   
   historically, serial / PSTN, and more contemporary Ethernet /   
   {DSL,DOCSIS}.  I'm somewhat at a loss for how a PSTN modem could use   
   fiber unless you are going to get into OC... but good luck with that.   
   It definitely won't be cheap in any sense of the word.   
      
   A dial-up PSTN based modem can't really go any faster than about ~30   
   kbps (line rate) because of problems encoding data.  Problems as in you   
   need to sample the line at least twice as fast as the signal you want to   
   send through it to have any hope of getting things to work.  The 33.6 ~   
   56 kbps (serial rate) was data compression applied to the serial stream   
   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?   
      
   Even if you're talking Ethernet / {DSL,DOCSIS}, you are still limited to   
   what the {DSL,DOCSIS} network can carry.   
      
   So ... what is going to be faster about your modem?   
      
   > 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?   
      
   > ...which may not necessarily use "ATDT" to dial,...   
      
   Okay....   
      
   > ...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   
   is it?  If it's now the OS and no longer the modem, why the change?   
      
   > 2. The OS should use INT 14H to get access to the serial port. Yes,   
   > it's slower and crappier than direct hardware access, but it   
   > future-proofs your OS.   
      
   I don't care how the OS accesses the serial port.   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)