Cute Canines - Eyes That Engage You

My mother adored cats, and I was brought up with felines of all fur colors, temperaments ranging from cuddly to haughty, taking control as they do all over the house. But my wife hates cats, so it’s been dogs during my married life.

I’ve gotten to really like dogs, and I’m in good company. For example, British prime minister Winston Churchill in the movie The Gathering Storm is pictured one day sitting in the farm section of his country property pondering the animals around him. He comments to an approaching visitor:

“You know, a cat looks down upon a man, and a dog looks up to a man, but a pig will look a man in the eye and see his equal.”

I don’t know about pigs, the closest I’ve ever been to one is while eating ham or bacon. Can’t say that I’ve eaten cat or dog (knowingly at least, but then again I have been to parts of Asia).

The dogs that we’ve had have always been cute and devoted. What is it about dogs that makes them into “man’s best friend” as is generally accepted?

Of course, there’s the services they faithfully carry out for us: watchdogs, seeing-eye dogs, wartime duty, lifesaving, farm dogs effortlessly shepherding sheep, and much. much more.

But it was an episode of the outstanding Catalyst science program Australian Broadcasting Corporation (ABC) that put forward another fascinating insight. Catalyst features stories about dogs every now and again.

For example, there’s this story about dogs’ eyes:

It was thought, that like humans, all dogs have the same eye structure and see the world the same way. But Australian researchers have discovered that dogs had a completely different retina. Amazingly, it means different dogs see the world completely differently.

All very interesting, but it doesn’t answer my question of why, of all domestic animals, dogs seem so cute and appealing (compared with cats, especially).

It seems that there could be a good scientific reason for this. There’s now a plausible theory that it all has to do with dogs’ eyebrows.

Watch the video, and read the transcript.

Are you convinced?

Sometimes I wonder if Microsoft developers really think

I’ve just been  was using the Windows 8 registry editor (regedit.exe) in an attempt to remove the remnants of an application that wouldn’t uninstall cleanly.

Even with my shiny new 8-core processor, twin fast Intel SSDs in RAID configuration plus 32 GB of RAM (rarely is even a quarter of this RAM used), there were periods of up to a minute when the registry editor was scanning for a search string.

During this boring period it simply displayed the following bland, deadly boring [Windows 8 flat, colorless, unappealing] dialog box:

I wonder why on earth some of Microsoft’s developers seem so short-sighted and not to think about the user’s experience. . . . Searching the registry for what, fellas?

In this case, if it was me writing the registry editor then the above dialog would for sure have looked something like this quick mock-up:

It ain’t rocket science!

Updating desktop Java sure can be confusing at times!

Ho hum, more security weakness issues have just been discovered in the desktop Java Runtime Environment (JRE).

See for example Yet another Reflection API flaw affecting Oracle's Java SE …

“The new flaw was verified to affect all versions of Java SE 7 (including the recently released 1.7.0_21-b11). It can be used to achieve a complete Java security sandbox bypass on a target system. Successful exploitation in a web browser scenario requires proper user interaction (a user needs to accept the risk of executing a potentially malicious Java application when a security warning window is displayed).

What's interesting is that the new issue is present not only in JRE Plugin / JDK software, but also the recently announced Server JRE as well.”

Wow, a chink in the armor of Java servers. That should raise a few eyebrows!

Back to desktop Java, however. I’ve been assiduously trying to keep my desktop JRE up to date, and it’s annoying that you have to go to the trouble of navigating to the Control Panel of Windows and then and click on Java (when Java for one of several reasons has not automatically presented the Update dialog in a timely manner).

Actually, it’s more than just annoying: I’d call it a significant shortcoming in the Java security maintenance regime, enabling Java updates to fall way behind if you’re not careful. I reckon that Oracle should improve the ‘reliable timeliness” of this entire process.

Well now, a month or two ago I was puzzled by not finding the Update tab to be present in the Java Control Panel, which I expected to look like the following:

 

A few months I lost some valuable time hunting around to find why this tab does not always appear. Take a look at What is Java Auto Update? How do I change notify settings? Notice that you have to read this page very carefully and about half way down the page you come across the clincher:

Why is the Update tab missing from the Java Control Panel?

Java Auto Update is currently not available for 64-bit versions of Java. 64-bit versions of Java do not include the Update tab in the Java Control Panel.

This is rather slack behavior by Oracle.

