C++

An Inside Look At The Next Generation Of Visual C++

Tarek Madkour

This article is based on a prerelease version of Visual Studio code-named “Orcas.” All information herein is subject to change.

This article discusses:
  • Targeting apps to Windows Vista
  • Enhancements to MFC
  • Preparing applications for UAC
  • Marshaling native and CLR types
This article uses the following technologies:
Visual C++, Visual Studio

Contents

Prepare Your App for Windows Vista
Add Support for New Common Controls
Other MFC Enhancements
Prepare for User Account Control
Interoperate with Managed Code
Keep It Simple Using the Marshaling Library
Use STL/CLR on CLR Types
Build Code Faster
Conclusion

Windows Vista™ exposes thousands of new native APIs that extend the Windows® platform. These APIs allow developers to create snazzier user interfaces, produce more responsive I/O operations, manage threads more effectively, and much more. The next version of Visual Studio,® code-named "Orcas," will help C++ developers take full advantage of the new capabilities offered by Windows Vista. It will do this by providing built-in support for all the new native APIs as well as additional support for the new controls and common dialogs in MFC and the dialog editors. In addition to all the native development improvements, Visual Studio "Orcas" extends the technology available to C++ developers to interoperate their native components with managed Microsoft® .NET Framework components by providing new libraries designed for bridging the gap between native and managed code. This article describes the details of these new technologies that will be available in the upcoming release of Visual Studio "Orcas."

Prepare Your App for Windows Vista

Visual Studio "Orcas" includes all the necessary headers and libraries needed to target all the versions of Windows from Windows 2000 through Windows Vista. This gives developers access to the low-level APIs exposed directly by the operating system and its components for use in C/C++ applications. In addition to providing access to the C-level APIs, Visual Studio "Orcas" extends MFC to use the new Windows Vista APIs where appropriate, and it encapsulates and exposes a subset of the APIs within the context of the MFC library.

Most of the enhancements made to MFC focus on UI. When an MFC application is recompiled with Visual Studio "Orcas," it gets an automatic face-lift for Windows Vista—that is, common dialogs will be enhanced, toolbars will follow Windows Vista themes, and window frames and title bars will sport Aero™ transparency. This face-lift happens without modifying any code—all you need to do is recompile the application. Of course, by porting the MFC application to the new version of Visual Studio, the developer gains access to the new controls and styles exposed in Windows Vista.

The updated MFC also does all the necessary work to make it easy to use common dialogs in Windows Vista. Consider the following MFC code, compiled with Visual Studio "Orcas":

    CFileDialog dlgFile(TRUE);
    dlgFile.DoModal();

Figure 1 MFC Common File Dialog on Windows Vista

Figure 1** MFC Common File Dialog on Windows Vista **(Click the image for a larger view)

When executed on Windows Vista, the new fancy common file dialog will be displayed as shown in Figure 1. But on downlevel platforms, such as Windows 2000, MFC uses a fallback mechanism to show the old common file dialog, as shown in Figure 2.

Figure 2 MFC Common File Dialog on Downlevel Platforms

Figure 2** MFC Common File Dialog on Downlevel Platforms **(Click the image for a larger view)

Note that the same code compiled with prior releases of Visual Studio and MFC would always result in the traditional common file dialog shown in Figure 2—even on Windows Vista. If you wanted to, you could override the new MFC behavior to default to always displaying the old, non-Windows Vista common dialogs. This is done by passing an extra parameter to the constructor of the CFileDialog class to set the bVistaStyle flag to FALSE.

In addition, the updated MFC classes allow developers to fall back to the underlying COM implementation of the common file dialogs in Windows Vista in order to perform more complex tasks, such as customizing the common dialogs. For example, the updated CFileDialog class has a getter that provides access to the IFileDialogCustomize interface, which allows developers to add controls to the dialog object.

Add Support for New Common Controls

Support for the new controls and styles available in Windows Vista enables developers to create great-looking, true Windows Vista applications. But Visual Studio "Orcas" also added support for some Windows XP controls and styles that were not implemented in previous releases of Visual Studio. Here’s a rundown of controls that were added to Visual Studio "Orcas":

Command Link Control A Command Link, shown in Figure 3, is a new style of button introduced in Windows Vista. It is essentially a button control with the BS_COMMANDLINK style flag set. The Command Link enables better user interfaces with buttons that actually indicate what action the button will execute along with a brief description of the action. This control is mostly used in Windows Vista Task Dialogs.

