Since its release, Windows 7 has had a very strong uptake with consumers across the globe (that is, in comparison with other operating systems in the past). This should come as no surprise to anyone, as Windows 7 is pretty awesome.

Windows 7 introduces tons of new features which are pretty cool individually, but together add up to a huge improvement over its predecessors. One of the coolest of these features – or at least the one that had the most media attention – is the new task bar.

There are a lot of new components introduced with the new taskbar, but for the purposes of this article, I’m only going to focus on Jump Lists; further on I plan to talk about progress bars in taskbar buttons, and image overlays on taskbar buttons, but those will be in future posts. These features are particularly handy for 3rd party developers and I’ve noticed a lot of people looking for ways to access them in the .Net environment.

There are two primary approaches to this problem; since both have their merits, I’ll focus on one, then the other.

Since the current version of .Net (at the time I wrote this, version 3.5) has been around well before the release of Windows 7, it’s certainly no surprise that these features are not directly supported by the .Net Framework. However, luckily for us, Microsoft has provided a library for accessing these features in .Net, which is basically a wrapper for part of the new Windows API. You can download the latest version here:

http://code.msdn.microsoft.com/WindowsAPICodePack

Just in case that link breaks in the future, I’ve also uploaded version 1.0.1 of the code pack here:

http://files.nacimota.com/WindowsAPICodePack101.zip

The code pack is actually distributed as source code instead of binaries. While we could include the source in our solution, I find it much simpler and cleaner to build the DLLs then use them as references in our project, so let’s do that.

After extracting everything in the ZIP archive to a folder of your choice, enter the WindowsAPICodePack folder and open WindowsAPICodePack.sln in either Visual C# Express 2008 or Visual Studio 2008 (you can open it in future versions but you will be required to upgrade the solution first).

Once the solution is open, click Build > Build Solution. Binaries for each project in the solution should have been compiled and can now be found in the \bin\Debug subdirectory of each project directory in the code pack.

You can now close the solution and open/create your own project. I’m going to create a .Net 3.5 Windows Forms application in Visual C# Express; I’ve called it Taskbar Fun.

In the Solution Explorer, right click on References and select Add Reference…

Since Visual Studio isn’t yet aware of the libraries we want to reference, we need to select the browse tab and locate them manually. Browse to the directory where you extracted the code pack and select the following binaries from WindowsAPICodePack\Shell\bin\Debug:

Microsoft.WindowsAPICodePack.dll
Microsoft.WindowsAPICodePack.Shell.dll

Then click OK to add references to those binaries.

Next, head over to the code for our default form (by default, it should be called Form1.cs), since this is where we will add our Windows 7 magic. Add the following directives to the top of the file so we can access the namespaces in the libraries without typing them over and over:

using Microsoft.WindowsAPICodePack;
using Microsoft.WindowsAPICodePack.Shell;
using Microsoft.WindowsAPICodePack.Taskbar;

You can also rename the file and class to something more appropriate if it pleases you. I’m just going to call mine MainForm.

Create a JumpList object at the start of the class. We’ll initialize our JumpList in the form’s Shown event, so create that event and the necessary handler now.

namespace TaskbarFun
{
    public partial class MainForm : Form
    {
        private JumpList jumplist;
        public MainForm()
        {
            InitializeComponent();
            this.Shown += new EventHandler(MainForm_Shown);
        }

        void MainForm_Shown(object sender, EventArgs e)
        {
            // stuff goes here
        }
    }
}

Inside our event handler, set the value of the JumpList object to JumpList.CreateJumpList(). This does some basic initialization stuff with our JumpList like associating it with our application. Before we can actually see our jump list, we’re obviously going to have to add some items. Let’s start with a JumpListLink, which is essentially just a windows shortcut. For my JumpListLink, I’m going to create a shortcut to Notepad. The constructor of the JumpListLink class demands a path and a title. Notepad is located in system32 directory; the title is completely arbitrary.

void MainForm_Shown(object sender, EventArgs e)
{
    jumplist = JumpList.CreateJumpList();
    JumpListLink notepadlink = new JumpListLink("C:\\Windows\\system32\\notepad.exe", "Open Notepad");
}

Next, we need to add our JumpListLink object to our JumpList, then update taskbar so that our changes are visible. Items are added to a JumpList using the JumpList.AddUserTasks() method. To update the actual jump list in the tasbar using our JumpList object, call the JumpList .Refresh() method.