It seems that when I got my new desktop system (in late 2012) I slipped up and indeed did have the 64-bit version installed when, like the vast bulk of users, I only needed the 32-bit version. So I dutifully hunted for, downloaded and installed the latest 32-bit JRE version and left it at that.

Last week, after reading about the latest pile of Java exploits, I decided that it was time to update Java again. However I kept getting the following dialog box:

Why no Update tab? I pondered this for a while and after checking  Programs and Features realized that, as noted in bold font on the above image, I still had 64-bit JRE installed (as well as the 32-bit JRE).

After uninstalling the 64-bit JRE the Update tab re-appeared, meaning that Oracle needs to update that statement at What is Java Auto Update? How do I change notify settings? to mention that the mere presence of the 64-bit JRE suppresses the Update tab even if you do have the 32-bit JRE installed.

Trivial? . . . Possibly, but I’d say still worth being described so that other people might save some time and frustration.

My premise: Australia’s NBN shouldn’t mangle the English language

I’m totally enjoying being a pedantic old grump. It’s one of the privileges of getting on in years, one of the joys of dotage.

At out home we’ve been really enjoying having the Optus Cable service for more than a decade now, and for the past year or two their highest offering of 100 Mbps download speeds (as well as a 1 terabyte download quota). I measure the cable speeds every day, and even though HFC is a shared service my tests show that it only drops as low as 30-40 Mbps on weekends and other similar busy times.

So it performs as promised, good work Optus. However I’d prefer it if they offered upload speeds higher than the nominal 2 Mbps (never better than about 1.5 Mbps in practice). The DOCSIS 3.0 standard does support faster speeds, though our National Broadband Network (NBN) being rolled out nation wide I don’t reckon that Optus will ever offer such higher HFC speeds.

So to get even better speeds I’m very much looking forward to the NBN. Unfortunately it’s a huge project expected to take the best part of a decade to roll out, and it was greatly hampered during the first year or two by the “moving target” syndrome (unexpected changes in regulations about the number of Points of Presence, drawn-out negotiations with Telstra, and so on).

I like just about everything that the NBNCo has done so far (and sincerely hope that the 2013 Australian federal election coming in mid-September don’t’ see a change of government and a much inferior NBN result from the new government’s limited vision).

However THERE’’S ONE THING THAT THE NBN DOES ALL THE TIME THAT I DON’T APPRECIATE AT ALL and it’s my pet hate. Their chief spokesperson,  CEO Mike Quigley, uses the term “premise” far too much when he should actually be referring to “premises” – and irritatingly keeps on doing so!

Unfortunately it seems to be spreading throughout NBNCo like an infectious disease (perhaps they’re afraid to correct the boss).

Here’s the latest example, from several days ago, A Report to the Australian Parliamentary Joint Committee on the NBN.

Just one example, a chart showing an estimated price on each “premise” passed. Dollars per “premise” – how slack:

The Australian federal opposition party hasn’t yet picked up on this litany of misused terminology, they would surely use it as another way to criticize NBNCo if they did, wouldn’t they?

How to detect and disable faulty context menu items (shell extensions) in Windows

Many software applications  that execute in Windows 8 (and earlier Windows versions) come with so-called Windows shell extensions.

These are intended to provide extra application functionality and convenience and they usually do a good job, but like any other software they can go wrong and cause complete or partial application failure -- with considerable bother and even havoc in some cases.

This is a longish blog post, necessitated by the complexity of the way that shell extensions work. They are so tightly interwoven into the parent applications that it can be very difficult to identify, isolate and resolve problems with them.

Hence I’ve gone to the trouble to explain it carefully and in some detail.  I hope it will save you wasted time and ease your frustration if you happen to become a victim!

As the name extension implies, these code elements provide extra functionality to File Explorer (you’ll know it as Windows Explorer in earlier versions of Windows) and other parts of Windows.
As MSDN puts it: “The Windows UI provides users with access to a wide variety of objects necessary for running applications and managing the operating system. The most numerous and familiar of these objects are the folders and files that reside on computer disk drives. There are also a number of virtual objects that allow the user to perform tasks such as sending files to remote printers or accessing the Recycle Bin.”

Shell extension handlers are developed by Microsoft as part of Windows itself, but also by many third-party developers ranging from  big software corporations right down to solo developers. (There’s a vast number of the latter in the Windows community, many of whom provide  retail or freeware products of very high quality).

The type of extension handler that I’m focusing on in this post is  Shortcut menu handlers which these days are more commonly referred to as Context menu handlers.

A context menu -- or shortcut menu -- appears when you right click on an object in File Explorer or other contexts such as dialog boxes. For example, in File Explorer to edit the hosts file I might do the following (with the pointer showing where I performed the right click mouse operation):



Context menus are extremely useful, and it’s not long after installing Windows and your favorite third-party software products that there will be quite an assortment of context menu handlers present in your Windows system, all waiting to do your bidding. A typical example:



All right, all right, everybody knows that. Let’s move on to the real point of this blog post.
Last October (2012) I took delivery of what might well be my last ever Windows desktop system. For my prime development system I switched from a quite adequate 4-core machine running Windows 7 64-bit (with a healthy 8 GB of RAM and several terabytes of SSDs plus more terabytes of spinning disks) to an even zippier 8-core machine (with 32 GB of RAM, twin faster SSDs in RAID mode plus even more terabytes of spinning disks), also running 64-bit Windows 7 Ultimate.

This was a few weeks prior to the release of Windows 8 Pro. Once it was released, I tested Windows 8 Pro extensively in a virtual machine environment -- especially getting back some favorite Windows features that Microsoft removed such as the Start Button (via Classic Shell, which I had long been using on Windows 7) and desktop gadgets (via a hack, the 8GadgetPack). I mention this here only because Windows 8 Pro was my final destination.

All went well for a month or two, and then I started having unusual problems with Windows Explorer on the new Windows 7 machine (but not on the old one).

I happen to be an extremely heavy user of context menus, and sometimes in Windows Explorer -- but not every time -- when I invoked a context menu (similar to the example above) there would be a pause lasting a few seconds followed by the following error dialog (1):


(Click on the various images to view enlargements)

Upon clicking the Cancel button, the following dialog (2) appears:


THE QUESTION:
What could be causing such errors? A little research at the Microsoft support website plus other Windows specialist sites indicated that this sort of thing is likely to be caused by a faulty Windows shell context menu handler.

The question that I was faced with – exactly as you will be in similar circumstances -- is which of many installed software products (ranging from complex suites to tiny single-purpose utilities) have context menu handlers? And then, of course, how do you determine which specific piece of software is causing the current fault?

A SOLUTION:
The universal answer to this seems to be to go to Nir Sofer’s excellent freeware product site. For today’s exercise, download and install the ShellExView utility which enables you to display details of all the shell extensions installed on your computer, and to easily disable or enable each individual shell extension.

TIP - While at the site, you might consider downloading Nir’s entire suite of utilities in a neat package called NirLauncher, a package of more than 150 portable freeware utilities for Windows. The NirLauncher package includes a “variety of tools that you may need for your daily computer use, including utilities to recover lost passwords, to monitor your network, to view and extract cookies, cache, and other information stored by your Web browser, to search files in your system, and more.”

THE BASIC PRINCIPLE:
Identifying and adopting a systematic, consistent debugging approach for the more esoteric parts of Windows can be very difficult.

In this case, by disabling shell extensions one at a time, you should be able to determine whether or not it’s the one causing the problem. But this is easier said than done.

Firstly, you’ll find that your system has dozens and dozens of shell extensions installed. Therefore disabling, testing, then [if not faulty] re-enabling them one at a time is a slow and elaborate process.
Secondly, it’s not always easy to recognize and reproduce the conditions that cause the error. For example, while this context menu error was repeatedly occurring on my new Windows 7 machine, it never did arise on the old Windows 7 system. Despite my best attempts to keep the apps on the two systems in synchronization, apparently the new system had some differently installed and/or configured applications.

It happened that this problem was not at the top of my priorities as the end 2012 approached, so I let it slip as summer vacation time arrived here Down Under.

In no time it was January 2013, and I was planning to upgrade from Windows 7 to Windows 8 Pro before the end of January (being a miser, I wanted to do this before the expiry of Microsoft’s generous $14.99 upgrade price offer). The in-place upgrade to Windows 8 went surprisingly smoothly. I only had to reinstall a couple of products to make them work properly again, and  most products worked without a hitch. (I only had to chase down a single device driver update, for an external hard disk docking station  that had stopped running at USB 3.0 speeds, and to reinstall a couple of programs after which they worked fine.)