Figure 3 Command Link

Figure 3** Command Link **

Split Button Control A Split Button, shown in Figure 4, is a Windows Vista button that has a default action as well as other possible actions accessible through a subtle UI gesture that displays a dropdown menu with more actions. A Split Button control is essentially a button control with the BS_SPLITBUTTON style flag set.

Figure 4 Split Button

Figure 4** Split Button **

Network Address Control This control shown in Figure 5 is a Windows Vista simple edit box that validates input to restrict the input to an IPv4 address, an IPv6 address, or friendly DNS names.

Figure 5 Network Address

Figure 5** Network Address **

Sys Link Control This is a Windows XP control that was not supported by prior releases of Visual Studio. It provides a convenient way to embed hypertext links in a window, as shown in Figure 6.

Figure 6 Sys Link

Figure 6** Sys Link **

For each of the new supported controls, MFC also includes classes and notifications. Moreover, the Resource Editor in the IDE was updated to use the new MFC classes and controls. The Toolbox window shows all the new controls as native controls available to the MFC dialog editor. When the controls are dropped on an MFC dialog, they are rendered correctly on Windows Vista hosts; on downlevel platforms, placeholders are shown with an appropriate message indicating that the control cannot be rendered on non-Windows Vista platforms. (Figure 7 shows a pre-Windows Vista dialog while Figure 8 shows a fancier Windows Vista dialog box.) The Property Pages were also updated to show the styles and events available for the new controls. Finally, support was added to the MFC wizards to add control classes and members.

Figure 7 Dialog on Windows XP

Figure 7** Dialog on Windows XP **

MFC in Visual Studio "Orcas" also extends the support for existing controls that were enhanced in Windows Vista. The following controls have extended support: TreeView, MonthCalendar, DateTimePicker, Static, Slider (TrackBar), and Progress controls. Furthermore, Windows Vista enhances many other controls using extended styles to provided smoother UI finish and richer user functionality. The styles for these controls can be set directly by sending a message to the respective control. For example, to enable rich tooltips on TreeView controls providing the ability to custom draw the contents with icon and text, you send a TVM_SETEXTENDEDSTYLE message to set the TVS_EX_RICHTOOLTIP extended style on the control.

Figure 8 Dialog Updated with Windows Vista Controls

Figure 8** Dialog Updated with Windows Vista Controls **(Click the image for a larger view)

Applications wishing to conform to Windows Vista UI guidelines should leverage the new controls available in Windows Vista to create a more attractive and functional user interface.

Other MFC Enhancements

New Windows Vista UI idioms, such as optionally defaulting to hiding the application’s menu bar, have also been accounted for in Visual Studio "Orcas." This particular example makes the menu bar visible only when activated using the Alt key; otherwise the menu bar is hidden. The same technique is used by various Microsoft applications, such as Internet Explorer® 7, running on Windows Vista. To enable this behavior, the developer needs to set the appropriate flag on CFrameWnd by calling CFrameWnd::SetMenuBarVisibility(AFX_MBV_DISPLAYONFOCUS). Aero Wizards are also exposed by MFC. Now MFC wizards can be updated to use the Aero Wizard framework by setting m_psh.dwFlags |= PSH_AEROWIZARD in the CPropertySheet constructor.

Likewise, the Resource Editor has been updated to support the new Windows Vista UI guidelines. By default, new dialogs being added will conform to the UI guidelines in terms of control placement, control size, and fonts used. The Resource Editor also provides enhanced capabilities for viewing icons used in Windows Vista-based applications. It now supports viewing 32-bit color images, PNG images, large 256×56 icons, and PNG icons (as shown in Figure 9). In addition, it supports a better preview mode for icon files that contain multiple icon images.

Figure 9 Icon Support in the Resource Editor

Figure 9** Icon Support in the Resource Editor **(Click the image for a larger view)

Finally, the Spy++ application was updated to monitor new messages introduced in Windows Vista. And Spy++ boasts added support for 64-bit applications in Visual Studio "Orcas."

Prepare for User Account Control

