Minimum System Requirements
The first thing to consider is the hardware that you’re currently using. Because developers tend to keep their systems relatively up-to-date, more than likely you’re in good shape. However, if your system is more than two years old, you’re going to want to check to make sure that it’s suitable for Vista. It’s recommended that you take a few minutes and run the Windows Vista Upgrade Advisor which is a utility that will generate a compatibility report. Note that it only works with Windows XP, so if you’re using an older version of Windows then you’ll have to make the evaluation yourself.

Microsoft lists the minimum system requirements for Vista as a 1 GHz processor, 1 GB of memory, 40 GB of disk space and a DirectX 9 compatible video card with at least 128 MB of memory. However, keep in mind that is the minimum system requirements, and they really mean it. For a development system that’s actually usable, you’ll want at least a 2 GHz processor, 2 GB of memory, 120 GB of disk space (all of those development tools add up) and a DirectX 9 video card with at least 256 MB of memory. Keep in mind that the actual processor speed largely depends on the type; a system with the Core Duo is going to perform better than a P4 at a higher clock speed. You can also get by with a video card that has less memory, particularly if you don’t plan on running with the Aero Glass desktop. If you’re looking at multiple components to upgrade, then prioritize memory first. Vista is very aggressive with its memory use, so the more RAM it has and the faster it is, the better it will perform. I would point out that it is possible to install Vista on a lower-end system; however it’s not likely that you’ll be happy with the performance.

Windows Vista Version
If you’ve decided that your hardware is suitable for Vista, then you need to decide what version of the operating system you should upgrade to. Vista comes in several different versions, from Vista Home to Vista Ultimate. As a developer, you really just have two choices: Vista Business or Vista Ultimate. Vista Business is fairly close to Windows XP Professional in terms of the overall features. Vista Ultimate is basically a combination of the Business version and the Home Premium version which includes Windows Media Center. Vista Ultimate also includes the BitLocker disk encryption that’s in the Enterprise version. The bottom line is that Vista Ultimate is the best choice if your development system also doubles as your personal computer. If you’re only concerned about business features on a system at work, and aren’t interested in the built-in disk encryption, then Vista Business is all you’d really need.

Drivers and Development Tools
Now that you’ve decided on what version of Vista to install, you should take an inventory of your peripherals. In particular, you’re going to want to make sure that drivers are available for your video and audio adapters, as well as your printer. USB devices won’t be a problem in most cases, but multi-function printers may not have drivers available. If you’re not using integrated audio, you may also find that release drivers aren’t available for your audio card (the audio stack was changed significantly in Vista, and some vendors only have beta drivers available with partial functionality). You should also check for any BIOS updates, as well as any updates to the chipset that your system is using.

In most cases, the development tools that you use under Windows 2000 or Windows XP will work fine on Vista. However, there are some general issues to be aware of. The most significant is that Microsoft only officially supports Visual Studio 2005 on the platform. If you use Visual Studio 6.0 or Visual Studio .NET 2003, you can install them, but Microsoft will not provide any support for them on the platform. If upgrading to Visual Studio 2005 isn’t an option you’re not completely out of luck, but there will be some limitations. Most of those limitations revolve around one of two general areas, ActiveX and debugging. More specific information is available in our article Software Development on Windows Vista. Another thing to keep in mind is that if you’re currently using WinHelp for your help files, that format is no longer supported by Vista. Microsoft does plan on releasing a WinHelp viewer at some point, but you should make plans to migrate your help projects to HTML Help.

Upgrade or Clean Install
Finally, you have to make the decision as to whether you’re going to upgrade your system in-place, or perform a clean install. While an in-place upgrade is tempting, it’s not something that I’d recommend. Upgrading from an earlier version of Windows takes longer than a clean install, and it is much more likely that you’re going to encounter odd compatibility problems (or even system instability) when upgrading. Although re-installing all of the development tools and utilities is certainly no fun, it will pay off in the long run. Make sure you have a good backup of your source code and data, as well as any software that you’ve downloaded and/or purchased online. If you don’t have an external USB drive, now would be a good time to invest in one. It’ll make the re-installation process much easier in the long run, as well as provide the best way to backup your complete system. Once you’ve started the installation the process is largely automated, so there’s little for you to do but sit back and relax.

Historically, Windows was an operating system designed for the traditional, stand-alone desktop PC. Networking was considered in a local context, and the Internet was something used primarily by the military, universities and some large companies. When Internet use exploded in the mid 1990’s, with all of the benefits it offered, it also presented a serious problem that was underestimated by many developers, including many within Microsoft. Single-user desktop systems with virtually no security features had joined the Internet by the millions. Software that had been written for stand-alone systems, without any real concern for security, was now exposed to an extremely hostile environment.

