# Slow Chat Archives > Slow Chat: Visual C++: Yesterday, Today, and Tomorrow >  [RESOLVED] Orcas and wrapping native Vista APIs

## Ted.

Doing a bit of work with the Vista Beta 2 SDK, I have realized just how huge a number of new native Vista APIs there are.  I'm not necessarily talking about the new controls or user experience APIs, which you have already talked about wrapping.  I'm talking about things like IFileOperation, the whole known folder API, the property system, and countless non-COM APIs in every subsystem of Vista.  Last I heard there are something like 5000 new APIs.  

I feel there's a real need for wrappers of these APIs (especially the COM based APIs).  I believe that MFC is a perfect delivery mechanism for these wrappers, for a few reasons:

1) When new APIs are introduced, I find that most of them are wasted (i.e. never used) because people are too afraid to use them since they are not backwards compatible.  People want their apps to run on all platforms, but can't be bothered writing all the delayloading or fallback code that is necessary.   Having classes help here a lot.  

2) The complexities of COM are still lost on a lot of developers.  As COM is taking a major role again in Vista with all the new "I" based APIs, the perfect opportunity exists to wrap these APIs as clean C++ based classes that isolate the user from any extra COM intricacies.   Compare that with tons of boilerplate code using CoCreateInstance, Class IDs, PIDLs, etc.  Believe me when I say a lot of this code is ugly.  Check the latest Windows SDK samples in Beta 2 SDK if you don't believe me. 

3) Having new APIs grouped together by category into classes, with proper Intellisense is very helpful for new users and increases discoverability of these new APIs. 

So my question is: Can you tell me what other work you're planning on doing with respect to native Vista APIs (COM and non-COM based) other than the work you've already announced (Vista User Experience, controls, new common dialogs)

It would be a shame to have a new set of APIs ignored once again.

----------


## CBasicNet

I beg to differ on the "MFC is a perfect delivery mechanism for these wrappers" part, I think the wrapper should not be MFC based; it should be neutral that  MFC, ATL/WTL and Win32 projects can use them.

----------


## Ted.

Yes you're probably right, however, they're not going to create new libs for Orcas, so the other choice to put them in would be ATL.

----------


## Nikola Dudar - MSFT

Hi Ted,

We have done in depth review of all new Vista APIs and discussed possible wrappers. We were looking on adding classes to ATL that can be used in MFC , similar to CStringT. We grouped them into categories, such as new security related APIs (URL APIs, Crypto, File System and Critical section APIs, thread pool); new APIs related to Vista UI (Common ctrls changes, shell extensions, property sheets, winuser and clipboard APIs); new Fusion (WinSxS) APIs and other. During the planning we have looked on all of them and prioritized based on time and resource available and what we saw as interesting to MFC developers. As you may already know, we have decided to focus on enabling MFC developers use all new styles, messages and common controls that are available on Vista. We also are planning to enable developers use new File dialogs API. We have decided to not provide wrappers for shell APIs, wizards, windows service APIs, perf mon and HTTP/URL specific APIs. Some of these can already be easily used in existing code based. As we hear demand for a specific group of APIs, we are going to add wrappers to these in MFC in the next versions.

Thanks,
Nikola Dudar
Program Manager
Visual C++

----------

