Text 208, 63 rader
Skriven 2006-05-24 05:39:58 av Bob Ackley (1:2905/3)
    Kommentar till text 204 av andrew clarke (3:633/267.0)
Ärende: squish
==============
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)