void MainForm_Shown(object sender, EventArgs e)
{
    jumplist = JumpList.CreateJumpList();
    JumpListLink notepadlink = new JumpListLink("C:\\Windows\\system32\\notepad.exe", "Open Notepad");
    jumplist.AddUserTasks(notepadlink);
    jumplist.Refresh();
}

If you build your solution now you will see that the jump list works and we have our Open Notepad link. You’ll see the process is listed as vshost.exe instead of whatever your project name is; this is normal, of course.

You can also add separators by creating JumpListSeparator objects and adding them with the same method:

void MainForm_Shown(object sender, EventArgs e)
{
    jumplist = JumpList.CreateJumpList();
    JumpListLink notepadlink = new JumpListLink("C:\\Windows\\system32\\notepad.exe", "Open Notepad");
    JumpListSeparator separator = new JumpListSeparator();
    JumpListLink paintlink = new JumpListLink("C:\\Windows\\system32\\mspaint.exe", "Open Paint");
    jumplist.AddUserTasks(notepadlink, separator, paintlink);
    jumplist.Refresh();
}

I’ll be focusing on other features like progress bars and icon overlays in future posts.

This has resulted in many veteran mappers adopting a viewpoint that is essentially “NEVER USE THE CARVE TOOL”, which is then passed on to new and aspiring source mappers who read those kinds of comments in tutorials and forum posts. Despite this, the carve tool remains a useful technique for quickly creating rectangular holes in a brush and shouldn’t be discarded from your mapping arsenal.

A question I’ve heard from new mappers over the years is, “if the carve tool shouldn’t be used for anything other than rectangular brushes, how do you properly create circular holes in a brush?”

The reason why the carve tool doesn’t work well with cylindrical brushes and so forth is primarily due to the simplicity of the algorithm behind it. When carving, Hammer executes multiple clips on the target brush parallel to each edge of the carve brush.

As you can see, this produces some nasty results, which can cause problems for the compiler as well as just being plain messy. What we’re going to do is follow a more complicated algorithm which, in my opinion, the carve tool should have used in the first place.

Since we’re going to be doing clips ourselves, we are of course, going to use the clipping tool. If you’ve never used the clipping tool before, now is your chance to learn.

The clipping tool is located in the toolbox between the overlay tool and the vertex tool. The way it works is simple. With the clipping tool activated, you can drag a line across a selected brush (or multiple brushes) in any of the three 2D viewports. It is along this line the selected brush will be divided. The clipping tool has three modes; the first two keep one of the divisions while removing the other and the third mode keeps both divisions. You can tell which division will be removed by looking at the outlines of the brush in the current viewport.The part outlined in red will be removed while the part outlined in white will stay. If you only see white outlines then you are using mode three, which keeps both divisions.  To cycle through clipping modes, you can click the clipping tool icon again or hit Shift+X. Make sure you’re using mode 3 before continuing.

The method we’re going to use is a five-step clipping process. Steps 1 and 2 involve dividing the target brush in such a way that our working area becomes as small as possible. Although we’re not actually using the carve tool, we’ll keep our carve brush (the cylinder) around for reference. To begin, select the target brush and activate the clipping tool (make sure you’re using mode 3 so we keep both divisions). In the 2D viewport that shows the end faces of the carve brush, drag a vertical line with the clipping tool straight through the vertex on the far left, like so:

Hit enter to execute the clip. Do the same for the vertex on the far right. Now your target brush is split into three divisions; the middle brush should be the same width as the carve brush. Proceeding to step two, select the middle brush – make sure the two side brushes are not selected – and execute horizontal clip through the top vertex. Do the same for the bottom vertex. You may notice that the result is very similar to what the carve tool would have done if we’d used a rectangular carve brush; the difference is that the centre brush would have been removed, which is why we clipped it manually.

Step 3 is to split the centre brush into sections. With the centre brush selected, execute vertical clips through each or the remaining vertices. You may need to decrease the size of the grid to complete the clips accurately; you can change the grid size by pressing the square bracket keys on the keyboard or using the buttons on the toolbar. Once you’ve clipped the centre brush into vertical slices it’s time for step 4. Clip each slice along the edge of reference brush. Make sure you only have one slice selected at any one time or you may end up clipping where you’re not supposed to.

Step 5 is to remove the inner brushes. This is pretty self explanatory. Last but not least is to tie all the inside brushes to a func_detail entity for the sake of optimization; while this isn’t strictly required, I strongly recommend it.

I have a cold so my voice is a bit off in places. Send plugin feedback to sketchuptools@valvesoftware.com.

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.

Originally published in 2008

In this tutorial, I’ll discuss disabling and configuring User Account Control (UAC) on Windows Vista, along with the pros and cons of doing so.