One of the most notable new security features in Windows Vista is User Account Control (UAC). With UAC, users run with least privilege, and administrative rights must be explicitly granted. This feature has very important implications. It’s now critical that developers are conscious of how their application will perform when run under UAC, which is the default on Windows Vista. In addition, it’s recommended that developers take an active role in enhancing desktop security by specifying the security level required by their application. Visual Studio "Orcas" helps developers prepare applications for UAC by removing the burden of manually generating the necessary XML manifests that UAC requires. Applications that do not have UAC manifests and that are not explicitly run with administrator privileges will run in a compatibility virtualization mode where all writes with a global impact, such as to the registry or to non-user disk locations, are redirected to per-user locations. Note, though, that the compatibility mode should only be considered a stop-gap measure since it can introduce subtle flaws in the application. We recommend that all applications designed for Windows Vista should be tested against UAC and should have an appropriate UAC manifest.

The UAC manifest can contain one of three invocation modes: As-Invoker, Highest-Available, and Require-Administrator.

As-Invoker This privilege level lets the application run with the same token as its parent process. This is the default and recommended UAC setting for all Windows Vista applications.

Require-Administrator This privilege level requires the application be run with full administrator privileges. Only members of the Administrators group on the local machine can run an application with this setting. Invoking an application with this privilege level will result in a UAC dialog requesting execution at this permission level.

Highest-Available This privilege level requires that the application be run with the highest privileges available to the current user. This often translates to a Require-Administrator privilege since so many users run as administrator.

So how do you generate a UAC manifest? Visual Studio "Orcas" exposes a new switch for LINK.EXE that enables the automatic generation of UAC XML manifest fragments. The format for the new switch, /MANIFESTUAC, is:

/MANIFESTUAC[:{NO|UAC fragment}]

The default for the switch is to generate a manifest with the As-Invoker privilege. Specifying No to the switch will generate no manifest and will cause the application to run in the compatibility mode. Specifying either requireAdministrator or highestAvailable will set the respective privileges on the generated UAC manifest.

Visual Studio "Orcas" also exposes the same options on a project’s property pages, as shown in Figure 10.

Figure 10 User Account Control Options for Visual C++ Projects

Figure 10** User Account Control Options for Visual C++ Projects **(Click the image for a larger view)

By default, an As-Invoker UAC manifest is generated for all new applications created with Visual Studio "Orcas." All applications upgraded from previous versions of Visual Studio will also have UAC automatically enabled.

I should also note that Internet Explorer 7 uses the UAC features of Windows Vista to provide a more secure Protected Mode. This mode, which is the default, essentially runs components inside Internet Explorer with less than standard user privileges. This is achieved by launching components in a newly spawned instance of Internet Explorer that has lower rights. Consequently, components that need to run within the context of Internet Explorer 7, such as ActiveX® controls, need to be tested against Internet Explorer 7 Protected Mode.

Visual Studio "Orcas" adds a new option for C++ projects to enable debugging for applications under Web browsers. And the list of available debuggers now contains a Web browser debugger, which is also aware of Internet Explorer 7 Protected Mode and does all the necessary work to attach to the newly created lower privilege process.

Interoperate with Managed Code

In addition to the strong focus on native tools for C++ developers, Visual Studio "Orcas" extends its support for technologies that bridge the gap between native C++ components and .NET components that were developed using managed code. Since the introduction of the .NET Framework, increasing numbers of industry-level applications have been incorporating more managed components into their native C++ applications in areas where managed code is valuable and appropriate.

Visual Studio "Orcas" makes it easier to integrate those .NET components into existing and new native C++ code. Visual Studio now provides libraries that bring native idioms to managed code and help you to effectively write code that crosses the native-managed boundary.

Keep It Simple Using the Marshaling Library

The most fundamental requirement for mixing native and common language runtime (CLR) types is being able to marshal the data across both type systems. Fortunately, Visual Studio "Orcas" comes with a solution. It includes a new Marshaling Library that reduces the complexity of writing code that marshals types between the native world and the CLR. The Marshaling Library operations are based on existing .NET Framework routines, but reduce the complexity of working with these classes by exposing marshaling routines as members of an extensible template library.

The new Marshaling Library has built-in support for all of the different common string types used by C++ applications—such as ATL CString, BSTR, CComBSTR, char *, wchar *, std::string, std::wstring, and System::String^. And developers can add more conversions than those supported out-of-the-box. Here’s a simple example of using the Marshaling Library to convert a System::String to a char *:

#include <msclr/marshal.h>