So now I had Windows 8 Pro running pretty well (using my four monitors in non-touchscreen mode, operating 99 percent like Windows 7 did prior to the upgrade, is exactly how I wanted). I get all the benefits of the many under-the-cover enhancements in Windows 8 while happily avoiding the “Modern UI” (a.k.a. “Metro”) like the plague. (It has no relevance  at all for the way I work.  Whenever I purchase a Windows 8 Pro tablet then, and only then, will I be content to make use of this new tiled interface. But that’s another story.)

But guess what? Whenever I right-click on a folder in the left navigator column of File Explorer, I discover that Explorer always freezes for a few seconds and then closes unceremoniously, without displaying the indicative error dialog that I mentioned above (the earlier  screenshot “Windows Explorer has stopped working”) . . . No  error message at all, zilch, nada – I really appreciate that, Microsoft!

Luckily, if you call it that, I had been experiencing the Explorer freeze-ups with Windows 7. So I surmised -- quite rightly as it transpired -- that this was likely to be that same context menu bug. I should point out here that without the prior experience under Windows 7 I would have been totally I the dark, without any clue about what was happening under Windows 8 and why. For some reason the Microsoft developers worsened the situation by neglecting context menu error trapping code when developing Windows 8 File Explorer.

THE RECOMMENDED METHOD TO USE SHELLEXVIEW:
So, how should you go about using ShellExView to resolve your difficulties? While some other people have discussed the use of ShellExView, generally they’ve omitted usage details (see this case).
When I ran ShellExView on my Windows 8 system I got the following listing. Note that it’s best to sort the entries by vendor name (Company), and I’ve highlighted the Microsoft section in yellow. This is the start of the list (T represents “Top”):



After scrolling down a long way in ShellExView, here are the last few Microsoft entries and the remainder of the non-Microsoft entries (B represents “Bottom”):



It’s a reasonable assumption that it is highly unlikely that the faulty shell extension will be contributed by Microsoft, so let’s ignore the central yellow section of the list.

Adopt a binary search type of approach. Firstly, select all of the entries bottom entries (B) and disable them via the context menu of ShellExView (click “Disable Selected Items” or press the F7 key).
Now focus on the section of the list (T). Disable each of them one at a time, and see if the fault that you’re testing remains or not (in my case, see if Windows File Explorer crashes silently).

As mentioned earlier, this sort of testing can be a laborious process. So if the top section (T) contains too many entries, consider using the binary search approach on it by disabling half of these and checking the other half one at a time.

If none of the top entries seem to be causing the problem, re-enable them and move down to the bottom section (B) of ShellExView, where you carry out the same binary search approach:



It was here that I discovered that when I disabled the Spybot-S&D Explorer Integration the problem went away. Relief at last, like as if I’d stopped hitting myself on the head with a hammer!
The final task was, naturally, to double-check that this is the only disabled shell extension and that all the others were enabled.

So there you are,  job done: a methodology for you to follow when you’re faced with this sort of problem. I hope that it’s one you can use effectively, and avoid losing as many hours as I did when solving this issue.

And of course, some faulty shell extension code that Safer-Networking Ltd has to fix in Spybot - Search & Destroy.

UPDATE (25 April 2013):
Their support team just advised me that this is a known problem with Search & Destroy version 2, here is their forum post about it:

You do not need to uninstall Spybot 2, you can simply disable the feature that is causing the issue. Please run the Start Center, switch to advanced mode and start Settings.
Now open the tab "System Integration“. Here you can uninstall "Windows Explorer integration“. Click "Apply“ and "OK“ afterwards. Settings can also be launched via SDTray (the small Spybot 2 icon beside your systems clock in the taskbar).

Making use of ShellExView was the only way that I eventually determined what the cause of the problem was. Because of the nature of this crash I didn’t have a clue that it was a Spybot issue, so didn’t ever even think to check on this particular support forum.


UPDATE (05 November 2016):
 My system recently got infected with one of those annoying adware nasties that causes annoying advertising in new web pages that open unexpectedly when you click on a spot in a perfectly normal web page.

I tried several tools that made an effort to remove adware like this, and while they did find various other unwanted PUPs (potentially unwanted programs) none of them found whatever browser extension was displaying those irritating advertising pages.

So I installed Spybot again -- luckily, hadn't needed it for several years -- and it seems to have rooted out the cause of my woes, which was a nasty called Mindspark.

Would you believe it? ... Even after more than three years the above bug in Spybot is still there! Are the people at Safer Networking doing anything these days? Anyway, here's a screenshot of the setting used to uninstall the shell extension causing the problem (and now, three years later, it's happening with Windows 10):