Thoughts on Windows 7

I’ve now been using Windows 7 Beta on-and-off for a few weeks. In all honesty, I’ve spent most of the small amount of time I’ve had with it playing games, so I can only reflect on my initial impressions. However, there are some observations I have as a (broadly) neutral observer which may be generalised across 64bit editions of Windows, or may be specific to Windows 7.

Microsoft appear to have gone to extreme lengths to keep many aspects of the Windows experience constant and consistent: there are many elements of Windows XP and even Windows Vista which haven’t changed significantly since the launch of Windows NT 4 in August of 1996, over 12 years ago.

(Indeed, take a look at the dialog used to add new TrueType fonts for an example of something which hasn’t changed at all in the preceding decade)

However, for better or worse, with Windows 7 Microsoft seems to finally be exorcising some of these “legacy” features. This approach currently seems to be a little scatter-shot however, and some of the refinements seem to have hidden or removed functionality in the apparent belief that “less functional” is equivalent to “more usable”.

As a very minor but telling example of this, I’ve been completely unable to find where the option to always underline accelerator keys without having to press Alt has been moved to. Searching for this has revealed a telling problem with both Vista and 7: the Control Panel now has so many different components that the only sane way to navigate it is by the (default) summarised overview. Trying to make changes at the level of individual panels is overwhelming due to their number. Whilst there is a search bar on the Control Panel window, searches for “accelerator”, “alt”, and “underline” all turned up a blank. Hopefully the release version of Windows 7, with the promised Windows Server 2008-style leaner default install, will remove the lion’s share of these Control Panel extensions (which, let’s face it, are mostly never going to be touched, even by power users) and leave a more manageable remainder.

I also notice a problem with the more Apple Mac OS X dock-like Windows Task Bar: On the Mac (as with Archimedes systems in times past, but unlike most UNIX applications and all Windows applications which don’t minimise to the System Tray) an application can be running even with no active windows. The application icon can be selected from the dock, and then the persistent menu can be used to open new windows. On previous versions of Windows, activating an application’s icon would always either launch a new instance or open a new window.

However, with the new dock-like Task Bar in Windows 7, this behaviour is no longer consistent: Application icons launch the application when no windows are present and it isn’t running, restores and brings the application window to the front if one window is present, or shows thumbnails of all windows belonging to the application is multiple windows are open.

The problem is this: I have IE8 open, and start downloading two different files. I then close the browser window, leaving only the download windows. I now decide I want to open a new browser window… how do I do this?

Clicking on the IE icon, which would previously have launched a new browser, instead shows thumbnails of the two download windows. Right-clicking on the application icon gives me the option to close the application, but not the option to open a new window (as would happen on OS X). It appears that the only way to get a new window is to close both download windows (quitting IE in the process) and then re-launch it. There must be something I’ve missed here… but if I’ve missed it then I’m sure that many home users would likewise be confused.

(And why does IE still not have some form of integrated download-manager… and at least the ability to resume previously cancelled or partially completed downloads?)

On the subject of IE8, I notice that sites running WordPress are amongst those which have to run in compatibility mode. Switching from IE8 to IE7-compatibility mode caused the tab to crash but, to Microsoft’s credit, this didn’t affect other tabs, even those in the same window. Even with a powerful modern graphics card and the latest drivers installed, the cursor flashes distractingly when over an IE window into the address bar of which text is being entered.

Then there’s the things which are just weird…

I’ve been playing a lot of Fallout 3 recently – and this ran perfectly under Windows XP. Since upgrading to the Windows 7 Beta a new version of Games for Windows LIVE! has been released… and on Windows 7, this doesn’t quite work properly. At first I though that the game was crashing on startup, because the game would launch and display the GfWL! overlay, but then even though the buttons all lit up correctly when moused-over (mouse-overed?), clicking had no effect – it appeared jammed.

It eventually twigged, and I realised that although the roll-on roll-off behaviour seemed correct, wherever I clicked on screen the actual click would be registered by the control (or empty space) approximately 50 pixels above the current mouse position!

I’ve not seen this problem in any other application, and the game itself plays just fine. The previous version of GfWL! I ran on Windows XP had a similar overlay on launch, but this was always 100% accurate.

My final observation is an architectural issue that’s probably the case on all 64bit editions of Windows, of which the Windows 7 Beta is the first I’ve encountered.

A bit of background:
Solaris supports 32- and 64-bit operation, and has a ‘/lib‘ directory for 32bit libraries and a ‘/lib64‘ directory for 64bit libraries. Since binaries are linked against libraries in one directory or the other, the ‘bin‘ directory doesn’t need to be segregated.
IRIX actually supports three different ABIs: ‘/lib‘ directory for (old) 32bit libraries, ‘/lib32‘ for “new” 32bit libraries (which are actually 64bit in terms of precision but 32bit in terms of address space, giving almost all of the advantages of a true 64bit mode without the disadvantage of having to shift twice as much data into and out of the processor in all cases), and ‘/lib64‘ directory for 64bit libraries.
Linux got off to a rocky start initially, with Debian especially trying to maintain pure 32bit and pure 64bit versions – each lacking the ability to execute the code of the other. Luckily, saner heads prevailed and Linux has also adopted a “multilib” ‘/lib32‘/’/lib64‘ scheme similar to the UNIX OS.

… which brings us back to 64bit Windows. Here, whilst libraries are still installed into the (single) ‘%SystemRoot%‘ directory (which these days will most likely be “C:\Windows“), the binaries are split into “Program Files (x86)” and “Program Files“, the latter presumably for 64bit code.

I cannot fathom why this would be thought to be an advantage: are there that many (or, indeed, any) cases where both 32bit and 64bit versions of the same application will be required? Perhaps one explanation is that most browsers plugins are 32bit, and so both 32bit and 64bit editions of IE are required – but wouldn’t it be simpler to allow 32bit plugins to execute within a 64bit browser via an emulation layer?

More to the point, I downloaded the “AMD64” versions of the SUA SDK and Tools – and the installer for this package wanted to install into “Program Files (x86)”. Is this because Windows 7 is unable to correctly locate a 64bit package with a 32bit installer? Does the installer not actually chose the installation directory to suggest itself, and it just so happened that the previous thing I’d installed was 32bit? Crucially, since the tools do seem to work, but this indicate that the differentiation between “Program Files (x86)” and “Program Files” is entirely arbitrary?

If I’m not mistaken then one of the effects of this is that there are now no less than four locations per user where a particular binary could be located: the system “Program Files” or “Program Files (x86)”, or also a per-user sandbox which seems to mirror the contents of these directories when a change is made – which I believe is an aspect of UAC.

Adding even more confusion to this situation is the new (since Windows XP) “ProgramData” directory (the naming of which I object to: given that all other similar names contain spaces, why does this not?) which is supposed to contain system-specific data which would previously have been saved into the “Program Files” directory along with the application binary. With the eventual (very sensible) aim of removing write access to “Program Files” except to installers, this sounds sensible. However, even this mechanism is broken: If one user runs and application for the first time and this writes data to “ProgramData”, then when another user comes along this data will either be read-only or unreadable to the second user (who doesn’t have the credentials of the first). To prevent this, application developers have to ensure that they manually (re)set ACLs on everything written to this directory.

All of this leads me towards the conclusion that, whilst the Windows 7 beta does seem commendably stable (especially for a beta), there are some potentially insurmountable problems lingering just below the surface, and it’s high time that Microsoft truly starts from a blank canvas, and implements compatibility with previous versions of Windows via sandboxes and Virtual Machines… I can’t see how the current web of compromises and special-cases could possibly last much longer.