[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: os.clock() [...] Windows and non-backwards-compatibility.
- From: sur-behoffski <sur_behoffski@...>
- Date: Sun, 10 Nov 2019 06:18:07 +1030
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
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
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:
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