The point of failure was that IE did not always pay attention to the flag that was passed saying not to pop up a dialog box. That call is entirely within the machine in question. All of the external networking already successfully happened at previous steps.
Now for all of the bugs in Win32::OLE, I've never heard anything indicating any way that code-paths within it could be non-deterministic. Besides, every call to Win32::OLE successfully went through, and the only the passing of a particular flag got messed up. While I can't prove it, I would be willing to bet large amounts of money that if the problem could have been debugged, we would have found that Perl reliably passed that call to Win32::OLE that reliably passed it into the appropriate underlying C library supplied by Microsoft. After all given that I had a reasonably simple single-threaded program, there is no possible cause to expect any non-determinism within that part of the code.
If that belief is correct, then the flag must have been lost at some point after that. But every layer after that is part of Windows! Yes, including IE, which (as you say) is a multi-threaded GUI program designed for human interaction. (Which is, I suspect, the most likely location for the actual bug.) According to Microsoft, that is part of windows.
So I've seen strong evidence that the problem arises in a piece of software that is (according to Microsoft) part of windows. How then am I wrong to blame windows for the problem?
Take, for instance, the case you bring up of Gary McKinnon. I can't find any records of what mix of machines he hacked into. But reading through things like this interview it looks like what he did was have a Perl script search for windows machines that had the default blank password for Administrator, and then he logged in. So it seems quite possible that none of the machines he accessed was any version of *nix. And if they were, then certainly the majority of them were not.
Now on to the default install. You are putting far too much fault on the manufacturers. While it is true that Dell actually configures the copies of windows on their machine, they are forced by contract to configure it within very tight guidelines provided by Microsoft. Microsoft took control of that after they got upset about pre-installs of Netscape on Windows 95 machines, and to the best of my knowledge have never given it up. Therefore no matter how competent they are, Microsoft makes them screw up.
Let me double-check that. (Searches.) Hmm. http://msdn.microsoft.com/en-us/isv/bb190477.aspx includes the sentence, OEMs cannot change any default settings in Windows, except as specifically described in Microsoft documentation or other contractual agreements. That doesn't exactly give the OEMs a lot of wriggle-room, does it? OK, that is specific to XP and to Windows Server 2003. But I think that it would take something big to make Microsoft change that policy. And I haven't heard of anything that could qualify.
So unless you can come up with something more recent, it looks to me like all of the problems with the default install of Windows are entirely Microsoft's fault. No matter how much the OEMs might wish things were different, they are prevented by contract with Microsoft from doing anything more serious for security than installing a third party anti-virus product.
In reply to Re^9: Time::HiRes sleep does not always work
by tilly
in thread Time::HiRes sleep does not always work
by tone
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |