The Interface  

An important part of a web browser (or any application for that matter) is the user interface. It’s one of the most immediately noticeable things when you start the beta for the first time. A particularly awkward change is the relocation of the tabs to the right of the address bar. This strikes me as a little odd, and I wouldn’t be at all surprised to see a very negative reaction from customers regarding the move. After some thought, it occurs to me that indeed, there is no reason that the address bar needs to consume the entire width of the browser window; however, to make the most of a tabbed browsing experience, the tabs need to have as much space as possible. Squashing them in next to the address bar doesn’t add much to the browsing experience unless you count the thirty odd pixels worth of vertical space saved, but on high resolution screens which dominate the consumer market today, the space saved is tiny and is not worth the detriment to the tabbing interface. You can actually resize the width of address bar, but you don’t want it to be so small that you can barely see the domain name. So the effect on the tabs is still quite strong, especially if you’re a heavy tabs user.  

The search box has been merged with the address bar. This is also awkward at first but I think it’s a change I can get used to. It does this particularly annoying thing where it goes straight to the “top result” in the search, but sometimes it just shows the search page. After a bit of investigating, I found you can turn this off in the search options, but in my opinion its inconsistency and unpredictability makes it a fairly useless feature to begin with.  

You may be noticing a trend, which is that Microsoft is going for a very minimalist approach to IE9′s GUI, cutting it down as much as possible so that it’s the webpage that stands out, not the browser itself. While this can work for some people, it doesn’t for everyone, especially power users; it would be okay if there was room for customization, but there isn’t. I really want to see the option to move those tabs back to their own space below the address bar.  

Despite the tab bar’s unnecessary displacement, tab management has improved. You can now drag a tab out of the window to form its own window, or drag a tab into another window.  

Dragging a tab outside of a window

 A new feature which IE  has desperately needed for many years now is a download manager. It’s such a relief to finally see this implemented. Downloading in previous versions was messy at best; each download would have its own window which couldn’t be paused, and support for large files (anything over a gigabyte or so) was virtually non-existent. Downloads are now managed in a single window and can be paused and resumed. A default download folder can be set to avoid the “Save As…” prompt you’re usually hit with in previous versions. Large files are now supported properly as well. Curiously enough, there is neither a progress bar nor a download speed indicator in the download manager, the latter of which strikes me as one of the fundamental elements of any download manager, so it’s a bit strange for it not to be present.

In a further effort to make the interface less disruptive, Microsoft has moved the notification bar to the bottom of the screen. This actually works too well for me, and I’ve heard similar comments from people in the community. Typically your focus is at the top of the browser to the middle, when content gets down low, people usually scroll up. Several times the notification bar has popped up and I have failed to notice it for some time. It’s great that the overall browsing experience isn’t interrupted, but notifications are important and should be a little more noticeable. This is another area where I think there should be more customization available. Given the option to move the notification bar back to the top of the browser and to set which notifications can appear would be an improvement.

Performance and Standards Compliance

Another thing that’s immediately noticeable when I first opened the beta is that it starts up much faster than previous versions of Internet Explorer. This seems like the first version of IE where performance has been a major design goal. Microsoft has replaced the abhorrently slow JavaScript engine used in previous versions with a completely new engine dubbed “Chakra”. At the time of writing, the IE9 beta scores 95/100 on Acid3 which is a significant improvement on IE8′s score of 20. Hopefully we’ll see that score reach the 100 mark in a future build prior to release. The beta also completely passes the selectors test at CSS3.info. The new engine has full support for HTML5 including the canvas element and various media components such as H.264 video. SVG is also fully supported, including both SVG files and inline SVG elements.

Hardware accelerated rendering makes for a much smoother browsing experience, especially on pages that are rich in content. For instance, since images are held in the GPU’s private memory, re-rendering pages rich in images is remarkably fast. The use of DirectWrite results in much nicer looking text.

There’s still some things that need to be ironed out but overall, the renderer in IE9 is a fantastic improvement on older versions.

Windows 7 Integration

One of the more interesting and unique features of the IE9 beta is how it integrates with Windows 7. You can pin sites to the taskbar by dragging a tab down to an empty space on the bar, much the same way as you would pin a regular windows application. Launching a pinned site starts a customized IE window with custom coloured back and forward buttons and so on. Sites can also have custom JumpList items, icon overlays, and thumbnail buttons, as well as the ability to make the taskbar button flash using a combination of meta tags and JavaScript. This works well with Facebook. Whenever there is a notification, Facebook adds a red asterisk-like overlay on the taskbar icon, which allows you to keep an eye on it using only cursory attention. I’ll probably write up a tutorial on how to use these features in the future but since IE9 is still in beta I think it might be best to wait and see what happens further on in the development cycle.

Some simpler Windows 7 features are also present, such as Aero Snap on tabs that you drag to edge of the screen.

Conclusion