Over the years, Windows developers have become accustomed to the idea that they have absolute control over the system. For example, they had the ability to create system-wide message filters which can intercept the messages for any application, inject code into another process or even have a DLL loaded in the address space of every process that’s created. Features which were designed to facilitate computer-based training, automation and testing on a stand-alone system became attack vectors for malware to wreak havoc on vulnerable computers connected to the Internet. With Vista, programs which use those features are restricted (requiring elevated privileges), and more strict security policies can be used, such as only permitting an executable or DLL to be loaded if it is in a secure system folder.

It is important to understand that Windows Vista is more than a collection of technological improvements. It also represents a fundamental change in terms of how Microsoft views the importance of security on the platform and the role they play as a company whose operating system is found on 90% of the desktop computers around the world. In the past, their principal concern was backwards compatibility. New features, including security features, were implemented while looking “backwards” to minimize the impact on existing applications. Even when Windows XP began to replace Windows 98 platforms on the consumer desktop, the default was to install the system giving the user administrative privileges and doing everything that they could to effectively “hide” the security-related aspects of the operating system.

With Windows Vista, efforts to maintain backwards compatibility did not automatically trump security concerns. The rule was simple: if security and compatibility come into conflict, security must win. So when it comes to the question of whose system it is, the answer is that it is everyone’s. The right to do as you please with your computer stops at the router that connects you to the Internet. Security is not just a feature; it is an obligation and a responsibility, and one that we must all take seriously, including hardware manufacturers, software developers and end-users.

Least Privilege Applications
As a software developer, the most significant change you need to make is with the general assumption that you have control over the entire system. For example, you may presume that you can create files in the same directory where your application is installed, or that you can create keys anywhere in the registry. You may also assume that you can do things like register ActiveX components, install message hooks or attach to another process. All of these things are now restricted, and unlike previous versions of Windows, telling the user that they are required to have administrative privileges won’t resolve the issue. The UAC system is specifically designed to limit access to system resources, even when the user is an administrator.

The most important things to keep in mind are:

1. Do not assume that you can create files in the same directory as the application. Under Vista, you will not have privilege to create files under C:\Program Files or C:\Windows. This is a particularly important because many applications create data and configuration files in their installation folder.

2. Store shared application data and configuration files in the common AppData folder. Under Vista, this is typically the C:\ProgramData folder. For per-user data and configuration files, store them in the user’s AppData folder, typically C:\Users\<UserName>\AppData\Roaming. Keep in mind that you should never make an assumption about what the actual path is. Use the SHGetFolderPath function that is part of the shell API to determine the correct location.

3. Never assume that you can create registry keys anywhere other than HKEY_CURRENT_USER. Access to other parts of the registry is generally read-only. Any information that your program needs to store in the registry should be stored under HKEY_CURRENT_USER\Software\<Company>\<AppName>.

4. Don’t request more privilege than required when accessing a file or registry key. For example, if you are only reading a file, don’t attempt to open it with read-write access. The same applies to the registry; don’t open a key with KEY_ALL_ACCESS rights if you’re only going to read a key value. Request only those privileges that you need at the time that you need them.

5. Never make the assumption that a particular Windows API function will always succeed. Functions which have “always worked” under Windows XP may fail under Vista due to access restrictions. For example, installing message filters or system-wide hooks can fail because the process doesn’t have the appropriate access rights. Always check the return values and practice defensive coding. Because it worked under previous versions of Windows is no guarantee that it will work correctly under Vista.

UAC Virtualization
What do you do about applications that have already been written which don’t follow those rules? For example, what if your program creates INI files in the same folder as the executable, or stores configuration data in the registry under HKEY_LOCAL_MACHINE\Software? The good news is that your application will probably work correctly. This is because Vista includes support for virtualization of specific parts of the filesystem and the registry.

When your program attempts to create or modify a file under C:\Program Files or C:\Windows it is automatically redirected to the user’s virtual store, which is typically C:\Users\<UserName>\AppData\Local\VirtualStore. If you are modifying a file that already exists, a copy of it will be made in the virtual store for the user. If you are creating a new file, it will only exist in the user’s virtual store. This happens transparently, and as far as your program is concerned there has been no change in the file path.

The system also virtualizes registry access under the HKEY_LOCAL_MACHINE\Software key. If your program creates or modifies a key value there, it will be automatically redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software. As with the filesystem, this is completely transparent to your application.