User Account Control, or UAC as it’s often called, is arguably the most controversial feature of Windows Vista. It’s also probably fair to say that it’s Vista’s most misunderstood feature.

UAC prompts you with a ‘click-ok-to-continue’-like dialog whenever you do certain actions. This is often interpreted as “Are you sure you want to run this program?” or “Are you an administrator?”, which isn’t quite the case. This prompting behaviour can be jarring for users, as it deviates from the behaviour of previous versions of Windows. Being constantly asked to confirm your actions can be frustrating for users new to the Vista platform. Because of this, many users choose to disable the UAC system all together, and it has become a main point of criticism for Vista.

Before I explain how to configure and disable UAC, let’s discuss briefly what it actually does.

In previous versions of Windows (as late as Windows XP), we had two main types of user accounts: Limited Users and Administrators. Limited Users were restricted in what they could do with windows. Most installations, for instance, required authorization from an Administrator. The same was true for various other tasks, such as installing hardware and making system wide changes to the operating system. Administrator accounts, on the other hand, had virtually full access to Windows.

According to Microsoft, most people prefer to use Administrator accounts. This is primarily due to the default account that is created during Windows Setup being an administrator, and also to the fact that users prefer to have full control over their PC. The main security issue with this approach to user policy is that applications are run with the same privileges that the user has. That is, if the user is an administrator, the application runs with administrative privileges. This makes Windows more vulnerable to malicious software than it should be.

Windows Vista takes a different approach to user security policy by implementing the UAC system.

By default in Vista, all programs run with minimal privileges regardless of the account type the user is set to. Without administrative privileges, it is much more difficult for applications to perform potentially harmful operations. However, some applications do have legitimate use for administrative privileges. The prime example would be setup applications, as they require access to areas such as Program Files and the Windows Registry. When an application attempts to do something that requires administrative privileges, it is detected by UAC.

What UAC actually does is tells the user that the application is requesting admin privileges (and thus, higher access to the operating system). The user can then allow or deny administrative access to the application that made the request by answering the UAC prompt. If administrative privileges are granted by the user, the application retains them until it closes.

This system gives users complete control over what applications the operating system exposes itself to, which makes malware a lot less effective.

When Windows Vista was first released in January of 2007, the amount of UAC prompting for regular programs was higher than what would have been tolerable for many people. This is because a lot of Windows software at the time required administrative privileges unecessarily, due primarily to poor programming by the developers. UAC has, perhaps unintentionally, encouraged developers to rewrite their software to work without triggering UAC prompts, which Microsoft argues results in an “improved software ecosystem”. The amount of programs that trigger UAC

prompts on Windows Vista has dropped approximately 78% between August of 2007 and August of 2008, which is compelling evidence to support Microsoft’s claims.

Regardless of UAC’s beneficial features, many people still find the prompting too intrusive, and turn UAC off as a result. This can be done in the User Accounts section of the control panel, but it’s not a very good idea.

Disabling UAC causes other Windows components to behave differently, which can cause problems here and there. Since it’s only the prompting that’s the issue, it would make more sense to leave UAC on, but turn the prompting off. This can be done.

Windows Vista Ultimate and Windows Vista Business users have access to the Local Security Policy editor, also known as secpol. To run secpol, type secpol.msc in the start menu search box and hit enter (you will be prompted by UAC, go figure).

Under Local Policies > Security Options, there are a whole bunch of settings related to UAC. The two we are interested in are…

UAC elevation prompt settings in the windows Security Policy editor (secpol)

• User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode; and
• User Account Control: Behaviour of the elevation prompt for standard users

To turn UAC prompting off, change these (or the one that suits you) to Elevate without prompting.

Instead of actually turning off UAC, this elevates programs to administrative privileges as soon as they are requested, removing the prompting from the process. This will remove the prompts, but remember, it will not protect you from malware – UAC does not differentiate between good and bad software heuristically or otherwise.

If you’re a Windows Vista Home Basic or Windows Vista Home Premium user, you do not have secpol. However, most of the settings in secpol just correspond to entries in the Windows Registry, including the two UAC settings above.

To change them, open the registry editor (type regedit in the start menu search box and hit enter).

Browse to the following key:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

The prompt settings are stored here as DWORD values. They are ConsentPromptBehaviorAdmin and ConsentPromptBehaviorUser.

The possible values for both settings are as follows:

0×00000000 (0) – Elevate without prompting
0×00000001 (1) – Prompt for credentials
0×00000002 (2) – Prompt for consent