As always, it’s important to note that when we’re dealing with a beta, we’re dealing with an unfinished product so you have to keep in mind that anything can change before release (although my experience with Microsoft tends to be that feature-wise, their betas are almost identical to the final product in most cases). Having said that, overall I’m quite impressed with this release. I think Microsoft can say for the first time in a very long time that they are at least on the same level as their competitors in the web browser market. The new layout engine and renderer and infinitely better than what was available in previous manifestations of IE, both in terms of performance and features. The Windows 7 integration is very nice and makes for some interesting web applications in the future. The main thing I’m bothered with by this release is the overly simplified UI. It works, but it just doesn’t have the necessary power and flexibility that I think a web browser of today should have. I really, really, really want to see at least the option of moving those tabs back down to their own space. I’m eager to see a future build, as this is definately a step in the right direction for Microsoft.

In the early days of Windows, applications would often store their configuration data in text documents called initialization files. Typically, these files would use an extension like .ini, .txt, .cfg, etc. One of the major problems with this particular system was that with the sheer number of applications installed, the .ini files would become scattered across the file system, making them difficult to track. After the release of Windows 95, in an effort to further standardize and manage configuration for applications and Windows, Microsoft encouraged software developers to use the Windows Registry as an alternative to INI files for storing configuration data. In the years that followed, the Windows Registry became the standard repository for application settings.

Today, XML files are gaining popularity with developers as a new medium for storing application configuration data for a variety of reasons. However, the registry remains a very important component of Windows; for software developers and windows power users, the ability to manipulate it is an essential skill.

The Windows Registry is essentially a large hierarchical database. Its structure is not unlike that of the Windows file system. Data is stored in entries called values, which are stored in collections called keys. A key in regards to the registry is in essence, a folder of sorts. Keys usually contain a collection of values and sometimes subkeys, not unlike a folder filled with files and subfolders. This makes keys a little confusing, because typically the word ‘key’ in computing refers to the name part of a value in an associative array. Value in terms of the registry refers to both the name and the value of the entry. This is because in the earliest versions of Windows (3.1 and prior), keys in the registry could not contain multiple name/value pairs; it only contained a single value which was tied to the key itself. In this scenario, the structure of the registry much more resembles an associative array and the term ‘key’ makes perfect sense. The elements of the registry have not been given more appropriate names since.

Keys in the registry are arranged into logical groups called hives. The hives that make up the registry are stored in multiple files in various directories on the system (mainly %SystemRoot%\System32\config). Below is a list of the standard hives and their supporting files, according to Microsoft:

At the root of the registry there are typically five main keys visible in the registry editor, they are as follows:

HKEY_CLASSES_ROOT (HKCR)
HKCR contains data concerning the relationships between applications and other items, such as file type associations. It is essentially a compilation of the classes stored in HKCU and HKLM.

HKEY_CURRENT_USER (HKCU)
HKCU contains configuration data specific to the currently logged in user. The contents of HKCU are just a reflection of the data in HKU relating to the current user profile. As shown in the table above, all of the data in the HKCU hive is stored in a .dat file located in the user’s root folder (typically %SystemDrive%\Documents and Settings\<Username> or %SystemDrive%\Users\<Username> depending on the operating system).

HKEY_LOCAL_MACHINE (HKLM)
HKLM contains settings for all users on the machine, rather than any specific user. As in HKCU, HKLM sorts driver and services information in the SYSTEM key, and configuration for windows and applications in the SOFTWARE key.

HKEY_USERS (HKU)
HKU contains everything in HKCU as well as the same data for every other user on the machine. It also describes the default configuration for new users.

KEY_CURRENT_CONFIG (HKCC)
HKCC contains data relating to the current hardware profile of the machine. Technically, it only contains information describing the difference between the current configuration and the standard configuration, which is stored in the SOFTWARE and SYSTEM keys of HKLM. HKCC is actually just a mirror of the contents in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles\Current.

The Windows Registry cannot be more than 512 levels in depth, and no more than 32 levels can be created at once with a single API call.

Because virtually every Windows setting is stored in the registry, it is the ultimate tool when it comes to system configuration. For more or less the same reason, the registry can also be very dangerous if misused. Incorrect configuration of certain parts of the registry can cause a variety of problems, including rendering the operating system unusable. Centralizing system configuration makes settings more accessible to the operating system. Registry settings can be applied to users en masse via group policy, and the entire registry is relatively simple to back up. Due to the way the registry is stored on the system, storing strongly typed data is possible and parsing data is not necessary as it is with INI files, which results in faster reads. On the other hand, the registry’s binary structure also makes damage much harder to repair.

The easiest way to manipulate the registry is via the Registry Editor, which is a component of Windows. By default, there are no shortcuts to the Registry Editor, so we’re going to have to start it a little differently than most applications.

Open the start menu and click Run. Type regedit and hit enter. We could type the full address to the Registry Editor, but it just so happens that it is stored in the system32 folder, which is where Run looks if an absolute path is not specified. If you’re using Windows Vista or Windows 7, just type regedit in the search box at the bottom of the start menu and hit enter.

