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.