void myfunc (String^ s)
{
    msclr::interop::marshal_context ctx;
    char *s2 = ctx.marshal_as<char*> (s);
    //...
}

Use STL/CLR on CLR Types

The container-iterator-algorithm structure of the Standard Template Library (STL) has simplified C++ development and it is now a pattern that many C++ developers are accustomed to. Visual Studio "Orcas" brings the same idioms that STL makes possible for native types to the world of CLR types using STL/CLR. This new capability has the potential to greatly improve the productivity of C++ developers by allowing the use of the same idioms in both the native and managed worlds. Additionally, this feature makes it easier to exchange data between STL containers and .NET collections.

STL/CLR provides the same containers for CLR types that STL provides for native types. The new containers are part of the cliext namespace. STL/CLR also maintains the same algorithmic complexity as STL. STL/CLR containers can hold garbage-collected CLR reference types and value types as well as both CLR and native built-in types; they cannot hold pure native types or pointers to native types.

STL/CLR also exposes iterators that work with its containers. STL/CLR iterators maintain the same hierarchy as that of STL iterators, and the STL/CLR iterators are accessed in exactly the same way. STL/CLR also exposes the same set of algorithms as STL. The algorithms can operate on STL/CLR and STL containers. The following sample shows STL/CLR containers and iterators in action:

#include <cliext/hash_map>

void myfunc ()
{
    cliext::hash_map<Int32, String^> m;
    m.insert (cliext::make_pair(5, L”five”));

    cliext::hash_map<Int32, String^>::iterator i = m.find(5);
    Console::WriteLine(“map[{0}] == {1}”, i->first, i->second);
}

Build Code Faster

Another improvement for developing C++ code that targets the CLR is that incremental builds are significantly faster. One sore point in the development of large CLR applications that have C++ components has traditionally been the need to rebuild dependencies, even when the core components have had only implementation changes and no interface changes. This was due to CLR assemblies packaging both the metadata and the implementation of a component in one binary. As a result, large C++ projects that depend on CLR assemblies would need to be rebuilt if any part of that CLR assembly changed.

The upcoming release of Visual Studio adds a new tool that creates a metadata-only assembly that captures the interface and only rebuilds dependent C++ projects when the interface assembly has changed. Changes to the implementation of an assembly do not trigger a rebuild of dependent assemblies. This can significantly reduce build times in the incremental build scenario, subsequently improving developer productivity.

While I’m on the topic of build throughput, one of my favorite features of Visual Studio "Orcas" is its ability to compile source files in parallel. This works for both native and managed code. CL.EXE provides a new switch, /MP, to enable this behavior. The syntax for the new switch is as follows:

/MP[n] use up to ‘n’ processes for compilation

Here, n essentially specifies the number of processors to be used. When the number of processors is not specified, the compiler uses the number of logical processors available on the machine. When a number is specified, exactly n processes are spawned for compilation.

The parallel compilation feature works by compiling different translation units in different processes; a single translation unit cannot be compiled across multiple processes. For example, consider the results of the following compiler invocation when run on a quad-processor machine:

CL /c /MP a.cpp b.cpp c.cpp d.cpp e.cpp f.cpp

The compiler will end up compiling four translation units in parallel with new translation units being compiled as soon as one of the four processors is freed up.

Now consider the results of the following compiler invocation run on a dual-processor machine:

CL /c /MP a.cpp

The compiler will perform a serial compilation of the single translation unit that it received since it does not perform parallel compilation within a translation unit.

Conclusion

The upcoming release of Visual Studio "Orcas" provides significantly enhanced tools for C++ developers looking to take advantage of the new features and capabilities offered by Windows Vista. In this release, thousands of new Windows Vista APIs are being made available to Win32® developers. MFC was also enhanced to make many Windows Vista features readily consumable for MFC developers. The IDE extends the Resource Editors to expose the new Windows Vista controls. And support has been added for creating UAC-aware applications.

Visual Studio "Orcas" also offers improvements for developers who need to bridge the gap between the native C++ code and the CLR. This is done with new libraries and tools that help improve developer productivity. Meanwhile, the new version of Visual Studio includes handy new features like parallel compilation to further improve the developer experience.

Tarek Madkour is a Lead Program Manager on the Visual C++ team at Microsoft. He has been working on different areas of the Visual C++ IDE and compiler for the past six years.