From: muta...@gmail.com   
      
   On Friday, June 18, 2021 at 6:21:17 PM UTC+10, muta...@gmail.com wrote:   
      
   > That's hardware changes. I don't care about that moving on.   
   > I care about the software API to interact with the hardware.   
   >   
   > There's no reason to invalidate that, although I will accept   
   > switching to 32-bit registers and then 64-bit registers   
   > instead of 16-bit registers as the register size changes.   
   >   
   > > > If manufacturers insisted that I need to call INT 14H in protected   
   > > > mode, I can live with that. But that's the interface. That's what   
   > > > should exist.   
      
   You know - I would have liked the manufacturers to have   
   produced a 32-bit interface right from the start. So that I   
   am not saddled with 16-bit code for eternity.   
      
   But that's the interface they provided. They said that if I   
   wanted to access the hard disk/serial port, and even to   
   boot, that I must be in 16-bit real mode. No BIOS setting   
   for the MBR to be executed in flat 0-based PM32.   
      
   They are the ones who created very annoying rules. I   
   wrote (albeit slowly) the code to conform to their rules.   
   Now the onus is on them to live by their own rules.   
      
   Some people on Fidonet used to complain that the rules   
   were the comms software needed to support Xmodem.   
   Why not zmodem? If Fidonet wants to mandate zmodem,   
   I don't have a problem with that if we can be sure that   
   there is no-one who wishes to run on a platform that   
   doesn't support zmodem. I wrote a public domain   
   version of zmodem, but until it has been built for a C64   
   and we still have C64 users connecting to Fidonet, xmodem   
   can't be invalidated.   
      
   Once public domain software has been put in the hands   
   of the C64 users and there is no discernable reason as   
   to why they can't use it, that's when I don't mind Fidonet   
   changing the rules. Someone is deliberately using xmodem   
   to disrupt the rest of the organization.   
      
   It is only with Win 10 that ANSI is supported. I intend to make   
   use of that feature (it's already in place), but I know that it   
   won't run on Windows 95. The onus is on me to solve that   
   problem. Those old computers running Win 95 can't be   
   willed out of existence. I might ask them to boot their   
   computer from floppy disk to run a future PDOS/386 that   
   actually supports ANSI (it doesn't currently), so that they   
   can run the ANSI version of micro-emacs (pretty crappy   
   at the moment, but it sort of works). Otherwise I still have   
   a Windows-specific version of micro-emacs that runs on   
   Win95.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)