It is also important to be aware of the potential side-effects of virtualization. While many applications will be able to run without issue, some will fail unexpectedly. This will typically affect programs which store licensing information in the registry or implement anti-piracy methods like embedding license keys in the executable after installation. Virtualization can also create the appearance of a flaw in your software. For example, if you store global configuration data in the registry under HKEY_LOCAL_MACHINE, any configuration changes that are made will always be per-user because of virtualization. If user “A” makes a change, it will be virtualized to their registry hive and users “B” and “C” will not see those changes. Any changes made by user “B” will not be seen by user “A” or “C” and so on. This can cause users to think that the configuration changes they’re making aren’t persisting correctly, or can cause more serious problems such as the wrong database being opened, files not being created in the correct location and so forth.

Although virtualization does help lessen the impact of the security changes in Vista, it is not intended to be used with new software. Microsoft has explicitly stated that developers should not depend on virtualization for two specific reasons. First, virtualization is a configurable option. By default it is enabled, but a system administrator can choose to disable it. Second, it is not guaranteed that it will be supported in future versions of Windows. Virtualization exists solely to help developers make the transition to Vista, ensuring that legacy applications will continue to run. It is not a feature developers should count on in the future.

Visual Studio 2005
If you use Visual Studio 2005 and are interested in moving to Vista as your development platform, you’re in good shape. Microsoft supports Visual Studio 2005 on Vista, and Service Pack 1 was released on December 19th, 2006. If you previously installed the beta version of the service pack, make sure that you uninstall it first, before attempting to install the released version or you may encounter errors during the installation.

It’s also recommended that you download the .NET Framework 3.0 and Windows SDK for Vista, which is the latest version of the Platform SDK. One note of caution for developers who are also using older versions of Visual Studio: Do not replace your previous Platform SDK with the new Windows SDK, particularly if you’re still using Visual C++ 6.0. Also, if you use third-party plug-ins for Visual Studio, check with the vendor to make sure that they support Vista.

Visual Studio .NET 2003
If you are currently using Visual Studio .NET 2003, you can install it under Vista; however, it is not supported by Microsoft and they don’t recommend that you use Vista as your development platform. Under most circumstances, you will probably find that Visual Studio .NET 2003 will work correctly. We have it installed on Vista, primarily for testing purposes, and are able to edit, compile and debug programs locally. Where you can run into problems is with remote debugging and COM interop.

If you want to try using VS.NET 2003 with Vista, make sure that you download and install Service Pack 1 if you haven’t already. If you’re using third-party plug-ins, make sure that they’re still supported. Because Microsoft won’t support older versions of Visual Studio on Vista, some vendors may choose to only support Visual Studio 2005 on the platform.

Visual Studio 6.0
Although the number of developers using Visual Studio 6.0 has steadily declined over the past several years, there are still a fairly large number of companies that continue to use Visual Basic 6.0 and Visual C++ 6.0. As with Visual Studio .NET 2003, Visual Studio 6.0 is not supported under Windows Vista and if you cannot upgrade to Visual Studio 2005, Microsoft recommends that you continue to use Windows XP as your development platform. There is some good news, and that is Microsoft will continue to provide support for the Visual Basic 6.0 runtime in Vista. This means that programs you develop using Visual Basic 6.0 will continue to run and be fully supported.

If you’re using Visual C++ 6.0, you’ll find that for the most part you’ll be able to use the IDE and compiler without a problem. However, remote debugging and using ActiveX controls can present problems. For example, adding components to your project (through the Project | Add to Project | Components and Controls menu option) may not work correctly.

Borland Developer Studio 2006
Borland has promised support for Vista and the .NET 2.0 Framework in 2007, however the current version of Borland Developer Studio is not supported under Vista and they recommend that you continue to use Windows XP as your development platform. Because Borland only supports version 1.1, developers won’t be able to take advantage of some of the new features included with Vista and the .NET 3.0 Framework until the new version of BDS is released.

Third-Party Languages
There are a large number of third-party languages available for Windows, and many of them will continue to work under Vista without a problem. The two key areas that are most likely to encounter problems are debugging and support for ActiveX controls or Automation. In some cases it may be required to run them with elevated privileges, either from the command line or from within their IDE. If you experience problems, select the shortcut to the program from the Start menu and right-click on it. Select Properties and the property sheet for the shortcut will be displayed. Next, click on the Compatibility tab and make one or more of the following changes:

1. Enable compatibility mode and select Windows XP (Service Pack 2). If the compiler is performing operating system version checks, it will continue to think that it’s running under XP. If this doesn’t work, try setting compatibility to Windows 2000.

2. Check the option to disable visual themes. This will disable theme support in the application, and is a good choice if you’re noticing problems with menus or buttons not being drawn correctly.

3. Check the option to disable desktop composition. This will disable the advanced features in the Aero Glass interface, such as transparency. This is a good choice if you notice problems with windows not being drawn correctly. For example, if the IDE includes visual tools to create and edit forms or dialogs, you may find that controls are drawn very slowly or aren’t redrawn in the correct position. Disabling this feature will often correct the problem, however it will force the entire desktop (not just the application) to disable the Aero UI until the program terminates.