At first glance, the Registry Editor looks similar to Explorer. You can navigate through keys using the tree on the left side of the window. Unlike explorer, subkeys won’t be displayed in the list view on the right, so you’ll have to use the tree to move around the registry. The list view shows each value of the current key. As discussed earlier, a value has its own name, type, and data. For the purposes of demonstration, we’re going to edit a value. The change we’re going to make is stopping an application from appearing in the “frequently used programs” list in the start menu (present in Windows XP onwards).

Windows keeps a small list of executables that shouldn’t be included on this list; it keeps this list in the registry of course. The value exists to stop certain system programs and applications that are unlikely to be run more than once from appearing on this list (things like installers and rundll32). Let’s say I want to prevent Windows Media Player from appearing on this list (because I already have it on my Quick Launch bar). This value is located in the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\FileAssociation

The parent keys in the above address basically break down like this:

Settings for the machine (not just this account) >
Settings for software on this machine >
Settings for software manufactured by Microsoft >
Settings for Microsoft Windows >
Settings for the current version of Microsoft Windows >
Settings for explorer (explorer handles the user interface, among other things) >

So use the tree view on the left to navigate to this key. You should see roughly three or four values listed. The one we’re interested in is called AddRemoveApps; it’s a REG_SZ which is essentially a string value (a value that contains data composed of a sequence of characters, usually text of some description).

Double click on AddRemoveApps or you can right click on it and select Modify… from the context menu that appears. You should see a small dialog appear captioned “Edit String”. This is pretty self explanatory; to edit the value data, change the contents of the second text box and click OK. The contents of mine looks like this:

SETUP.EXE;INSTALL.EXE;ISUNINST.EXE;UNWISE.EXE;UNWISE32.EXE;ST5UNST.EXE;RUNDLL32.EXE;MSOOBE.EXE;LNKSTUB.EXE;MSASCUI.EXE

So what we have here is a list of executables separated by semicolons. To add Windows Media Player, jump to the end of the string, add a semicolon, then type the executable name:

SETUP.EXE;INSTALL.EXE;ISUNINST.EXE;UNWISE.EXE;UNWISE32.EXE;ST5UNST.EXE;RUNDLL32.EXE;MSOOBE.EXE;LNKSTUB.EXE;MSASCUI.EXE;WMPLAYER.EXE

You’ll notice I’ve typed wmplayer.exe in upper case; this is just for consistency, it isn’t actually case sensitive. Windows only checks this value when it attempts to add a program to the list, so if Media Player is already on your frequently used programs list, you will have to remove it yourself first (either by clearing the list, or right clicking on it and selecting Remove from This List.).

You can also export entire keys (or the registry itself) into .reg files, which are basically text files with a special syntax which Windows can read. When you open a .reg file, Windows attempts to modify the registry based on the contents of the file. Since this is a potentially dangerous thing to do (especially if you don’t know where the file came from or what its purpose is), Windows will always ask for confirmation before executing a .reg file. If you want to read or edit a .reg file, you can do so with a text editor such as notepad.

Exporting allows you to back up the registry before making changes. In most cases, this isn’t strictly necessary if you’re careful, but it is a good practice to establish. To export a key, simply right click on it and select Export.

Originally published in 2008

On Windows XP and up, it is possible to hide user accounts from both the Welcome Screen and the User Accounts control panel. In this tutorial, I’ll show you how. I’m sure people have various reasons for wanting to do this, so here we go.

The first thing you want to do is head to the Control Panel and create the user you want to hide, if you haven’t done so already. I’m calling mine Secret Account. It’s important to take not of the exact name of the account, including character case, because we’ll need to use it later.

Notice that the account is shown in the User Accounts control panel. This is normal, of course.

If you log out, you’ll notice that the account is also shown on the Welcome Screen. Once again, standard windows behaviour.

In order to tell Windows to hide the account in both the Control Panel and the Welcome Screen, we need to make an edit to the Windows Registry.

To open the registry editor, select Run from the start menu, type regedit and click OK.

Once the Registry Editor opens, browse to the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList

In this key, you need to create a new DWORD value. Give it the exact name of the user account (case sensitive). In my case, I’m calling it Secret Account. The default value for a new DWORD should be 0×00000000 (0), which is the value we want, as it hides the account. If this is not what your DWORD is set to, change it accordingly.

Once you’re done, close the Registry Editor and the effects should be instantaneous. Head back over to the Control Panel and the affected account should not be visable.

Log out to see the Welcome Screen. You’ll notice the account is no longer visible here either.

In order to log on using the hidden account, you’ll need to press Ctr+Alt+Del twice. You will be prompted with the classic NT log on window.

Input your username (case insensitive) and password (case sensitive), and click OK.

You can also use this method to show the Administrator account on XP, which is hidden by default.