Re: os.clock() [...] Windows and non-backwards-compatibility.

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: os.clock() [...] Windows and non-backwards-compatibility.

On 2019-11-08 23:57, Rob Kendrick wrote:
 >> [...]
 > Does it give the rationale?  I have always assumed this is a backwards
 > compatibility issue (which Microsoft take very seriously): under DOS the
 > the wall clock time a program had been running was identical to its use
 > of the CPU, as it was a single-tasking environment.

Microsoft takes backwards compatibility seriously?  Don't make me laugh.

0. Meme floating around the blogosphere, that I recall hearing at the time
    when it was current:

         "Dos ain't done until Lotus won't run!"

    However, I cannot find a definitive source for this quote... I certainly
    can personally attest that the quote/principle was considered funny
    (in a sad and/or frustrated way) and relevant amongst MS programmers I

1. A talented friend/programmer, who used Borland tools, complained to me
    that a key program that he was selling crashed when a new version of
    Windows came out.  His comment was that the Borland executable
    referenced a very-specific function name early on during program
    initialisation, that triggered dynamic-loading of Borland-specific
    libraries, which set up the environment for the program to run
    correctly... and when the new version of Windows came out,
          *that exact same specific function name*
    was present in an already-loaded Windows DLL, thereby poisoning that
    step of the Borland runtime, and leading to illegal function calls.
    Result:  MS programs continued to run; Borland programs crashed;

2. I myself kept hitting my head against a brick wall, trying to get
    an "Open File" dialog box function, similar to the dialog boxes that
    I saw MS products using... but I could never get it to work using
    using the API calls available.  It was only much later, when I heard
    about Microsoft losing the "Undocumented APIs" court case, that I
    found out that MS had been stuffing me around, wasting a lot of my
    time, on functions that the court case found did not produce
    workable results.  The exasperation over the MS API problems,
    underlined by the "undocumented APIs" court findings, have been the
    reason why I've switched to GNU/Linux as far and as hard as I
    possibly can;

3. Another example comes from the instant that Microsoft transitioned
    from generally-command-line-driven interfaces, and in particular,
    when they suddenly allowed spaces in filenames, why did they suddenly
    use the name

         "Program Files"


    For crying out loud, it's a filesystem, with a hierarchy set up by
    directories.  Perhaps "Program Files And Directories"?  A cynical
    user could look at the MS environment from a time when a space was
    generally agreed to be a word (including filename) separator, and
    the tools for quoting complex words were more primitive in the
    command shell(s) of the day.  "Program Files" as the start of a full
    filename meant that naive multi-word parsers would see "Program" as
    one word, and "Files/whatever/etcetera" (fill in some real data for
    "whatever/etcetera", as desired).  Both parts will not work as
    desired.  My opinion is that, given that it was obviously already a
    filesystem, the name "Program Files" at the base of the path broke
    compatibility for programs that were not expecting spaces in

4. My personal favourite:  The MS-DOS-era C function "Beep()", aimed
    at working with the internal PC speaker, with two parameters:

         BOOL Beep(
           DWORD dwFreq,
           DWORD dwDuration

    Back in the MS-DOS days, some programs could come up with some neat
    sound effects by emitting pairs (or triples?) of very-short-duration
    tones, perhaps sweeping the set from low to high frequencies within
    a second, as a way of signalling the end of an operation.  This
    might involve perhaps 10-15 separate Beep calls.  Some games may also
    have exploited this short-duration capability.  (I'm not certain,
    but I think the duration was in 1/18ths of a second, corresponding to
    hardware timer ticks.)

    I recall fondly when a version of Windows came out (Windows 95?),
    when all of a sudden, "Duration" was ignored, and the sound was played
    for a full second... so these smarty-pants programs, instead of giving
    a neat sound for about (say) 15/18ths of a second, via 15 separate
    Beep() calls, suddenly started a slow sequence of tones that locked up
    the machine for 15 seconds (because Beep was synchronous), before the
    user could continue.


    and look at lovely documentation in there, such as:


             Windows 95: Supported.
             Windows 98: Supported.
             Windows NT: Requires Windows NT 3.1 or later.
             Windows 2000: Supported.
             Windows CE: Not Supported.



                     Windows NT/2000: The frequency, in hertz (Hz), of the tone to play. Windows 95/98: Ignored.
                     Windows NT/2000: The duration, in milliseconds, to play the desired tone. Windows 95/98: Ignored.

     Let's re-read that again, just to make sure: "Backwards Compatibility":
             dwfreq: "Windows 95/98: dwFreq: Ignored"
             dwDuration: "Windows 95/98: dwFreq: Ignored"

     Did the Duration change from:
           - "1/18ths of a second" duration units; to
           - "ignored (force one second)" duration units; to
           - "milliseconds" duration units;
     Yep.  (Both frequency and duration were ignored when the Beep function
     was mutilated to play the "default system sound".)

     Is changing the units of a parameter backwards-compatible, when the
     function name and parameter list doesn't change?


sur-behoffski (Brenton Hoff)
programmer, Grouse Software