4. Check the option to run the program as an administrator. This will allow the IDE or compiler to run with elevated privileges. If you are experiencing problems debugging your application or using third-party ActiveX controls, enabling this option may correct the problem. Note that if this option is enabled, you will be given a UAC prompt every time that you run it. You should only enable this option for programs that you trust because they will be given full, unrestricted access to the operating system.

User Account Control
Aside from the user interface, the new User Account Control (UAC) system is probably the first thing that you’ll notice. There’s been a lot written about UAC, but the bottom line is that applications no longer have unrestricted access to the entire system, even if the user has an account with administrative privileges. Whenever you attempt to perform a system maintenance function, copy files to a protected folder, modify the registry or install an application, UAC will block the application and prompt the user to confirm the action. When UAC is enabled, essentially all applications run with restricted privileges, regardless of what groups the user is a member of. This impacts programs in several important ways, including how they are installed, how they store configuration information and create data files.

Software Installation
When a user installs your software, it will typically require elevated privileges and they will be presented with a UAC prompt, asking them to confirm the installation. This will allow your installer to register components, create file associations and add the other registry entries that it requires. It will also allow your installer to store files in protected system folders under C:\Windows and C:\Program Files. A consequence of this is that you should not launch your application (or another application, such as a web browser) at the end of your installation. The reason is that, as a process created by the installer, it will inherit those elevated privileges and be able to create files and access system resources that the user normally would not be able to.

Configuration Files
Applications should create any configuration and data files on first run, not as part of the installation process. This is because the installer runs with elevated privileges and can store files in locations that are not normally writable by the user. Related to this, you should not store configuration files or data in the same location as the executable under the C:\Program Files folder. Users only have permission to read files stored there, and cannot create or modify them. The appropriate place to store per-user configuration files is in the user’s AppData folder, and system (global) configuration files should be stored in the ProgramData folder.

Registry Access
Registry data for the application should be stored under the Software key in HKEY_CURRENT_USER, not in HKEY_CLASSES_ROOT or HKEY_LOCAL_MACHINE where the user does not have permission to create or modify keys. This will impact ActiveX controls and other COM objects because the process of registration typically requires that they create keys under HKEY_CLASSES_ROOT. In practical terms, this means that utilities like RegSvr32.exe will not work correctly unless it is run with elevated privileges. For applications that are designed for Windows XP and later versions of Windows, developers should consider deploying their software using registration-free COM activation. That also enables applications which use ActiveX controls to be deployed using ClickOnce installation.

Visual Studio
Microsoft created some controversy when they announced in September, 2006 that only Visual Studio 2005 would be supported for development under Vista. It’s important to note that it is only the Visual Studio 2003 development tools which are not supported; applications created using the .NET 1.1 Framework are fully supported under Vista. If you’re using an older version of Visual Studio, our general recommendation is to upgrade to Visual Studio 2005. If you are unable to upgrade to Visual Studio 2005, then we recommend that you continue to use Windows XP as your development platform and test deployment under Vista.

The compatibility issues with Visual Studio 2003 and Vista primarily involve the debugger and COM interop and many developers may not experience a problem using it. However, if you do encounter a problem, Microsoft will not provide updates or hotfixes to address problems specific to the Windows Vista platform. Additional information can be found on the Visual Studio section of the Microsoft Developer Network. Select Support, then Visual Studio on Windows Vista from the menu.

Microsoft has released Service Pack 1 for Visual Studio 2005 and we strongly recommended that you install it, particularly if you are using Vista as your primary development platform. Note that if you have previously installed the beta release for this service pack, you must uninstall it and reboot your system before installing the official release. If you don’t, you’ll get errors during the installation process.

SocketTools
When you install SocketTools 4.5 on Vista, you will be given a UAC prompt confirming the installation. You must install SocketTools with administrative privileges, or the installation will not complete correctly. The SocketTools components are installed into system folders, and changes are made to the registry which requires elevated privileges.

It is recommended that you provide your serial number and other related information as part of the installation process. If you have previously installed an evaluation version of SocketTools, it is recommended that you re-install the product and provide a serial number. If you wish to use either the License Manager or Registration utility that is included with SocketTools, you must run them with elevated privileges by right-clicking on the utility and selecting “Run as Administrator” from the menu.

SocketTools 5.0, the next major release of SocketTools scheduled for release in February, will be specifically designed for the changes introduced in Windows Vista. We have made internal changes to the components and libraries which significantly improves functionality under Vista, while maintaining backwards compatibility and without requiring changes to your existing code.