Udostępnij za pośrednictwem

Tips & Tricks for Going Native on Windows Vista

  • Artykuł

I’m presenting a session at TechEd Boston next Friday, titled Windows Vista: Tips & Tricks for Targeting Key Native APIs from Managed Code.  The goal of the session is to share lessons learned on how to use a handful of specific Windows Vista native APIs from managed code (I’ll be using C# for all the demos).

Here’s a preview of what I’m going to cover (along with some insight into why I couldn’t come up with a shorter session title :-)

Why Native APIs?
There’s been a lot of excitement and interest around WinFX , and with good reason - WinFX is loaded with powerful, new managed API sets like WPF, WCF and WF. (Information on WinFX can be found on the MSDN WinFX Developer Center)
 
There are also thousands of new native APIs in Windows Vista, not yet exposed by our managed frameworks.  And there are currently a number of challenges for managed code developers that want to use these APIs.  Some things will be better by the time we ship Windows Vista; other improvements will become available in future versions of Visual Studio and the .NET Framework. 

A lot of great work is being done on Windows SDK samples that illustrate how to implement managed wrappers for many of these native APIs. (You can find a pre-release version of these samples in the Windows SDK, installed under %sysdrive%\Program Files\Microsoft SDKs\Windows\v1.0\Samples – in the CrossTechnologySamples.zip file, look for a folder called VistaBridge) Hopefully, Jeff will resume blogging and will share some of his thinking behind these samples.

Which APIs?
Rather than focusing on the generalities of accessing native APIs, I thought I’d cover tips & tricks for dealing with specific challenges I’ve run into when trying to use the following features:

User Account Control (UAC) is a core security feature in Windows Vista (see TechNet for details); it’s not really an API that you call. But developers do need to understand how UAC can impact applications, and should consider making their apps “UAC-aware”. Basically, an app is UAC-aware when it defines the level of privilege it requires when launched (e.g. standard user, highest privileges user has, or requires admin user). This is done by providing a manifest and setting the value for requestedExecutionLevel. The ideal way to provide a manifest is to embed it in the executable (by the way, this is one of the proposed Logo Requirements; look for the section on UAC)

So what’s the problem for managed code developers? Manifests are typically embedded as native resources during the build process. While native C++ projects provide tools for defining and including resources, there is no obvious way to do this for managed code projects with existing tools – it’s not hard to do, it’s just hard to put the pieces together and figure out what needs to be done. (Look for a future blog post on this subject)

OLE DB Provider for Windows Search.  Desktop search is an integral part of Windows Vista and you’ll see the Quick Search box integrated everywhere: the Start menu, in Control Panel, and all the Explorer windows. You can also easily integrate search into your applications by using the OLE DB Provider for Windows Search.

The OLE DB Provider can be used directly from ADO.NET by using the types in System.Data.OleDb. The challenge in using this provider is the current lack of documentation. (The documentation should be available by the release of Windows Vista). During my session I’ll review some of the basics of the provider’s query syntax as well as the specifics of the connections string. (Another future blog post :-)

Command Links are one of my favorite new UI elements in Windows Vista. It’s not a new control, but rather a new style that can be applied to Win32 buttons.

Command links are really useful when you have lengthy command names, or when the command requires further explanation. The Windows Vista User Experience Guidelines has some recommendations on when to use command links in dialog boxes.

Windows Forms doesn’t currently have a wrapper for the command link, but it’s actually pretty easy to build a reusable wrapper class. I’ll go over the necessary steps during my session (and in a future blog post).

Common File Dialogs. There are new versions of the File Open and File Save dialogs in Windows Vista. These dialogs provide all the new Explorer functionality for viewing, organizing, and searching within files. And they also have a number of new extensibility points for developers.

There’s also a whole new set of COM APIs for these dialogs (IFileDialog, IFileOpenDialog, IFileSaveDialog, etc). The existing Win32 APIs (GetOpenFileName, GetSaveFileName) continue to work on Windows Vista and will display the new dialogs - as long as you don’t pass in a pointer to a hook procedure. Unfortunately, the existing UI frameworks I’ve looked at so far (MFC, Windows Forms, and WPF) all pass in hook procedures. Bottom line: if you are using the file dialogs through any of these frameworks, you won’t get the new file dialogs when your app runs on Windows Vista unless you change your code.

So what’s the big deal, can’t you just use COM Interop? Not directly. These COM interfaces are vtable-based and no type library is provided. So you either have to hand-craft the interop definitions or write a managed wrapper using mixed mode C++.  I’ll go over some of the options during my session.

Well, that's about all I'll be able to cover in 75 minutes. If you're going to be at TechEd and are interested in learning more, then I hope you consider attending my session.

Comments

  • Anonymous
    June 13, 2006
    The comment has been removed
  • Anonymous
    October 10, 2006
    I recently participated in the first three stops of an EMEA Windows Vista and IE7 Readiness tour, specifically,
  • Anonymous
    October 31, 2006
    I'm leaving tomorrow for Spain, where I'll be presenting a couple of sessions next week at TechEd Europe
  • Anonymous
    March 01, 2007
    PingBack from http://www.nathanm.com/getopenfilename-on-vista/