The Shell used to get all the cool APIs :)

After I posted my article on the SHAutoComplete, I mentioned it to one of my co-workers.  His response "I'm not surprised - The shell gets all the cool APIs".   And they do.

For instance, my "new favorite" Win32 API: RegGetValue began it's life as the SHRegGetValue function.  But increasingly, many of the cool shell APIs are moving out of the shell, and that's a good thing.

Over the past couple of releases of Windows, there have been a great number of "shell" helper APIs that have gotten "promoted" out of the shell and transformed into Win32 core APIs.  One of the reasons for that has been the ongoing Architectural Layering effort initiated by some of the teams in the Core OS Division.  I wrote about this layering process a couple of years ago, the MinWin effort that was discussed recently is another benefit of the archlayer work.

The SHRegGetValue API was one of the APIs flagged by the layering issue as being more appropriate for core OS functionality - the analysis done by the layering team showed that a number of low level components in operating system were calling into the shell DLLs because the shell helper functions provided some convenient functionality that wasn't present in the lower layers.

As a result, a number of shell APIs were recreated as kernel32 APIs.  You can see some of them on the "What's New in Windows Vista" page on MSDN.  They include:

There are undoubtedly others that have been migrated over time, these were just a few that I picked up in a couple of minutes of searching.

In general, this is a good thing for both the shell and the core OS teams.  The more applications clients that move away from the shell APIs and into the kernel32 equivalents, the better it will be for the entire ecosystem.

This is another example of how a relatively small change to an application (removing a dependency on shlwapi32.dll) can have significant benefits to the application - as I've mentioned in previous posts, each DLL you load consumes 4 private pages and takes between 500 thousand and a million cycles to load.  If you can remove that dependency, your application will thus load faster.

Comments

  • Anonymous
    November 05, 2007
    PingBack from http://msdnrss.thecoderblogs.com/2007/11/05/the-shell-used-to-get-all-the-cool-apis/

  • Anonymous
    November 05, 2007
    That the shell has so many APIs that should be at lower level tells me that the shell team has been taking up the slack that some of the core teams have been leaving. As an example, most or all of the path APIs should have been part of the file system APIs, especially since a number of these functions are non-trivial when you take into account UNC paths, Unicode/native escape prefixes, slash vs. backslash and repeated slash behavior, etc. I've been a bit encouraged by the API additions in Windows Server 2003 and Vista, as it seems there's some movement to fill in the missing holes in the rougher APIs, like the one for the console subsystem.

  • Anonymous
    November 06, 2007
    The comment has been removed

  • Anonymous
    November 10, 2007
    @Leo: It's the price win32 pays for being an API targeted to perform well for low-level C programs.  The only path to better behavior is to use a good higher-level wrapper, like your custom one or .NET.  

  • Anonymous
    November 11, 2007
    Give it a flag which makes auto-allocation option and it will still perform equally well for the things that need it while being far more convenient in most other cases.