APIs Are More Than Just Function Calls
This is related to my earlier post on toolbar icons. None of newer 3D toolbar icons found in Windows explorer and Office applications are legally redistributable. Applications essentially have to use older versions of the toolbar icons that Microsoft has made available. Even that version is only available for redistribution by purchasing a license of Visual Studio.
I am not aware of Microsoft actually legally enforcing its copyright against the illegal use of its icons. It is probably a public relations disaster to even pursue this avenue.
I understand that Microsoft is concerned about applications that look too similar to its flagship Office application. However, the lack of standard icons and resources in the Windows API just add costs and delays to the development of new applications and also introduces unnecessary user interface inconsistencies in applications, written by different developers.
These icons are not necessarily simple to create as Microsoft recommends that file icons be available in three sizes (48x48 px, 32x32 px, and 16x16 px), each supporting three color depths (24bit with 8-bit alpha, 8bit with 1 bit transparency, and 4bit with 1 bit transparency). You might be able to get away without the 4bit as 16-color and 256-color mode is not available by default in Windows XP; however, 8-bit icons are still shown in 16-bit mode. Icons optimized to appear in the start menu should also support 24x24 px. Toolbar icons should be available in two sizes, 24x24 px and 16x16 px. Microsoft also encourages applications to support icons for high-contrast mode.
There is precedent in Win32 to provide stock icons as system calls do exist to retrieve special cursors, alert icons, and shell icons. Windows also comes with a sizable set of standard fonts.
I think that, in the future, that it would make sense that the API provide a standard set of general-purpose, reusable media such as images and vector graphics. Certainly, all the icons in Windows should be made available for applications to use and redistribute. The OS may also have some interesting theming opportunities with standard shapes.
Not every developer is a graphics expert. Instead of figuring out how to draw a common shape such as a star or lightning in GDI+ or XAML; perhaps, the developer can call into a library of standard shapes (like those provided in Office Drawing toolbar) to instantly obtain the corresponding GDI+ GraphicsPath or Avalon Geometry object.
I am not only thinking about including a set of common general-purpose graphical object in the API, but also common content, in general--generally useful content that might typically be found today in a reference CD.
For example, sometime out post-Longhorn, if and when Microsoft includes a full-featured Natural Language API, the amount of hard disk storage and RAM will be order of magnitude what it is now. Microsoft could potentially include a WordNet-like machine-readable dictionary into the operating system, complete with an identifier for each word, a database of syntactical features for each word, and a full-fledged ontology mapping various semantic relationships between pairs of words. What now would be stored in a reference CD such as Encarta would actually be available for application developers.
Clearly, if natural language understanding is one day to be supported in Windows, such a dictionary is required. It would make more sense for the operating system to store this dictionary, since it is sizeable amount of information for each application to develop and carry, and a common dictionary allows multiple applications to speak the same language (pun intended).
Another example, if the OS fully realizes the potential of 3D graphics, would be the storage of thousands of 3D representations of common objects, which the OS can use to dynamically compose scenes. In combination with AI, this would be very powerful, where computers could readily depict a world that a user imagined and described back to the computer. Today, graphics in application user-interfaces are very much hard-coded (not dynamically generated) and essentially inanimate.
But, for the present, Microsoft should simply offer standard Windows XP (and some of Office 2003) icons and other resources as part of the Windows API.