Don't you love non-deterministic behaviour? Windows likes to do that some times.

Utter bollocks! I expected better of you.

Prove that statement...or withdraw it!

I'm sorry if it offends you, but that honestly was my experience of Windows back when I used it. For example at one point I was using Win32::OLE to drive IE to load a website then print it to a postscript file. (That was then passed through ps2pdf to get a PDF version of the web page.) I was using the option to tell IE to do the print but not pop up an alert. It would work about, say, 99.9% of the time. But one time in a thousand the alert did come up.

I got around it by making nothing else dependent on that job finishing in a timely manner, emailing someone if the alert came up, then having someone manually check that alert every week or two. Oh, and I pushed the person who developed the web page to make a standards compliant version so that we could just use html2pdf and get rid of the Windows dependency. (That happened about 6 months later, and I was very glad when it happened.)

According to Microsoft, every layer from Win32::OLE on was part of and integrated with Windows. Including IE. So when I say that this was non-deterministic behaviour within Windows, I am using Microsoft's definition of Windows. I do not know why it happened. It "smells like" a race condition but I cannot prove that.

Admittedly this was some years ago. As you may know, I avoid dealing with Windows whenever I can. The problems may have all gone away, and I wouldn't know.

However I doubt it. Every so often I hear stories that confirm my low opinions. For instance with the initial release of Vista I heard complaints from people testing it that they couldn't get the same result twice from an install. More specifically, they could script an install of the whole OS and applications. Start with 2 factory machines that were supposedly identical. Do identical installs. And they would wind up with 2 machines that would misbehave in different ways. Of course this was before Vista was in wide release and I am sure it has improved since, but still a non-deterministic install process does not inspire confidence.

If I was to guess a cause for these problems, I would say that it is a combination of heavy multi-threading and a dysfunctional development process. If you want to know about the latter, you could do worse than to occasionally read the discussions from insiders at http://minimsft.blogspot.com/. I know we disagree on multi-threading, but read through The Problem with Threads and tell me whether you can honestly disagree with the technical content of that paper. (I know you will disagree with the tone, so please identify technical content you disagree with.)

A second cause of problems is that behaviour may be deterministic, but is affected by things outside of our knowledge. DLL hell comes to mind as a common cause, but it is far from being the only one. For instance many home users have no idea when their computer is captured and made part of a bot net. How many of us don't know someone whose computer mysteriously got corrupted and crashed? How often is it because of computer viruses and worms? Even if the behaviour is deterministic, from the operator's point of view, it isn't. If you're like my nanny your computer starts off fine, gets slow, then at some point won't turn on. For no apparent reason.

And before you say it, yes I know that other operating systems like Linux use multi-threading. However by and large they use it less than Windows does. YAnd their internal development processes seem to be in better shape. Yes, they have security problems. But those are less exploited than Windows is. The result that I haven't experienced a similar amount of pain from non-deterministic behaviour on Linux that I remember from Windows.

Okay. Let's tackle these one at a time:

1. Automating IE from Perl.
   • Perl:

     which for the most part operates despite running on win32 rather than with it.

   • doing IPC via Win32::OLE (an early version of given your timeline)

     A module which has probably suffered more bugs in its history than any other module known to man.

   • to drive Internet Explorer.

     A multi-threaded, GUI program designed for human interaction.

   • To load a page from a remote server.

     That you have no control over its performance, loading, specification ...

   • via an ever-changing network of remote bridges and routers.

     All of which are not only not under your control, but are not under any single point of control.

   • using HTTP

     A connectionless, unreliable protocol.

   • to load a page, and then print it.

   And when 1 time in a 1000, a "timing issue" causes a problem, "Windoze" is the cause!

2. Start with 2 factory machines that were supposedly identical. Do identical installs.

   On one big project I was deeply involved in, 700 "identical" HP servers were purchased on a single purchase order. The (EU mandated and approved) purchase order required that all 700 machines be identical specification.

   When automated installs of HPUX started to be rolled out in a 20 server pilot test, 7 of them failed. In subsequent checks on the 700 machines, 62 variations of motherboard were found. 11 different combinations of harddrive/drive controller manufacture were found. That grew to well over 100 different hardware combinations when minor hardware revisions were taken into account. And that rose to well over 300 variations once minor fairmware revisions were acounted for. In the ensuing legal case, it was determined that is was impossible for a manufacturer to provide 700 identical machines.

   The "identical" clauses were dropped from the contracts for the 40,000 NT workstations, because no manufacturer would sign them.

   Even badly seated memory chips or adapter cards can cause install time hardware checks to produce different results. And all OSs can and do suffer the same way.

3. DLL hell.

   Badly versioned shared library problems are not confined to Windows. Indeed, I first encountered them on IBM VM/SP.

   And as this paper from some guy at Priceton shows, Linux isn't immune to this either. Indeed, he says: "Surprisingly, it is arguable that the shared library problem under Linux is perhaps even worse than the corresponding problems in Microsoft Windows.".

4. Windows machines get hacked--due to "non-determinism".

   The US government is currently trying to extradite Gary McKinnon for hacking "53 US Army computers, 26 US Navy computers, 16 Nasa computers, one US department of Defence computer and one US Air Force computer.". Apparently, "The entire network of more than 300 computers at US Naval Weapons Station Earle, in New Jersey, is said to have been left inoperable after Mr McKinnon deleted files."

   How many of those were running some version of *nix do you think? And if the US Navy/Army/Airforce and NASA aren't capable of securing their machines, what chance has "your nanny"?

   How do you think your nanny would fair trying to resolve the compiler and linker errors when building her own copy of Linux? And how do you think she would fair configuring IPTables?

Yes, windows is far from perfect. And the way it comes pre-installed with half the ports open to the world is downright idiocy. But remember that Dell configure the copies of windows installed on Dell Machines; and Sony on Sony machines; etc. Windows can be bolted down pretty tight, but it takes know-how. The manufacturers should have that know-how. Granted, if MS defaulted it to be bolted down, and forced the manufacturers to have to unbolt things, then they might put more thought into the process, but knee-jerk "blame it on Windows" answers really don't benefit anyone.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."