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

[sur-behoffski <sur_behoffski@...>]

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
   knew;

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
   filenames;

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.

   See:

        http://www.jasinskionline.com/WindowsApi/ref/b/beep.html

   and look at lovely documentation in there, such as:

        Platforms

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

        [...]

        Parameters

                dwFreq
                    Windows NT/2000: The frequency, in hertz (Hz), of the tone to play. Windows 95/98: Ignored.
                dwDuration
                    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