Quick Take - Windows 7

In August 2010, I bought a Toshiba 18-inch laptop with backlit keyboard so that I can see what I'm typing even in a darkened room. So far, I love this computer because is lightning fast both when booting up and shutting down, to say nothing of day-to-day operations. Furthermore, the 18-inch screen is just gorgeous. Leaving it to return to my other 15-inch laptop is like going from a wide picture window to a tiny port hole.

Fortunately or unfortunately, depending on your point of view, the machine came with the 64-bit version of Microsoft's Windows 7 operating system. In the first few days and weeks of experimenting with the new O/S, I have been struck by three revelations.

The first issue has no operational effect whatsoever but is mildly amusing nevertheless. It involves some apparent internal classification inconsistencies within Microsoft.

By way of background, I have Norton/Symantec anti-virus and firewall products on all of my older computers. However, I have grown tired of Norton's constant barrage of pop-up windows asking me to approve or disapprove a multitude of transactions. Because the price is right—namely, free—I chose to try Microsoft Security Essentials on my new laptop instead of Norton/Symantec.

This is where the fun begins. It appears that the update tab of Microsoft Security Essentials is totally unreliable. It often says "Up to date" even when the Windows Update panel shows a still-pending definition update! Furthermore, Windows Update classifies modifications to Security Essentials merely as "Optional", not "Important" or even "Recommended." At least the Windows Update module shows the needed update even if it does make a mockery of Microsoft's own title Security Essentials.

To further confuse matters, when I look in the System Restore window immediately after updating Security Essentials, it shows a restore point created in association with a "critical update."

In the strange, bizarre world that is Microsoft, three different elements of Windows 7 (Security Essentials, Windows Update, and System Restore) all assign different categories of importance to the same update. It's almost as if the individual elements of Windows 7 were developed by programmers on different planets.

I have encountered similar disparities in the past with regard to Microsoft Office, where the Visual Basic for Applications (VBA) modules in Access and Excel do not always recognize the same basic commands. These collective disparities create the indelible impression that Microsoft must be a stove-piped organization where different software development teams within the organization do not appear to communicate very well with each other.

The second issue is a minor irritant that makes crystal clear how little regard Microsoft holds for end users. Fifteen years have elapsed since the introduction of Windows 95 which first allowed users to select from among multiple cursor schemes and sound schemes and to even create their own such schemes. That is all well and good. During that time, Microsoft has "progressed" through Windows 98, Windows ME, Windows XP, Windows Vista, and now Windows 7. (I am a home user, so I will deliberately ignore the business-oriented Windows NT and Windows 2000.) However, in those fifteen years and five subsequent major software releases, Microsoft still has not implemented any provision for users to export those settings!

In Windows 7, there are 15 different cursors for users to select within a scheme; for sound schemes, there are 57 events for which to select sounds (30 in Windows, 11 in Windows Explorer, 6 in speech recognition, and 10 in Web Time). After all these years, users must still wrestle with drill-down menus to painstakingly hunt-and-peck for the desired cursor images and sound clips one by one. As an alternative, users may (and I did) scrounge through the registry and manually export relevant registry keys to create a .reg file which can then be executed on another machine. However, that process is just as agonizing as the manual entries.

It is past time for Microsoft to implement a convenient way for users to export these and other setting so that those settings can be easily transferred to and installed on new machines. It is sheer folly to have to re-invent the wheel every time users purchase a new computer.

The third issue is far more important operationally: that of backward compatibility. By that I mean trying to get all of my favorite 32-bit software packages to work in the new 64-bit environment. I have found at least four factors that influence how software will work.

1. Is the software written for 64-bit or 32-bit environment? And even when I can find a 64-bit version of my favorite software to replace my original 32-bit version, the 64-bit version still does not always work, possibly because of the next two issues:
   
2. Where is the best place to install software? By default, Windows 7 wants to install 64-bit programs in the folder "C:\Program Files" and 32-bit software in a separate "C:\Program Files (x86)" folder. Of course, all of my favorites were installed in yet another folder of my own designation so that I could more easily copy them to a new computer. Now I have to try each alternative with each program to determine the best location out of the three.
   
3. How best to launch a program? I have two file managers called 2xExplorer and FreeCommander which I refuse to abandon because they have two side-by-side panes that make file management, especially synchronization and backup, an absolute breeze. They are both 32-bit programs, and I am finding that opening a 64-bit program within a 32-bit file manager can sometimes produce quite different results than opening that same program using the 64-bit version of Windows Explorer. Similar problems arise with the converse: opening a 32-bit program in 64-bit Windows Explorer in lieu of my 32-bit file managers.
   
4. Are you running the program as administrator? Be aware that in Windows 7, even if you log on to an administrator account, you do not automatically inherit administrative privileges whenever you launch an executable! To insure that you are running a program as administrator, you might need to right-click on the executable file and select "Run as administrator" from the context menu. This applies not only to applications but also to system files like the command "cmd.exe" that launches the command console.
   
   As an example, I frequently use a marvelous utility by a programmer named Nir Sofer called Registry Scanner, or RegScanner for short. I especially like this program because it provides users the ability to search with a very powerful feature called regular expressions. RegScanner will list all the registry keys that match the search criteria. Users may then double-click on any of the elements displayed. At that time, in a normal 32-bit environment, the Windows registry editor will open for users to edit or even delete the selected registry key. In Windows 7, however, this last feature will work properly if and only if the user has launched RegScanner with the "Run as administrator" menu.
   

In short, experimenting with all of these different combinations and permutations for all of my favorite software is driving me nuts. I now have a greater appreciation for the reasons why businesses that are dependent on legacy software have been slow to abandon old reliable Windows XP. It is simply another manifestation of the old adage "If it ain't broke, don't fix it!"