Replying to a message of andrew clarke to Bob Ackley:   
      
    BA>> If people would write (only) ANSI standard code this wouldn't be   
    BA>> an issue as any compiler that conforms to ANSI standards (and    
    BA>> AFAIK most do) on any OS would work just fine.   
      
    ac> You make it sound so easy!  The Squish and Maximus code dates back to   
    ac> the early 1990s.  It's a bit unrealistic to expect 15 year old   
    ac> DOS-based code to be ANSI/ISO C standard conformant.  If they were to   
    ac> be rewritten from scratch I suspect this would not be much of a   
    ac> problem, although they would probably be rewritten in C++ or Python   
    ac> now.   
      
   Back in the hoary days of my past, we were *required* to use only ANSI   
   standard code because one basic requirement of the software was that it   
   be portable (at the time there were five different companies making mainframes,   
   none of them were compatible with each other but *all* were ANSI   
   compliant, we had to be able to compile our (COBOL) programs on any   
   of them).   
      
   While each of those five companies were basically ANSI compliant, all had   
   'quirks'   
   added (that we weren't supposed to use) to their systems.   
      
    ac> In any case, there are some things you can't do solely with ANSI/ISO   
    ac> C/C++, eg.   
      
    ac> - findfirst/findnext (eg. Squish processing *.PKT and *.pkt), although   
    ac> you can do this with less-portable POSIX calls   
      
   I haven't looked into it, but I would imagine that it's possible to write such   
   a function in ANSI standard code.  Not necessarily easy, but possible.    
      
    ac> - serial port I/O (OS dependant) (required for Maximus)   
      
    ac> - enhanced text mode display (required for Maximus but not Squish) (OS   
    ac> dependant - requires Curses, OS/2 Vio* or Win32 console subsystem   
    ac> calls)   
      
    ac> - probably a few other things that don't spring to mind   
      
   My bottom line point is that if the users *demanded* ANSI compliance and   
   refused to purchase or lease software that wasn't compliant, the various   
   software outfits would become compliant.  Even if new ANSI standards have   
   to be developed.  And I doubt that it's going to happen.   
      
   Way back in the 70's there were over seventy different firms making Intel   
   based microcomputers.  All of them had their own operating systems and disk   
   formats   
   and most of them were incompatible with the others - and apps had to be written   
   for each disk format and for each OS.  Somewhere around here is a CP/M program   
   that allows my Heath H-89 to read and write in over seventy different (soft   
   sector)   
   disk formats.  Then Gary Kildall brought out CP/M, which standardized the API   
   and   
   made software development and distribution MUCH easier.  Perhaps something   
   similar could be done WRT handling video displays - a standard API but the   
   other   
   end modified for whatever OS its running under?   
      
   And my system runs Maximus (but not Squish).   
      
   --- FleetStreet 1.19+   
    * Origin: Bob's Boneyard, Emerson, Iowa (1:2905/3)